Astro 5: when content and applications converge

Actualizado: 2026-05-03

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 landscape.

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 — 50 ms TTFB from CDN with 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 — 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, whether a remote CMS, an API, a database, or a file system, can be modeled as a typed collection with the same Zod schema and the same 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 I have seen in several sites after migration 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 is several hundred 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 large sites with many collections should review the content-cache configuration.

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 several projects is that if you will mix frameworks, the reason needs to be concrete, not just exploratory. One UI framework per project simplifies experience.

Mature View Transitions

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 very 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: blogs with member areas, publications with personalized comments, portfolios with CMS, small stores with static catalog and dynamic checkout, 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.