Astro 5: when content and applications converge

Astro 5 shipped on December 3, 2024 and reaches September 2025 with nine months of runtime, enough for launch impressions to be tested against real experience. This post is not a day-one review; it is a time-tested assessment of what has worked, what has been hard, and where Astro has definitively marked the JavaScript ecosystem. We already covered Astro’s island model when it debuted, in Astro and Islands: The Web That Sends Less JavaScript; this piece picks up the story five versions later.

Key takeaways

• Astro 5’s Content Layer generalizes Content Collections to cover any data source (remote CMS, API, database) as a typed collection with Zod schema and build-time guarantees.

• Server Islands allows including on-demand render blocks inside static pages without making the whole page dynamic: TTFB stays at 50 ms from CDN even when the block shows personalized content.

• A typical blog page in Astro 5 ships less than 10 KB of residual JavaScript, versus ~40 KB in Astro 4, a visible difference on mobile with slow 4G.

• Build time has increased: ~18 s for 500 pages versus ~12 s in Astro 4, due to Content Layer schema validation. It is reviewable with content caching.

• Astro 5 does not compete head-on with Next.js (interaction-heavy apps) or Hugo/Eleventy (purely static content): its space is sites where content and application coexist.

The Content Layer as a real milestone

The most important novelty of Astro 5 is unquestionably the Content Layer. In Astro 4, Content Collections already allowed typing local Markdown and JSON content, but they were limited to repository files. The Content Layer generalizes that concept: any data source can be modeled as a typed collection. Whether it is a remote CMS, an API, a database, or a file system, the Zod schema is the same and so are the build-time guarantees.

The change is deeper than it looks. Over the last three years, the dominant pattern in JavaScript sites has been consuming data at runtime via fetches or GraphQL, with manual typing through external generators. Astro proposes to invert it: content is loaded at build time, validated, typed, and exposed as a queryable collection. For sites where content changes with low-to-medium frequency, this model removes entire layers of runtime complexity.

In my case, I migrated two sites that consumed data from Sanity and a headless WordPress. In both, the Content Layer reduced integration code to a thirty-line adapter describing the schema and calling the CMS API. The rest of the app neither knows nor cares whether the data comes from Sanity, WordPress, or a local file. This uniform abstraction is the most Astro thing there is.

Server Islands: the architecture that fits

The other structural change is the introduction of Server Islands, which generalizes the island model to also allow dynamic-render islands inside static pages. In Astro 4 a page was static or server-rendered, and mixing both required tricks. In Astro 5 a static page can include specific blocks that render on demand, like a user panel, a stock counter, or a personalized section, without making the entire page dynamic.

This fits the reality of most modern websites:

• A blog is 95% static content but 5% dynamic: comments, feedback, authenticated user data.

• A store has a static catalog but dynamic availability.

• A publication has static articles with latest-headline sections or regional personalization.

In all these cases, Server Islands lets you serve the page from CDN as if it were static and only hit the origin for the specific blocks that need it. The implementation uses a special component with a server:defer directive that renders on the server when the page is requested, while the rest of the page comes from CDN. The result is that a page can have 50-millisecond TTFB from CDN and still show personalized content.

Performance measured calmly

A pattern that repeats across the sites I have migrated is that time to content on mobile has dropped noticeably. Not dramatically, but because Astro 5 compiles the framework more strictly and removes more unnecessary JavaScript. A typical blog page that shipped 40 KB of residual JavaScript in Astro 4 now ships less than 10 in Astro 5. On a mid-range device with slow 4G, the difference in first render runs into the hundreds of milliseconds.

The downside is that build time has increased. A site with 500 pages that built in 12 seconds on Astro 4 now takes about 18. The reason is Content Layer schema validation across collections, which is more thorough. For small sites this is irrelevant, but once the number of collections grows, the content-cache configuration is worth reviewing.

Astro logo. Its version 5 consolidates the Content Layer and Server Islands model. It fits sites where static content and dynamic components coexist without sacrificing first-render performance (Image: Unknown authorUnknown author, CC BY-SA 4.0, via Wikimedia Commons)

The React and Vue integration issue

Astro 5 keeps the framework-agnostic idea, but polish varies a lot by framework:

