Next.js vs Astro: How Much of Your Page Is Interactive?
Astro ships zero JavaScript until you ask for it. Next.js ships a React runtime and lets you shrink it. That one difference decides most of this.
The honest framing of this one is a single question: what proportion of your page needs to do something after it loads?
Answer that and the comparison mostly resolves itself.
The default each one starts from
Astro renders to HTML and ships no JavaScript. Interactivity is opt-in per component - an island - and everything outside those islands is static markup. A page with one search box ships the search box.
Next.js renders to HTML and ships a React runtime. Server Components let you keep components off the client, so the bundle can be small, but the baseline is not zero and the discipline is yours to maintain. Where the client boundary sits is the whole difference between a lean Next.js page and a heavy one.
So: Astro starts at zero and you add. Next.js starts with a runtime and you subtract. On a mostly-static page, starting at zero wins and it is not close.
Where Astro is the better answer
- Documentation, blogs, marketing sites. Content with a few interactive bits. Astro's content collections handle frontmatter, typed content and markdown natively, which is otherwise a small pile of glue.
- Anything where the JavaScript budget is the constraint. Slow networks, cheap devices, large markets where the median phone is not a recent one.
- Sites with components from more than one framework. Astro is genuinely agnostic. A React widget and a Svelte widget on one page is a normal thing to do rather than a heroic one.
Where Next.js is the better answer
- Shared client state across the page. A cart, a filter panel that drives a grid, an editor. Astro's islands are isolated by design; making them talk means reaching for a store outside the framework, and at that point you are building what React already does.
- Authenticated application surfaces. Anything where most of the page changes per user, and rendering strategy has to be decided per route rather than per component.
- Mixed static and dynamic in one codebase. A catalogue that must be generated at build time and a checkout that must not. The rendering model is designed for exactly this split.
The trap in the middle
The case that goes wrong is the site that starts as content and grows an application inside it. A docs site adds a playground. A marketing site adds a configurator, then an account area.
Islands handle one of those. Three of them sharing state is where teams start writing their own bridge - and a hand-rolled state layer between isolated islands is worse than either framework's answer.
If you can see that trajectory when you choose, weight it. If you genuinely cannot, Astro is the cheaper mistake: a static site is easier to move off than an application.
What this is not about
SEO. Both produce server-rendered HTML. Neither has an inherent advantage, and the things that actually decide rankings - canonicals, sitemaps, structured data, Core Web Vitals - are your work in either.
Speed. Astro's page weight advantage is real and it is about JavaScript, not about rendering. A well-built Next.js site with a disciplined client boundary is fast. A careless one is not, and neither is a careless Astro site with five unnecessary islands.
If the answer to the opening question is "almost none of it", you may not need a React framework at all.