Why I switched from Next.js to Astro

After 4 years with Next.js, I moved my projects to Astro. This post is not about which is better — it is about the specific technical reasons that made Astro the right choice for my use cases.

What I was building

Three projects drove the switch:

1. A marketing site + blog for an open-source project (mostly static, occasional dynamic page)
2. A docs site for the same project (mostly static, search is dynamic)
3. A small SaaS dashboard (mostly dynamic, some static pages)

All three were on Next.js. All three felt heavier than they needed to be.

The reasons

1. Less JavaScript by default

Next.js ships React runtime to every page, even ones with no interactivity. Astro ships zero JavaScript by default and lets you opt in per-island.

For the marketing site, this was the single biggest win. The page went from 280KB of JS to 0KB. LCP dropped from 2.1s to 0.9s.

2. Better static generation

Next.js getStaticProps works, but it runs at build time and the result is locked in. Astro's content collections give you type safety, frontmatter validation, and a query API that works at both build and request time.

For the docs site, this meant I could query content by tag, by date, or by frontmatter field — without writing custom build logic.

3. Simpler mental model

Next.js has App Router, Pages Router, Route Handlers, Server Actions, and Server Components. Each has its own rules. The cognitive load is real.

Astro has pages, layouts, and components. That is it. The simplicity is not a limitation — it is a feature.

4. Faster builds

My Next.js docs site took 90 seconds to build. The Astro version takes 12 seconds. Same content, same output. The difference is architecture — Astro was built for static-first, Next.js was not.

5. No React requirement

I wanted to use Vue for one component (a complex form) and Preact for another (a lightweight widget). Astro lets me mix frameworks on the same page. Next.js does not.

What I lost

Honesty time. Switching was not free.

• Server Actions — Next.js Server Actions are nice. Astro has nothing equivalent; you write endpoints.
• Ecosystem — Next.js has more third-party integrations. I had to write a few myself.
• Talent pool — more developers know Next.js. Hiring is harder with Astro.

For my use cases, the trade-offs were worth it. For yours, they may not be.

When I would still pick Next.js

• Heavy app-like products with lots of client-side state and complex routing
• Teams already invested in React — the switching cost is not worth it
• Vercel-locked features — if you need ISR at scale and you are on Vercel, Next.js is the path of least resistance

Closing

Astro is not better than Next.js. Astro is better than Next.js for the things I build. The right framework depends on your project, your team, and your constraints.

The mistake is treating framework choice as identity. Pick the tool that fits the job. Switch when the job changes.