What is Astro in plain English?

Astro is a web framework — a set of tools developers use to build websites. Its defining choice is that pages are rendered into plain HTML before anyone visits, with JavaScript shipped only where it earns its keep. Most other modern frameworks ship a JavaScript application to the browser and let it render the page on the user's device. Astro inverts that: HTML first, JavaScript second. The result is sites that load fast, cost almost nothing to host, and stay simple.

Is Astro a framework or a static site generator?

It's both, and the distinction matters less than the marketing suggests. Astro can build pages as fully static files at build time (static site generator behaviour) or render them on a server at request time (framework behaviour). The same project can mix both, page by page. The naming debate is about historical lineage — Astro started in the static-site-generator family and grew the dynamic capabilities later — but in practice it's a hybrid framework that lets you choose the rendering mode per route.

How is Astro different from React or Next.js?

React is a JavaScript library for building user interfaces — it expects you to ship code to the browser that renders and re-renders the UI based on state changes. Next.js is a React framework that adds server-side rendering, routing, and data fetching. Astro starts from the opposite assumption: most of your site doesn't change after it's built, so render it as HTML and ship nothing. Where you do need interactivity, Astro lets you drop in a React, Vue, Svelte, or Solid component as an 'island' that hydrates independently. The default is static; interactivity is opt-in.

What is Astro Islands architecture?

Islands architecture is Astro's way of mixing static HTML with interactive components. The page renders as static HTML by default. Wherever you need interactivity — a search bar, a carousel, a contact form — you mark a component as a client island. Only that island ships JavaScript to the browser; the rest of the page stays as HTML. Each island hydrates independently, which means a slow island doesn't block the rest of the page. It's the architectural answer to 'I want HTML by default but JavaScript where I need it' without the trade-offs of full client-side rendering.

Is Astro good for SEO?

Yes — and the reason is architectural. Astro ships HTML on first request, which is exactly the shape Google's crawlers prefer. Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint) are easier to pass on Astro than on most JavaScript-heavy frameworks because the page is already rendered before the browser has to do any work. Astro also handles sitemaps, canonical URLs, structured data, and meta tags at the framework level. You can still misconfigure it — trailing slashes and SSR mode have their own traps — but Astro starts SEO-friendly by default.

Is Astro free to use?

Yes. Astro is open-source software released under the MIT licence. There's no paid tier, no usage-based pricing, no vendor lock-in. The framework itself is free; you only pay for hosting (which can be free on Netlify or Cloudflare Pages for typical small-business traffic), a domain (a few pounds a year), and whoever builds and maintains the site. Astro is funded by sponsorship and by integration partnerships, not by selling the framework to developers.

Who built Astro and when?

Astro was started in 2021 by Fred Schott, with a core team that now operates as a small open-source company. The 1.0 release shipped in August 2022; the 5.0 release in late 2024 brought major changes including content collections, server islands, and improved SSR. The framework is used in production by sites including Wired, IGN, Trivago's marketing surfaces, Firebase's documentation, and tens of thousands of small business and developer sites. It's no longer experimental.

When should a developer choose Astro over Next.js or other frameworks?

Choose Astro when the site is mostly content — marketing sites, documentation, blogs, brochure sites, content-heavy ecommerce front-ends. Choose Next.js or another React framework when the site is mostly application — dashboards, logged-in user experiences, real-time interactive products. The decision rule is whether the dominant question is 'how do I render this content fast' (Astro) or 'how do I manage this state across pages' (Next.js). Both can technically do the other's job; neither is the right shape for it.

What Is Astro? The Framework, Explained Plainly

Astro is a web framework whose defining choice is to ship HTML, not JavaScript. That single decision — render at build time, send finished pages, opt into interactivity only where it earns its keep — separates Astro from almost every other modern framework. This piece is the plain answer to what that actually means, who it’s for, and when to reach for it. If you landed here looking for a non-technical explanation of why a website is built on Astro, the companion piece for business owners is the route you want.

The One-Sentence Answer

Astro is an open-source web framework that builds your pages into plain HTML files at build time and ships almost no JavaScript to the browser by default. Where you need interactivity — a search bar, a form, a live counter — you drop in a component from React, Vue, Svelte, or Solid, and only that component hydrates. The rest of the page stays as HTML.

That’s the whole architecture, in one line. The rest of this piece is the working underneath it.

What a Web Framework Actually Is

A web framework is a structured set of tools, conventions, and runtime behaviour that a developer uses to build a website without re-solving the same problems on every project. The framework handles routing (which URL renders which page), templating (how data becomes HTML), asset bundling (combining and compressing CSS and JavaScript), and the build or render pipeline (how source files become the website a visitor sees).

