Astro v5: The Beast of the Web

Astro is one of the beasts of the modern web: the framework built for content-driven sites — blogs, marketing, e-commerce — that load fast and have great SEO. With Astro 5.0 (released December 2024), the framework takes a big step: Content Layer to pull content from any source, Server Islands to mix static HTML with dynamic, personalized content on the same page, and a major simplification of how SSG (static site generation) and SSR (server-side rendering) work together. In practice, they’re siblings: static by default, server when you need it.

My portfolio is built 100% in Astro vanilla (no React, Vue, or Svelte on the client) and I use Astro in many of my projects. In this article I cover what Astro is, what v5 brings, and everything you can do with it.

What is Astro?

Astro is the web framework for building content-driven sites: blogs, landing pages, marketing, e-commerce. If you need a site that loads fast and ranks well for SEO, Astro is a strong fit.

Its pillars:

• Zero JS by default: Astro ships HTML and CSS; any JavaScript you add is opt-in (islands). Less JS means less weight and better load times.
• Islands Architecture: Only components that need interactivity are hydrated; the rest stays static. Less work in the browser.
• Multi-framework (optional): You can use React, Vue, Svelte, Solid, etc. only where needed, or stay Astro vanilla like my portfolio: .astro components, a bit of client-side JS if you need it, and that’s it.
• SSG and SSR: By default it generates static HTML at build time. If you add a server adapter (Node, Vercel, Netlify, Cloudflare), you can have routes rendered on-demand on the server.

With v5, Astro doubles down on all of this and adds new tools for content and for mixing static and dynamic on the same page.

Astro 5.0: What’s New

Content Layer

Astro has always been strong on content. With the Content Layer in v5, content collections become a unified, typed layer where content can come from anywhere: Markdown on disk, CMS (Notion, Storyblok, Hygraph, etc.), REST APIs, or asset systems.

• Loaders: Functions that fetch and transform data. You can use built-in loaders (e.g. glob for files) or define your own (an API, a CMS).
• Single API: You define collections in content.config.ts and use them in pages with types and autocomplete.
• Performance: In v5, Markdown collections can build up to 5x faster on content-heavy sites and up to 2x faster for MDX, with lower memory use.

So you can have a blog in Markdown, data from a CMS, and data from an API in the same site, all typed and cached at build time.

Server Islands

Islands on the client (only hydrate what’s needed) were already Astro’s signature. In v5, Server Islands bring the same idea to the server. You can have on one page:

• Static content that never changes (cached on the CDN).
• Dynamic content generated on the server (database, logged-in user).
• Personalized content (avatar, cart, reviews) rendered on-demand.

Before, you had to pick one caching strategy for the whole page. With Server Islands, the base page can be heavily cached and only the dynamic “islands” (with server:defer) are rendered when needed. Each island loads independently: a slow island doesn’t block the rest.

That gives you pages that load instantly from the edge, with only the personalized parts filled in afterward. Using Server Islands requires a server adapter (Node, Vercel, Netlify, Cloudflare).

SSG and SSR: Siblings, Not Enemies

In Astro, SSG (static site generation) and SSR (server-side rendering) are siblings: same framework, two output modes.

• Default: static (SSG). Astro pre-renders pages at build time and outputs static HTML. Fast, cacheable, ideal for content that doesn’t change per request.
• When you need it: server (SSR). You add an adapter (e.g. @astrojs/node, @astrojs/vercel) and mark routes with prerender = false. Those routes are rendered on-demand on the server.

In v5 the config is simplified: hybrid mode is merged into static. You no longer choose output: "hybrid"; you use output: "static" (default), and if you set prerender = false on a route, Astro uses SSR only for that route. No need to remember a matrix of modes: static by default, server where you mark it.

Summary: SSG for most pages; SSR for login, dashboards, per-user or per-request content. Same project, same mindset.

astro:env (Type-Safe Environment Variables)

In v5, astro:env lets you define environment variables in a typed, safe way:

• Specify whether a variable is for client or server.
• Mark variables as secret (API keys, etc.) so they’re not exposed to the client or inlined in the server build.
• Define whether they’re required or optional and their type (string, number, boolean, enum).

You configure them in astro.config.mjs and import where needed, e.g. import { STRIPE_API_KEY } from 'astro:env/server', with types and validation before the server boots.

Vite 6

Astro 5 runs on Vite 6. For most projects you don’t change any code; the benefit is a dev server and build that align better with how code runs in production. Long term, this enables better support for environments like Cloudflare or edge runtimes.

Experimental: Responsive Images and SVG as Component

In v5 there are useful experimental flags:

• Responsive images: Cropping with fit and position, and responsive layouts that generate correct srcset and sizes.
• SVG as component: Import an .svg and use it as an Astro component, passing width, height, fill, stroke, etc.

Enable them in astro.config.mjs with experimental.responsiveImages and experimental.svg.

What You Can Do with Astro (Summary)

• Pure static sites (SSG): Blogs, docs, landings. No server if you want; deploy to any static host.
• Hybrid sites: Most routes static, some SSR (forms, auth, per-user content).
• Content from many sources: Markdown, CMS, APIs, via Content Layer and loaders.
• Performance and SEO: Little JS by default, static HTML, islands only where needed.
• Astro vanilla: Like my portfolio: only .astro, Tailwind (or your preferred CSS), sitemap, no UI frameworks on the client. Optionally add React/Vue/Svelte only where you need them.

My Portfolio: 100% Astro Vanilla

This portfolio (sebastiancheikh.com) is built entirely in Astro vanilla. There’s no React, Vue, or Svelte in the client bundle. I use:

• .astro components for layout, sections, and pages.
• Content collections for the blog (Markdown per language).
• Tailwind for styles.
• @astrojs/sitemap for the sitemap.
• Static build (SSG); deploy to a server or CDN.

It’s fast, easy to maintain, and shows that for many sites you don’t need a heavy client framework. I also use Astro in many of my projects: from corporate sites to blogs and landings, for the same reasons: less complexity, better performance, same pleasant DX.

My Personal Perspective

Astro v5 reinforces what Astro already did well (fast, little JS, clear SSG/SSR) and adds Content Layer and Server Islands for more complex sites without losing simplicity when you don’t need them. Unifying “static + server when you ask for it” without confusing hybrid modes is a win.

For portfolios, blogs, documentation, and content sites, Astro remains my first choice. If I need localized interactivity later, I can add an island in React or Vue without rewriting everything. If not, I stay vanilla and the site stays a performance beast.

To try Astro 5: npm create astro@latest. If you already have a project, the official guide is Astro v5. And if you want a real-world example in Astro vanilla, this portfolio is one.