Astro vs Next.js in 2026: which framework to choose?

« Astro or Next.js? » The question comes up in almost every technical scoping session, and it's poorly framed. The two tools don't solve the same problem. Treating the choice as a duel is like asking whether you need a lorry or a saloon car: the answer depends entirely on what you're carrying.

This site runs on Astro 7. Here's why, with figures from our own migration rather than a generic comparison table.

What this site actually sends to the browser

Figures recorded on the playdigital.ch homepage, in production:

• 60 KB of HTML, fully pre-rendered at build time
• 152 KB of JavaScript, of which 136 KB are our animations (GSAP and Lenis) — an aesthetic choice, not an expense imposed by the framework
• 61 KB of CSS for the 219 pages of the site
• 219 pages generated in just over six seconds

The important point lies elsewhere: our Keystatic administration interface weighs 2.7 MB of JavaScript. This file never reaches a visitor. It's only loaded on /keystatic, behind authentication. This is island architecture: interactive code is sent where it's needed, and nowhere else.

With a framework that hydrates the entire application, this separation requires deliberate work. With Astro, it's the default.

The real dividing line

It doesn't run between « brochure site » and « application ». It runs here:

Are your pages identical for all visitors, or do they depend on who's looking?

A service page, an article, a project sheet: identical for everyone. They can be calculated once, at build time, and served as files. That's Astro's territory.

A dashboard, a shopping cart, a client portal, a list filtered by access rights: different on each visit. You need a server that renders on demand, a session layer, per-user cache management. That's Next.js's territory, and it covers it better than Astro.

Most corporate websites are 90% in the first category and 10% in the second. The trap is choosing the tool for the 10%, and making the remaining 90% pay the price of a full application.

What Next.js does better

Let's be honest, the list is real:

• Per-user rendering. Server Components, streaming, granular revalidation: nothing in Astro matches this maturity when every page depends on a session.
• Applications heavy on state. Multi-step forms, optimistic updates, client-server synchronisation: the React ecosystem is at home here.
• The developer pool. Recruiting for Next.js is easier. It's not a technical argument, but it's a business argument.
• Vercel. Deployment is frictionless — at the cost of dependency on a specific hosting provider, which is not neutral for a Swiss company subject to data localisation requirements.

What Astro does better

• JavaScript by default: zero. You add interactivity where you need it, with the right directive (client:load, client:visible, client:idle). The reverse — removing JavaScript from a hydrated application — is much harder.
• Multilingual without acrobatics. Three languages, different slugs per language, complete hreflang tags across 219 pages: that's file routing, not configuration.
• Freedom of library. React, Svelte, Vue or nothing at all, in the same project. Our administration is in React; the public site doesn't contain a line of it.
• Hosting wherever you want. A Node adapter, a container, your server. We serve this site from a VPS in Satigny.

Three questions to decide

1. What proportion of your pages depends on the visitor's identity? Below 20%, Astro. Above 60%, Next.js. In between, the next question settles it.
2. Who will maintain this project in two years? A team settled on React has good reasons to stay on Next.js. Team consistency often outweighs a few kilobytes.
3. Where must your data live? If the answer is « in Switzerland, on infrastructure we control », the comfort of Vercel disappears from the picture.

Our position

We use both. For a multilingual content site with integrated administration — exactly the case of playdigital.ch — Astro delivers a better result for lower maintenance cost. For a client portal with accounts, permissions and per-user data, we go with Next.js without hesitation.

What's wrong is the idea that one choice is better than the other in absolute terms. What's costly is choosing before you've answered the three questions above.