All guides

Why Astro is a great framework for simple content sites

Development6 min read

Most brochure sites, documentation sites and marketing sites are built on frameworks that were designed for applications. A React or Vue app ships a runtime to the browser, rehydrates the page after it arrives, and only then becomes interactive. That is a reasonable trade when you are building a dashboard with sorting, filtering and live state. It is a strange trade when the page in question is an about page with a heading, three paragraphs and a contact link.

Astro exists for the second case, and it is the reason this site is built on it.

Zero JavaScript by default

The central design decision is easy to state. Astro renders your components to HTML at build time and ships no JavaScript to the browser unless you ask for it. A component written in .astro syntax runs on the server, produces markup, and then stops existing. No runtime to download. No hydration step, and no client-side router waiting to take over navigation.

When you do need interactivity, you opt into it one component at a time. Astro calls these islands: a search box, a carousel, a pricing calculator, each hydrated independently with a directive like client:load or client:visible. The rest of the page stays static HTML. A site with one interactive widget ships the JavaScript for that one widget, not for the whole page.

This inverts the usual default. In a typical single-page-application setup you start with a JavaScript bundle and work to reduce it. In Astro you start at zero and add only what earns its place. For a content site, that difference compounds across every page you publish.

What the field data says

Framework marketing claims are cheap. What matters is data collected from real browsers rather than lab tests on a developer’s machine.

Google’s Chrome User Experience Report gathers Core Web Vitals from actual Chrome users, and the HTTP Archive joins that dataset against detected technologies. Astro’s own 2023 Web Framework Performance Report, published 7 March 2023, used those sources and found Astro was the only framework where more than half of tracked sites passed Core Web Vitals, against an all-site average of 40.5%. Next.js sat near 25% and Nuxt near 20%.

That report is three years old now, and Astro published it about itself, so treat it as a starting point rather than a verdict. More recent third-party numbers point the same way. The WebVitals.tools framework benchmark from April 2026, built from CrUX mobile origin data joined to Wappalyzer detection and excluding origins with fewer than 1,000 samples, puts Astro at an 84% mobile pass rate, ahead of SvelteKit at 75%, Next.js at 68%, Nuxt at 60% and Gatsby at 53%. For context, the global pass rate across all origins in that period was around 56%.

Why this matters more than it used to

In March 2024 Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vitals metric. FID measured only the delay before the browser began processing your first interaction, which was forgiving: a page could be clogged with JavaScript and still score well, because the first click was often registered quickly even if nothing visibly happened for another second.

INP measures the full path from interaction to the next painted frame, across the whole visit rather than the first tap. Long tasks on the main thread now show up in the score. Since parsing, compiling and executing JavaScript is the most common source of long tasks, the metric change quietly penalised exactly the architecture that content sites had least reason to adopt. Shipping less JavaScript became the most direct lever on one of the three metrics Google reports. That was a real shift.

A migration with numbers attached

The Yarn package manager moved its documentation site from Docusaurus to Astro. In the case study published by Lucky Media, the Lighthouse performance score went from 85 to 99, alongside 100 for accessibility and 100 for best practices. The team attributed the gain to the island architecture and shipping zero JavaScript by default, rather than to any single micro-optimisation.

Documentation is close to the ideal case, which is worth saying plainly. Text, navigation and a search box. That is precisely the shape of site where the architecture pays off most.

The honest caveat

The framework is not the whole story, and any guide that implies otherwise is selling something. The same WebVitals.tools analysis notes that framework choice accounts for roughly the bottom ten percentage points of a site’s Core Web Vitals pass rate. Hosting and image handling account for most of the rest.

A badly built Astro site served from a slow origin with unoptimised hero images will lose to a carefully built Next.js site on a good CDN. What Astro gives you is a better starting position and a default that is hard to accidentally ruin. You still have to compress your images, pick sensible fonts and put the site somewhere fast.

When Astro is the wrong answer

Astro is a poor fit when the page is the application. Anything with heavy shared client state, real-time updates, complex authenticated views or dozens of interdependent interactive components will fight the model. At that point you are opting so much back into hydration that you have rebuilt a single-page app with extra steps, and a framework built for that job will serve you better.

The dividing line we use: if the content mostly sits still and the interactivity is local to a few components, Astro. If the interactivity is the product, something else.

Where it sits now

Astro 5 added a content layer for loading content from any source, plus server islands for mixing personalised dynamic fragments into otherwise static pages. Astro 7.0 landed on 22 June 2026 with the .astro compiler rewritten in Rust, a Rust-based Markdown pipeline, and Vite 8 with the Rolldown bundler underneath. Version 7.1 followed in July. The project has been through several major versions without abandoning the original premise, which is a reasonable signal for something you intend to keep running for years.

This site runs Astro 7, and the numbers are checkable. The page you are reading is a single HTML file. The production build emits no JavaScript bundle at all: the only first-party script on the page is a few lines inlined in the head to run the scroll animation and the mobile menu. Everything else you can see is markup and CSS.

References