Different frameworks make different default choices about what work happens where. Some render every page on the server when a visitor arrives. Some render in the browser using JavaScript. Some build everything ahead of time into static files. Astro’s defining choice is the last one — and the consequences ripple through everything the framework does well and everything it isn’t built for.

A framework’s defaults are its real opinion. Astro’s default is HTML. Most of what’s interesting about the framework follows from that single choice.

How Astro Is Different from React, Vue, and Next.js

React is a JavaScript library for building user interfaces. It expects to run in the browser, render the UI from JavaScript, and re-render whenever state changes. React on its own doesn’t handle routing, build configuration, or data fetching — it’s a component model, not a framework. To use React in a real production site, you typically reach for a framework that wraps it, and Next.js is the dominant choice.

Next.js is a React framework. It adds the missing pieces: file-based routing, server-side rendering, data fetching patterns, image optimisation, API routes. Next.js can render pages on the server, statically at build time, or in the browser — but the framework’s default shape assumes you want React running in the browser to handle client-side interactivity. Even with static export, a typical Next.js page ships a JavaScript bundle to hydrate the React tree.

Astro starts from a different question. What if most of the page doesn’t need to be a React application? What if you could render the page as HTML once, at build time, and ship that finished HTML to every visitor? You’d save the bundle download, the parse time, the hydration cost. You’d get a faster first paint, better Core Web Vitals, and lower hosting bills.

Astro’s answer is to do exactly that — and to let you drop in a React component (or Vue, or Svelte, or Solid) when you genuinely need client-side behaviour. The framework calls these client islands, and they’re the killer feature.

Islands Architecture, Explained

Islands architecture is Astro’s term for mixing static HTML with interactive components on the same page. Imagine a marketing site: a hero section, a few service blocks, a customer testimonial carousel, a contact form, a footer. In a React framework, the entire page is a React tree — every section ships JavaScript that hydrates, even the parts that don’t change.

In Astro, the hero, service blocks, testimonial copy, and footer render as plain HTML. Only the carousel and the form are marked as client islands. When the page loads, the browser receives finished HTML for everything except those two islands; each island then independently fetches its own JavaScript and hydrates. The static parts of the page are interactive immediately — they’re plain HTML — and the islands wake up as soon as their bundles arrive.

90%+ less JavaScript

typical Astro page payload compared to an equivalent React/Next.js page rendering the same content

The technical primitive is a directive in the component tag: client:load, client:idle, client:visible, or client:only. Each directive tells Astro when to hydrate the island. client:visible is particularly clever — the island only loads JavaScript when it enters the viewport, which means a long-scroll page can ship almost no JavaScript at all and still feel fully interactive once the user reaches each section.

This is the architectural answer to a problem the React ecosystem has been working around for a decade. Server components, partial hydration, the app router in Next.js 13+ — all of these are attempts to bring the React tree closer to the Astro model. Astro just started there.

What Astro Is Built For

Astro is built for content-driven sites. That’s the honest framing.

Marketing sites — landing pages, service pages, about pages, contact pages. Most of the content doesn’t change between visits. Render it once, serve it fast.
Documentation sites — technical docs, knowledge bases, wikis. The content is the product. Static HTML serves it best.
Blogs and content publishers — articles, magazines, newsletters. Markdown-first authoring, fast loads, clean SEO.
E-commerce content layers — product information, category pages, brand storytelling — paired with a headless commerce backend (Shopify Storefront API, Snipcart, Commerce.js) for the cart and checkout.
Portfolio and agency sites — the case studies, the contact form, the about page. Speed is a credibility signal.
Small business sites — service businesses, trades, consultancies, B2B suppliers. The 80% case where the site is mostly informational and needs to load fast.

For these use cases, Astro starts in the right place. The defaults are aligned with the goal. The framework doesn’t fight you.

What Astro Isn’t Built For

Astro is not the right framework for applications. If your site is fundamentally an interactive product — a dashboard, a logged-in user experience, a real-time collaborative tool, a SaaS interface, a marketplace with complex state — Astro is the wrong shape. You can technically build these on Astro, but you’d be ignoring the framework’s strengths and reaching outside its defaults for every page.

The honest test: does the site spend most of its life rendering content that doesn’t change, or most of its life responding to user actions? Content sites are Astro. Applications are Next.js, Remix, SvelteKit, or whatever React-equivalent your team is fluent in. The Astro vs Next.js comparison covers that decision in detail.

The Astro Component Model

Astro components look like HTML with a frontmatter section that contains the JavaScript. A typical .astro file:

---
const title = "Hello world";
const items = ["First", "Second", "Third"];
---

<h1>{title}</h1>
<ul>
  {items.map((item) => <li>{item}</li>)}
</ul>

The fenced section at the top runs at build time (or on the server, depending on render mode). The template section is HTML with embedded expressions in curly braces. There’s no virtual DOM, no reactivity model, no hooks — because by default, the component renders once and ships HTML. If you need reactivity, you import a React, Vue, Svelte, or Solid component and mark it as an island.

