From Next.js to Astro + Cloudflare Pages: Our Migration Story and Real Performance Numbers

Migrating a production site from one framework to another isn't a decision we took lightly. When we inherited mintec.co, it ran on Next.js 14 deployed on Vercel. It worked. But it had problems: Core Web Vitals were inconsistent, the JavaScript bundle weighed 463 KB, builds took over 4 minutes, and we were paying $49/month for a Pro plan we barely used. We decided to migrate to Astro + Cloudflare Pages. This article documents the real numbers, the technical decisions, and what we learned along the way.

The Starting Point: Why Next.js Wasn't the Answer

Next.js is an excellent framework, but it has a clear bias: it's built for full web applications, not content sites. With Next.js 14 in SSG (Static Site Generation) mode, every page generates static HTML at build time, but the framework always ships the React runtime in the client bundle. That means even if your page has zero interactive components, the browser still downloads, parses, and executes React — 463 KB of JavaScript that does nothing visible for the user.

The numbers before migration:

The problem wasn't Next.js per se — it was using the wrong tool for the job. Our site is primarily content: service pages, blog, portfolio. No dashboards, no authentication, no shared state between pages. For what we needed, Astro offered a cleaner architecture.

The Astro + Cloudflare Pages Architecture

Astro flips the fundamental premise: zero JavaScript by default. Instead of rendering components on the server and shipping the runtime to the client (as Next.js does), Astro renders everything to static HTML at build time and only sends JavaScript for components that explicitly need it (islands).

+------------------+       +------------------+
|     Next.js      |  →   |      Astro       |
|                  |       |                  |
|  React runtime   |       |  Zero JS by      |
|  (463 KB)        |       |  default (0 KB)  |
|  Pages Router    |       |  Content         |
|  API Routes      |       |  Collections     |
|  Image Opt.      |       |  Astro Islands   |
|  Middleware       |       |  View Transitions|
+------------------+       +------------------+
|  Deploy: Vercel  |       |  Deploy: CF      |
|  $49/month       |       |  Pages: FREE     |
+------------------+       +------------------+

The final stack:

The Numbers After Migration

Lab results (Lighthouse, simulated slow 3G network):

Field data (Chrome User Experience Report) also improved significantly. The P75 LCP went from 3.8 s to 1.6 s for visitors from Latin America, where Cloudflare's infrastructure has better presence than Vercel's.

What We Gave Up

Not everything was a win. Migration has costs you need to understand:

1. Interactivity islands. If you need stateful React components (dynamic forms, carts, dashboards), Astro supports them via client:load, but each island adds JS to the bundle. Not a problem for content sites, but a real consideration for interactive applications.

2. No API routes. Cloudflare Pages Functions can replace Next.js API routes, but the DX isn't as polished. For purely static sites like ours, we don't need them.

3. Smaller ecosystem. Astro has fewer components, plugins, and tutorials than Next.js. For standard use cases (blogs, marketing sites, documentation), it's well covered, but finding solutions to very specific problems may require more research.

4. View Transitions needs setup. Although Astro 5+ has native View Transitions API integration, making it work well between pages requires configuring view-transition-name on shared elements, adding CSS complexity.

When to Choose Astro vs Next.js (Our Decision Framework)

Based on our experience, here's the framework we use at Mintec for each project type:

Lessons Learned

If you're considering a similar migration, here's what we'd do the same and what we'd do differently:

What We Did Right ✅

• Measured before migrating. Lighthouse, WebPageTest, CrUX field data. Without baselines, you can't prove improvement.
• Migrated in phases. First the static pages (home, services), then the blog, then the dynamic pages. Each phase validated the architecture.
• Eliminated unnecessary dependencies. We used the migration to review every dependency. Went from 23 dependencies to 11.

What We'd Do Differently 🔄

• Budget more time for View Transitions. Data migration was fast (2 days); animation configuration took almost an additional week.
• Don't underestimate redirect configuration. We had 38 legacy URL redirects from the old site. Cloudflare Pages uses a _redirects file with specific syntax that has its own edge cases.
• Communicate the change to the team. We moved from a familiar stack (React + Next.js) to a less familiar one (Astro). The team's learning curve was real.

The Verdict

Migrating from Next.js to Astro + Cloudflare Pages was the best technical decision we made for mintec.co. We reduced JavaScript by 94%, improved every Core Web Vital, eliminated a $49/month recurring cost, and cut build times from 4 minutes to 48 seconds.

But this isn't a universal recipe. Next.js remains superior for interactive web applications. The key is choosing the right tool for the project type — not the trendiest one or the one you're most familiar with.

If your site is primarily content and you're paying for features you don't use, the migration to Astro will likely deliver similar results. If you need a full-stack framework with dashboards, APIs, and authentication, stick with Next.js.

In the end, the best framework is the one that doesn't stand between your content and your users.

Have a project and aren't sure which stack to choose? At Mintec we help you make the right decision from day one. Contact us for a free web architecture consultation.

Related articles:

• View Transitions API in Production: Patterns Beyond the Demo
• AI Agents in Backoffice: Automating Internal Operations