Astro 5 shipped at the end of last year with content layer, server islands, and a meaningfully tighter Vite integration than the previous releases. We have shipped eight client builds on it since the release. Two were marketing sites that would previously have gone to Next.js. Four were content sites that would previously have gone to monolithic WordPress. Two were hybrid builds that paired Astro with a WordPress content backend.
Across the eight projects, the framework has earned a permanent spot in our stack. It has also surprised us in places, and there are project shapes where it is clearly the wrong call. Here is what we have learned.
What Astro is, in 2026
Astro is a server-rendered framework that defaults to shipping zero JavaScript to the browser. The page renders as static HTML on the server (or at build time for static sites), and the framework only sends JavaScript for the specific interactive components that need it. The ‘islands of interactivity’ model.
The framework supports React, Vue, Svelte, Solid, and its own .astro component syntax. Components from any of these can coexist in the same project. The output is real HTML and CSS with selective hydration where you ask for it.
For 2026, the additions that matter are the content layer (a unified way to consume content from CMS sources, markdown, JSON, or APIs) and server islands (the ability to defer-render specific portions of a page on the server after the initial response).
Where Astro 5 has won, on our projects
Content-heavy marketing sites. Sites with a blog, a case study library, a team page, and a few dynamic listings — Astro renders them faster than any other stack we have measured. Initial page weight on a typical marketing build is under 80 kilobytes total, including content. LCP on mobile lands in the 0.8 to 1.4 second range without any tuning.
Headless WordPress front ends. When the project genuinely wants a decoupled front end but does not need the React-ecosystem features that drive most projects to Next.js, Astro is meaningfully simpler to build and operate. The content layer makes WordPress GraphQL or REST consumption clean. The hosting is simpler — Astro deploys to any static host or to Vercel/Netlify equivalents with edge SSR for the dynamic bits.
Pages that would otherwise be over-engineered. A handful of the eight projects had been quoted on Next.js by previous agencies and were sitting at six-figure budgets. The Astro versions came in at 35 to 60 percent of the Next.js quote because the framework simply does not require the engineering depth that a Next.js app does.
Where Astro 5 has surprised us
Server islands are genuinely useful. The pattern — render most of the page immediately, then defer the parts that need fresh data — solves a problem we have been working around for years. Personalization, real-time data (stock levels, pricing tiers), authenticated UI fragments inside otherwise-public pages. Server islands handle these without the architectural overhead of a full SSR-everywhere setup.
The content layer flexibility. The content layer abstraction in 5.x lets us consume content from WordPress, Sanity, Strapi, a markdown directory, or a custom API through the same component interface. A single Astro app can pull from multiple sources without the project becoming a tangle of fetch handlers.
View Transitions integration. Astro’s view transitions support, paired with the native browser API, gives multi-page applications the perceived smoothness of single-page apps without the JavaScript weight. We have shipped this on three of the eight builds. The user experience is meaningfully better and the cost is two lines of configuration.
Where Astro is the wrong call
Heavily interactive applications. If the project is essentially a single-page application — most pages need React state, the user is going to spend most of their session in client-rendered views — Astro is not the right framework. The islands model is a poor fit for an interface that is mostly interactive. Next.js, Remix, or a pure client-rendered React app would all be better.
Projects where the team is deeply invested in React. Astro supports React, but the framework has a learning curve of its own — the .astro syntax, the islands model, the content layer, the integration setup. A team that wants to write ‘just React’ will be more productive on Next.js.
Real-time, multiplayer, or collaborative applications. Anything with live state synchronization, WebSocket-heavy interaction, or real-time collaboration is not what Astro is built for. The architecture is page-oriented. Stateful real-time UIs belong elsewhere.
The performance numbers
Across the eight builds:
- Median LCP on mobile: 1.1 seconds
- Median CLS: 0.02
- Median INP: 65 milliseconds
- Median Total Blocking Time: 30 milliseconds
- Median Lighthouse mobile performance score: 97
These are unusually consistent numbers. For comparison, our Next.js builds across the same period had median Lighthouse mobile scores in the 89-93 range, and our monolithic WordPress builds were in the 84-91 range. Astro is faster, and the gap is not subtle.
The editor question
Astro itself does not have a CMS. The content has to come from somewhere — WordPress, Sanity, Contentful, markdown files in a repo. For most of our client projects, that ‘somewhere’ is WordPress, because the marketing team already knows it.
The Astro + WordPress combination is the pattern we end up shipping most often. WordPress handles the content production and the editorial workflow. Astro renders the front end. The two systems communicate through WPGraphQL or the REST API. The marketing team’s day-to-day does not change. The site’s performance improves dramatically. It is the same pattern we have written about with Next.js, but Astro is cheaper to build and operate for content-driven sites.
The team-shape question
Astro fits a specific kind of team. The team has to be comfortable with multiple front-end syntaxes (the .astro syntax is its own thing, even if the embedded components are React or Vue). The team has to be comfortable with the content layer abstraction, which is meaningfully different from a typical React data-fetching pattern. The team has to accept that the framework is opinionated about where work happens — server first, client only when justified.
For a team that values those opinions, Astro is a productivity multiplier. For a team that wants to write ‘just JavaScript’ or ‘just React’ without learning a framework-specific model, the friction is real and the gains may not be worth it.
The 2026 outlook
Astro 5 is a release where the framework crosses into ‘safe to recommend for production.’ The previous releases were promising but had enough rough edges that we hedged. 5.x has earned the recommendation.
For content-heavy marketing sites, headless WordPress front ends, and decoupled architectures where the front end is page-oriented rather than app-oriented, Astro is now our default in 2026. For projects that want WordPress as the backend with a faster front end, it is the pairing we recommend before Next.js, Gatsby, or any of the other static-site options.
The market for front-end frameworks is more fragmented than it was three years ago, and that is genuinely a good thing. The right framework for a specific project shape now actually exists. Astro has filled a gap that the other frameworks could not fill cleanly.