This is the part most developers find immediately comfortable on first read. The syntax is closer to HTML than to JSX. The component model is closer to a templating engine than to a UI framework. The complexity surface is small.

The fastest framework to learn is the one that looks like what it’s replacing. Astro looks like HTML. That’s not an accident.

Astro Routing, Content Collections, and Other Framework Pieces

Beyond the rendering model, Astro provides the standard framework pieces you’d expect:

File-based routing. A file at src/pages/about.astro renders at /about. Dynamic routes use bracket syntax — src/pages/blog/[slug].astro matches any URL under /blog/.
Content collections. Markdown and MDX files in src/content/ are typed, validated, and queryable. This is how you’d build a blog, a documentation site, or any content-heavy section.
Server-side rendering. Set output: 'server' in the config and pages render on each request instead of at build time. Useful for personalisation, authentication, or anywhere build-time rendering doesn’t fit.
Server islands. Released in Astro 5, these let you statically render most of the page and inject server-rendered content per-request into specific slots. The performance of a static page with the dynamism of an SSR page where you need it.
Integrations. First-party integrations for Tailwind CSS, MDX, sitemaps, image optimisation, RSS feeds, and the major UI frameworks. The integration system is straightforward — most are a one-line install.

The framework is small enough to learn in a weekend if you’re already a web developer. The official tutorial walks through building a blog from scratch and takes a couple of hours.

Hosting and Deploying an Astro Site

Astro builds to a directory of static files (in static mode) or to a Node-compatible server runtime (in SSR mode). The framework officially supports Netlify, Vercel, Cloudflare Pages, AWS Amplify, Deno Deploy, GitHub Pages, and any static host that serves a directory. There’s no opinionated hosting partner you have to use.

For a typical content site, Netlify or Cloudflare Pages on the free tier is the standard answer — sub-second loads from edge nodes, free SSL, continuous deployment from Git, generous bandwidth. The Astro Hosting UK page covers what each platform does well in the UK context.

When Developers Reach for Astro

I’ll name the patterns that send developers towards Astro, because they tend to repeat.

The marketing site for a React SaaS product. The app itself is Next.js or Vite + React; the marketing site is Astro because it doesn’t need to be the app and shouldn’t carry the app’s complexity.
The documentation site for an open-source project. Markdown-first, fast loads, easy MDX integration for interactive examples where needed.
The portfolio rebuild. A senior developer with a Gatsby or Hugo site from five years ago who wants something that still feels current in five more years.
The agency client brochure site. When the agency’s developer instinct says “this should be fast and stay fast for a decade” and the budget doesn’t support a maintenance retainer.
The blog migration off WordPress. Same content, different runtime model. The author keeps writing Markdown; the site stops needing PHP, MySQL, and twelve plugins.

These are the gravity wells. If your project shape matches any of them, you’re not the first to reach for Astro for that reason.

How to Learn Astro

The official documentation at docs.astro.build is the canonical learning route — and unlike most framework docs, it’s genuinely well-written. Start with the install guide, work through the official tutorial (build a blog), then read the islands architecture page. That’s enough to be productive in a day or two.

After that, the gaps are usually the integration-specific parts: MDX content authoring, image optimisation conventions, deploying to your chosen host, integrating a headless CMS if you need one. Each has a dedicated page in the docs. The community Discord is active and helpful for the questions the docs don’t yet cover.

If you want to see real-world Astro source code, several large sites have open-sourced their Astro implementations — the Astro docs site itself is built on Astro, as are the docs for Cloudflare, Firebase, and Bun.

The Honest Verdict

Astro is a strong default choice for content-driven web projects in 2026. The framework is mature (released August 2022, on its fifth major version, used in production by sites you’ve heard of), the developer experience is unusually polished for an open-source project, and the architectural choice — HTML by default, JavaScript where it earns its keep — has aged well as the broader frontend ecosystem has caught up to the same idea.

It is not the right tool for every job. Applications belong on application frameworks. Anywhere state, interactivity, or real-time behaviour dominates the work, Astro is the wrong shape. The honest version is that most websites are not applications, and for the websites that aren’t, Astro starts in the right place.

If you arrived here from a developer-curious search and want to go deeper, the Astro vs Next.js comparison is the next piece. If you arrived because someone proposed building you a website on Astro and you wanted to know what that means in practice, the plain-English explanation for business owners is the one written for that audience.

If you’re a UK business considering an Astro build — whether that’s a migration from WordPress or Wix, or a new site from scratch — the Astro Website Design service page covers what I build, how it costs, and what’s included. The faster route is to send me the URL of what you have now and I’ll tell you straight whether Astro is the right fit for your specific situation.