• React 19: excellent, including experimental Server Components support.

• Vue 3: works well but has edge cases with custom directives.

• Svelte 5: solid.

• Solid: good.

• Lit: adequate but less cared for.

The issue is that in a project with multiple frameworks coexisting, some patterns only work well in one. My recommendation, after trying it on real projects, is that if you will mix frameworks, the reason needs to be concrete, not just exploratory. One UI framework per project simplifies experience.

View Transitions mature

Another area that improved much in Astro 5 is View Transitions support, the browser API for animated page transitions without building a full SPA. In Astro 4 it was flagged experimental and had ugly edge cases with nested routes. In Astro 5 it is stable and works in most modern browsers.

The practical effect is that an Astro site can have app-like smooth page transitions, keeping persistent elements across routes, without losing the architectural advantage of being a multi-page site.

Where it still lags

Not everything is positive in Astro 5. Two areas still show resistance:

First, the ecosystem of prebuilt components. Against Next.js, where thousands of components, layouts, and templates are ready to copy, Astro has a much smaller ecosystem. For teams depending on starting fast with existing components, the difference shows.

Second, the learning curve for developers used to React. Astro has its own mental model that is not the classic SPA one. The split between .astro components that are server by default and framework components that are islands takes work to internalize. I have seen teams spend weeks trying to use Next.js patterns in Astro before giving up and adopting the native model.

My take

Astro 5 has finished consolidating its own space among web frameworks. It does not compete head-on with Next.js, which remains the obvious choice for applications where interactivity dominates. It does not compete head-on with Hugo or Eleventy, which remain the kings of purely static content. It competes in a real middle ground: sites where content and application coexist, where most of the UI is static but there are specific dynamic blocks, where SEO and first-render performance matter.

That middle ground turns out to be much bigger than it seemed two years ago. It covers blogs with member areas, publications with personalized comments, portfolios with CMS, small stores with static catalog and dynamic checkout, and documentation sites with enriched product content.

My concrete recommendation is that if you are starting a new project that is not clearly an interaction-heavy application, Astro 5 deserves serious evaluation. You will likely end up with less code, fewer dependencies, and better performance than with Next.js, without giving up the dynamic capabilities you occasionally need. If your project is a highly interactive application, stick with what you already use. The tool is not neutral: it fits some ways of working and clashes with others, and not pretending to fit every case is part of its value.

This article is also available in Spanish: Astro 5: cuando contenido y aplicaciones convergen.

Sources:

1. Official Astro 5.0 announcement on the Astro blog^[1]
2. Content Collections and the Content Layer API, Astro documentation^[2]
3. Server Islands, Astro documentation^[3]
4. astro@5.0.0 release notes on GitHub^[4]

Frequently asked questions

Can I show personalized content on a static Astro 5 page without losing CDN-level TTFB?

Yes, with Server Islands. You mark the specific block (a user panel, a stock counter, a personalized section) with the server:defer directive. It renders on the server when the page is requested, while the rest is served from CDN as static. The result is a 50-millisecond TTFB from CDN with personalized content, without making the whole page dynamic as Astro 4 required.

Why does my site build more slowly after migrating to Astro 5?

Because of Content Layer schema validation, which is now applied more thoroughly across all collections. A 500-page site that built in about 12 seconds on Astro 4 takes about 18 on Astro 5. For small sites this is irrelevant; once the number of collections grows, review the content-cache configuration. In exchange, a typical blog page ships less than 10 KB of residual JavaScript versus 40 KB in Astro 4.

Is it a good idea to mix React and Vue in the same Astro 5 project?

Only with a concrete reason, not just to explore. Polish varies by framework. React 19 is excellent, with experimental Server Components support; Svelte 5 is solid; Solid is good; Vue 3 works well but has edge cases with custom directives; Lit is adequate but less cared for. With two or more frameworks coexisting, some patterns only work well in one, so a single UI framework per project simplifies the experience.

Sources

1. Official Astro 5.0 announcement on the Astro blog
2. Content Collections and the Content Layer API, Astro documentation
3. Server Islands, Astro documentation
4. astro@5.0.0 release notes on GitHub