Astro against Next for content sites, dogfooded on this one

The claim, and the evidence

Every page on this site ships no framework JavaScript at all. The only script is analytics, two async tags that nothing renders from. The mobile navigation, which is the only interactive element above the fold, is a checkbox and two labels with no JavaScript whatsoever. Turn scripting off entirely and the site is identical, minus the analytics call.

That analytics is also worth a sentence, because it is where most sites quietly give up. Google’s own snippet is an inline <script>, and allowing inline execution means script-src 'unsafe-inline' across every page, forever, so that four lines of setup can run. The bootstrap is emitted as a real file from this origin instead, so the Content Security Policy stays strict and nothing on the site executes inline JavaScript.

That is not discipline. It is the default. Astro renders components to HTML at build time and ships no client runtime unless a component explicitly asks to be hydrated.

The React integration is not even registered in the config here, because nothing has yet earned it. When I did register it, the build emitted a 195KB client chunk for a site that had no islands. That is the difference in one sentence: in one framework the runtime is opt in, in the other it is present and you work to shrink it.

What decided it

Default weight. For a site whose job is text and proof, the correct amount of client JavaScript is approximately none. Astro gets there by doing nothing. Next gets there with care, discipline, and a bundle analyser, and only for as long as everybody remains careful.

Content as typed data. Astro’s content collections validate frontmatter against a schema at build time. On this site that means a page cannot ship with a title over sixty characters, a description outside seventy to a hundred and fifty five, a missing date, or an em dash. Those are not lint warnings, they fail the build. That mechanism replaces discipline with a compiler, which matters more than any performance number when one person maintains sixty pages.

The canonical, which is personal. The previous version of this site emitted a canonical pointing at the homepage from a shared layout, so every page told Google it was the homepage. That single line is why it never ranked. In the rebuild the canonical is derived from the page’s own path in one layout, there is no parameter to pass a wrong one, and a post build script reads the emitted HTML and fails if any page has more than one. Any framework can be built this way. This one made it natural.

What Astro costs

A smaller ecosystem, so occasionally there is no ready made integration and you write it. Fewer engineers have used it, which is a real hiring consideration for a team even if it is not for me.

And it is genuinely the wrong tool for an authenticated application with per user state on every view. The islands model is a poor fit when the whole page is interactive, and fighting that is worse than using the framework designed for it.

When Next is right

When the product is an application. Authenticated dashboards, per user data on every view, complex client state, an interaction model that is the product rather than the wrapper.

Next is built for exactly that and does it well. Using Astro there means fighting the architecture, which is the same mistake in the opposite direction.

The mistake this decision is actually about

Neither framework is the error. The error is using the application framework for the marketing site because the team already knows it.

That is how you end up serving a 300KB runtime to render three paragraphs and a contact form, and how a marketing site that exists to be found ends up slower than the application it advertises.

The verdict

Astro for content. Next for applications. And whichever you pick, make the SEO invariants structural, because the alternative is trusting that nobody ever adds a second canonical to a shared layout, and that is exactly the bet the previous version of this site lost.