Next.js vs Astro: How Much of Your Page Is Interactive?

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.

The gap is measurable rather than rhetorical. This site ships no client JavaScript of its own on any route, and still carries roughly 186KB gzipped of framework runtime on a first visit. That is close to the floor for a React framework, and it is a floor an Astro page without islands simply does not have. Whether that matters depends entirely on who is visiting: on a fast connection it disappears, and on a mid-range Android phone in a market you are trying to enter, it is a visible part of the time to interactive.

The control each gives you over hydration

This is where the two models differ in practice rather than in principle.

Astro's islands are declared with a directive that says when to hydrate - immediately, when the browser is idle, or when the component scrolls into view. That last one is the interesting one: a component below the fold costs nothing until somebody reaches it, and expressing that is a single attribute.

Next.js has no equivalent per-component switch. A Client Component hydrates as part of the tree it belongs to. You control what ships, which is the more powerful lever, but you do not get "ship this, and start it later" without reaching for dynamic imports and writing the loading behaviour yourself.

Neither model is better in the abstract. Astro's is finer-grained for a page made of mostly-static content with a few live parts. Next.js's is better when the interactive parts are the page.

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.

The content collections point is worth expanding, because it is the part that saves the most time on a content site. Typed frontmatter, validated at build, with the failure arriving as a build error rather than as a blank heading in production, is the kind of thing every content site eventually builds. In Next.js it is a library choice and some glue - this site's own content layer is a few hundred lines of exactly that. In Astro it is the framework.

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.

That asymmetry is the practical heart of this decision. Moving content from Astro to Next.js is mostly moving Markdown files and rewriting templates - the content itself is portable and the URLs need not change. Moving an application out of a framework is a rewrite. When two options are close, the one that is cheaper to be wrong about should win.

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.

Which one is more capable. Astro server-renders, has middleware and can run on the same platforms. Capability is not the constraint here and framing it that way produces the wrong answer, because the question was never what the framework can do - it is what your page costs a visitor.

If the answer to the opening question is "almost none of it", you may not need a React framework at all.