Astro review: the right tool for content sites, and the wrong one for apps
Filed under Review
By Gerald · 7 September 2026
There are two products called Astro. This review is about the web framework at astro.build, not Astro by Astronomer, which is a managed Apache Airflow product for data pipelines. If you searched for "Astro" and landed here looking for data orchestration, you want the other one.
Astro is the right choice for a blog, marketing site, or documentation site, because it ships close to zero JavaScript by default and gets out of your way. It is the wrong choice once most of a page needs to be interactive, because the thing Astro is built to avoid (shipping a client-side app) becomes the thing you actually need.
What Astro is optimising for
Most frameworks start from the assumption that your page is an application: state, interactivity, client-side routing. Astro starts from the opposite assumption. Most of the web is documents, not applications, and documents do not need a JavaScript runtime to be useful. Astro renders your components to static HTML at build time and ships no JavaScript for that HTML unless you explicitly ask for it.
That single decision explains almost everything else about the framework. Build outputs are small. Lighthouse scores are easy to hit. The dev server has less work to do because there is less client-side machinery to bundle. None of this is a trick. It is what happens when a framework treats JavaScript as an opt-in cost instead of a default.
Islands architecture, explained without the diagram
"Islands" is the name for how Astro adds interactivity back in when you need it. Instead of hydrating an entire page as one React (or Vue, or Svelte) application, you mark individual components as islands, and only those components ship JavaScript and become interactive. The rest of the page stays static HTML.
A pricing page is a good example. The headline, the copy, the feature table: none of that needs to run in the browser. A currency toggle or an FAQ accordion does. In Astro, you write the whole page as normal components, then add a directive to the toggle component telling Astro to hydrate just that piece. The headline never ships a script tag. The toggle does.
Astro 6, released in 2026, extended this idea to the server with server islands: components that render per-request on the server while the rest of the page stays static, so you can mix a cached static shell with a personalized block (an account name, a live price) without turning the whole page into a dynamic route. It is the same philosophy applied one level deeper: keep as much of the page static as the content allows, and only pay a dynamic cost where the content genuinely requires it.
The tradeoff is conceptual overhead. You have to think about which components are islands and which hydration strategy each one uses (on page load, when visible, when idle). For a five-component blog that is trivial. For a page where twenty components are interactive, deciding the hydration strategy for each one is its own kind of maintenance work, and at that point you have mostly recreated the problem islands were meant to avoid.
Content collections and the authoring experience
Astro's content system, now built on the Content Layer API introduced in Astro 5 and extended in Astro 6, is the part I actually enjoy day to day. You define a schema for your content type (blog post, product, documentation page) using Zod, and Astro validates every Markdown or MDX file against it at build time. A missing frontmatter field is a build error, not a runtime surprise three months later when someone forgets to set a date.
The Content Layer also unifies loading from local files and from external sources such as a headless CMS through the same loader interface, so a site that starts with local Markdown and later moves its content into a CMS does not need a full rewrite of the templating layer, only a different loader.
For a site with a hundred posts, this is a build that finishes before you have looked away from the terminal. For a marketing team publishing frequently, type-checked frontmatter catches the kind of small mistake that used to only show up after a broken page went live.
I moved a client's documentation site from a hand-rolled Markdown pipeline to Astro's content collections over a weekend. The schema caught four posts with a missing publish date on the first build, all of which had been silently broken for months under the old system. That is the kind of bug a type system is good at finding and a human reviewer is bad at noticing.
Where Astro stops being the right choice
Islands work because most of the page is static and a small part is interactive. That assumption breaks down for dashboards, admin panels, and anything where the majority of the UI is stateful. If eighteen of your twenty components are islands, you have not avoided shipping a client-side app. You have shipped one anyway, with extra ceremony around which parts hydrate when.
The honest signal to watch for is this: if you are writing more code to manage hydration boundaries than you would have written just building the page as a normal React or Vue app, Astro is adding friction rather than removing it. That point arrives earlier than most teams expect, usually somewhere around "most of what the user sees needs to react to their actions."
Migrating off Astro once you hit that wall is not free, but it is not a full rewrite either if you were disciplined about keeping business logic in framework-agnostic functions rather than inside Astro components. The templates change. The data-fetching and validation logic, if you wrote it as plain TypeScript, mostly does not.
Build times and hosting
Astro's build times scale well for content-heavy sites because most output is static HTML that does not require a running server to serve. Official adapters exist for Vercel, Netlify, Cloudflare, and Node, so you can deploy the static output to any of those, or add server rendering with the matching adapter if part of the site needs it.
For deploying a frontend for free, the same free tiers that work for a plain static React build apply to Astro's static output, since the result is the same kind of asset: HTML, CSS, and a small amount of JavaScript. If you later add server islands or on-demand rendering, you will want Vercel compared with Netlify to decide where that dynamic piece runs best.
A static Astro build also has no server to keep warm and no cold start to wait on, which is a real difference from hosting a server-rendered Next.js route on a platform that spins functions down between requests. For a content site that is mostly read traffic, that is one less operational concern to think about at all.
Who should use Astro
- A blog, documentation site, or marketing site where most pages are read, not operated
- A team that wants strong Lighthouse scores without manually auditing every bundle
- A site that will occasionally need a widget or two, not an app's worth of interactivity
Who should skip it
- A dashboard, internal tool, or product where most of the UI is stateful and interactive
- A team that would rather reach for Vite directly and build a single-page app with full control, which is the route Flow itself takes
- Anyone choosing based on Lighthouse scores alone without checking whether their actual page is mostly static
Frequently asked questions
Is Astro better than Next.js for a blog? For a content-first site, Astro usually ships less JavaScript by default and requires less configuration to get a fast result, because it starts from the assumption that most pages are static. Next.js is the stronger choice once the site needs a genuine mix of static content and complex server-rendered application logic in the same codebase.
Can I build a web app in Astro? You can, using islands for interactive pieces, but Astro's advantage shrinks as the proportion of interactive UI grows. A site or app where most components are stateful is usually a better fit for Vite with a framework like React, or a full-stack framework like Next.js.
Does Astro work with React components? Yes. Astro supports React, Vue, Svelte, Solid, Preact, and plain HTML components in the same project through official integrations, and you can mix frameworks on the same page if you genuinely need to, though most teams pick one.
Is Astro good for SEO? Astro's default output is static HTML with minimal JavaScript, which crawlers render without needing to execute scripts. That is a genuine advantage for SEO-sensitive content sites, on top of the type-checked content collections that reduce broken metadata.
How hard is it to migrate off Astro? It depends on how much business logic lives inside Astro-specific templating versus plain, framework-agnostic functions. Well-separated logic ports over with moderate effort. Logic tightly coupled to Astro's component and hydration model takes longer to unwind.
Related reading
My verdict
Astro is the best content-site framework I have tried, and I would reach for it again for a blog or docs site without hesitation. The moment a project's real job is being an application rather than a document, I would build it in Vite or Next.js instead, not fight islands into doing something they were never meant to do.