Home
Astro Agency
Astro vs Next.js

Astro · Comparison

Astro vs Next.js: the shape of your site decides – not a league table.

Most Astro vs Next.js comparisons are written by someone with a stake in the answer: the vendor behind one of the frameworks, or a company selling something adjacent to it. We build websites with Astro and applications with React. Both frameworks are MIT-licensed open source – we earn nothing from either one, only from the build. So there is no scorecard on this page. There is the one distinction that actually holds up in projects: Astro is built for content-driven websites, Next.js for React applications. Between those two poles sits the case most teams actually have.

Get a framework read Jump to the table

Both are in our stack

We build websites with Astro and applications with React – alongside Webflow, Flutter, React Native and SwiftUI. We have no framework to defend.

No stars, no winner

We describe what the two frameworks do differently instead of scoring them. The decision is made by how your site is built, not by a table.

Measurement, not benchmarks

Somebody else's benchmark says little about your site. We measure your Core Web Vitals before and after, using your own field data.

In short

The short answer: content-driven site – Astro. Application with authenticated, stateful, highly interactive surfaces – Next.js. Everything in between comes down to one question: how much of your page is genuinely interactive?
The technical core: Astro strips all client-side JavaScript from components by default; interactivity is opted into per component with a client:* directive. Next.js is built on React – Server Components move a lot of work to the server, but a client runtime is part of the model.
What Next.js genuinely has: a deeper ecosystem, a far larger hiring pool, and everything to do with state, sessions and personalisation. Those are real advantages, not politeness.
What Astro genuinely has: static HTML as the default output, a typed content model via Content Collections with Zod, a free choice of UI library, and a build that can sit on any CDN.
It is not either/or: marketing site in Astro, product in Next.js, split by subdomain or path – a common and usually the most honest arrangement. If you do want to move: Next.js to Astro.

01 — The differences

Astro and Next.js side by side.

Eight dimensions where the two frameworks actually differ – described, not scored. No cell is better in the abstract; each one is better for something specific.

As of August 2026. Astro details follow the official documentation; current major line is Astro 7.
Dimension	Astro	Next.js
Best-fit surface	Astro describes itself as "a JavaScript web framework optimized for building fast, content-driven websites". Marketing sites, blogs, documentation, landing pages, catalogue and case-study pages.	A React framework for applications: surfaces with login, roles, state and personalisation. It builds websites too – just not by the leanest route.
JavaScript delivered by default	By default Astro removes all client-side JavaScript from components. It is added back only where a component explicitly asks for it.	React is the foundation of the page. Server Components shift a lot of work to the server – but as soon as a component becomes interactive, a client runtime share is part of the model.
Rendering model	Multi-page architecture with server rendering as the default. Prerendered is the baseline; individual routes render on demand via `export const prerender = false`. Setting `output: 'server'` flips the default. Client-side routing is opt-in through the built-in `<ClientRouter />`.	Static, server-rendered and incrementally revalidated per route. After the first load the app navigates client-side through the React router – state survives page transitions.
UI layer	Framework-agnostic. Official integrations for React, Preact, Svelte, Vue, SolidJS and Alpine.js. Several of them can be combined on one page – but only inside an `.astro` file.	React, fixed. That is a constraint and a strength at the same time: one model, one ecosystem, one onboarding path for every new hire.
How interactivity is opted into	Per component, with a directive: `client:load` hydrates immediately, `client:idle` when the browser is free, `client:visible` only once the component enters the viewport. Server Islands render server-side after the fact via `server:defer`.	In the App Router components are Server Components by default; `'use client'` marks the boundary at which a component runs in the browser. The granularity is comparable – the default for the whole tree is not.
Hosting and adapter model	A static build is plain HTML and sits on any web server or CDN. On-demand rendering needs an adapter for the target runtime; first-party adapters in the `@astrojs` scope exist for Node, Vercel and Cloudflare.	Self-host as a Node server, or run on serverless platforms. The framework is developed by the hosting company Vercel, so its own platform offers the tightest integration; self-hosting is explicitly supported.
Content modelling	Built in. Content Collections since Astro 2.0: schemas defined with Zod, automatic TypeScript types, querying via `getCollection()`, and built-in caching that holds up across thousands of entries. CMS-agnostic, with documented guides for Storyblok, Sanity, Contentful, Payload, Directus, Keystatic and headless WordPress.	Not built in. Content comes from whatever source or library you pick – an MDX setup, a headless CMS, your own database. More freedom, and correspondingly more assembly and more decisions for your team.
Portability	MIT-licensed open source. The output of a standard build is HTML – it runs anywhere and, at worst, can be kept alive without the framework.	Also MIT-licensed open source. Operation is tied to a runtime rather than to a vendor; some operating modes are simply far more convenient on platforms with the matching infrastructure.

02 — The decision

When each one is the right call.

If you recognise your project in mostly one column, the decision is made. If you recognise it in both, read the section below – that is the normal case.

Choose Astro when …

Your site is, at heart, a publication.

Most of your pages are content: home, services, case studies, blog, careers, landing pages.
Load time and Core Web Vitals are a business objective, because you buy visibility through search and paid media.
You want the bulk of the page delivered as static HTML and only specific components made interactive – a configurator, a search box, filters, a form.
Content should live in a typed, validated model rather than loose files: a typo in the front matter should break the build, not the live page.
Your team is not committed to React – or deliberately should not be, because Svelte, Vue or no UI library at all suits the surface better.
Hosting should stay a free choice: a static build needs no runtime and sits on any CDN.

Choose Next.js when …

Your product is, at heart, an application.

There is login, there are roles and permissions, and a large part of the surface exists only for signed-in users.
State has to survive navigation: multi-step flows, carts, dashboards, editors.
You already have a React team and a React component library. That is a real advantage, not a sunk-cost argument – existing competence is delivery speed.
You need the ecosystem in depth: auth, payments, data layers, tables, form and validation libraries are densest around React.
Hiring matters: React developers are simply more numerous on the market than Astro specialists. For a long-lived product with a growing team, that is a hard argument.
Almost every route is personalised, and per-request server rendering is the rule rather than the exception.

03 — The middle ground

Most projects sit in the middle – and there is a test for that.

Very few projects are a pure brochure or a pure application. Most are a website with a handful of interactive spots – and that is where the decision is genuinely made.

Take your page list and mark every surface that only works when JavaScript runs in the browser: instant search, a pricing configurator, appointment booking, a cart, faceted filters, a map, an interactive chart. Do not mark things that work without it – a navigation menu, an accordion, a form processed on the server.

If the marked share is small and lives in a few clearly bounded areas, Astro is the leaner answer. That is exactly what the Islands Architecture is for. The documentation defines an island as "an enhanced UI component on an otherwise static page of HTML". The rest of the page stays static HTML, and the interactive component receives its JavaScript through a directive – client:visible, for instance, loads it only once it scrolls into view. The paragraph above it receives nothing.

If the marked share runs through nearly every view, or hangs off shared state or a session, Next.js is the leaner answer. With Astro you would then be working against the framework: each island is its own root, and sharing state across many islands turns into engineering. A framework that treats the whole page as an application is simply more honest at that point.

React knowledge is not thrown away

A common misreading: moving to Astro means abandoning React. The opposite is true. Astro is UI-framework-agnostic and ships an official React integration – your existing React components keep running, as islands. A single .astro page can even host components from several frameworks side by side. What goes away is not React; it is the assumption that everything must be React.

The third option nobody puts in the comparison

The marketing site and the product do not have to live in one codebase. A very common and usually clean split: the public website – home, services, pricing, blog, careers – runs on Astro and is maintained by marketing. The application behind the login runs on Next.js and is built by the product team, on app.yourdomain.com or a dedicated path. Both teams then move at their own pace without blocking each other. When the marketing pages currently sit in the same Next.js repository and every copy change requires a product deploy, that is usually the real trigger for a move – not load time.

Why there is no percentage on this page

Snappy percentage claims circulate about both frameworks. We publish none of them, because they shift with every release and every measurement run and say nothing about your site. What can be stated qualitatively and defended: a page that ships no client-side JavaScript has less to execute than a page that ships some. What that means for your numbers is something we measure on your project – Lighthouse in the lab plus your own field data from the Chrome User Experience report, before and after. More on that under Astro performance optimisation.

The question both frameworks leave open: who maintains this later?

A framework comparison usually stops at the build. Operations start right after it. That is why we put a modern AI stack on top: our clients can edit their website by chat – through a Telegram bot, for example. Change a paragraph, publish a blog post, swap an image, correct a price: as a message, not as a CMS session.

It works because Astro content lives in a typed, schema-validated content model – Content Collections with Zod – or in a headless CMS with an API. Either one is addressable by a machine: the schema defines which fields exist and what counts as valid, and therefore acts as a guard rail. An agent can only fill fields that exist, in formats that validate; a bad edit fails the build instead of the live page. Every change lands as a reviewable commit and a deploy – with history, review and rollback. It suits a large enterprise with an editorial team just as well as the sole trader or SME who will never open a CMS: if you can send a voice message, you can maintain your website. Our own WhatsApp AI agent is the honest proof that chat agents are day-to-day work here rather than slideware.

The limits belong in the same paragraph. The chat route does not replace an editorial workflow with approval stages for a large team – it complements one. Editorial responsibility stays with you; an agent drafts and writes, it does not decide. Structural changes – new page types, layout, navigation – remain development work. And the scope is defined per project: which collections, which fields, which approval stage. Described in full under editing your website by chat.

The test in one line

Mark every surface that fails without browser JavaScript. Few surfaces: Astro. Nearly everywhere: Next.js.

No skills wasted

React components keep running in Astro as islands, through an official integration. Your team does not need to relearn anything to start.

Both is allowed

Website on Astro, application on Next.js, separated by subdomain. Two teams, two deploy rhythms, no mutual blocking.

If it really is an app

Where the logic is genuinely application logic, we would rather build you a custom web application – and say so upfront.

04 — Switching

If you move from Next.js to Astro: what it actually involves.

A framework change is a rebuild, not a button. Here is what to expect when an existing Next.js site moves to Astro – including the parts that are usually underestimated:

There is an official migration path – The Astro documentation lists Next.js among its migration guides, so you are not inventing the approach from scratch. It does not replace project planning, though – the docs themselves note that a number of those migration pages are kept short.
Routes and layouts get translated, not copied – Both frameworks use file-based routing, but the conventions differ. Every route needs a decision: prerendered or on demand. That decision is the actual substance of the rebuild.
React components stay – the question is which ones – Interactive components move over as islands. Anything that only produces markup is better rewritten as an .astro component: that is precisely where the reduction in delivered JavaScript comes from. Sorting the two apart is the real manual work.
Data access gets rewired – Server-side data access, environment variables, API routes and the image pipeline all move to Astro equivalents. For images, Astro ships its own components, which set alt, loading and decoding and infer dimensions so no layout shift occurs.
SEO is the critical path, not the design – URLs, redirects, canonicals, hreflang, structured data and the sitemap need checking before go-live. A framework change should not change your addresses – and where it must, it happens deliberately and with a complete redirect map.
Cost scales with page types, not page count – Twenty blog posts sharing one template are one page type; twenty individually built landing pages are twenty. In the first call we count page types and interactive surfaces – that is where the range comes from, not from a flat rate.
When you should simply stay – If your Next.js site is technically healthy, your team is productive in it and load time meets your targets, there is no reason to move. A rebuild without a trigger is burnt budget. We will tell you that in the first call, before you ever see a quote.

The detail page

Process, timeline and checks in full: migrating Next.js to Astro.

Measure first

We record your Core Web Vitals and your rankings before the rebuild – otherwise nobody can prove afterwards that anything improved.

Guidance instead of handover

For larger rebuilds we can act as IT project management while your in-house team delivers part of the work.

Different starting point?

We wrote up Astro vs Webflow and Astro vs WordPress to the same pattern. Everything else in one place: Astro agency.

05 — Timelines

How long a switch realistically takes.

Prices are not on this page – those arrive as a transparent estimate after the first call. Time, on the other hand, can be discussed upfront. The ranges below are our own estimate for the way we work, counted from the inventory to go-live – not an industry figure and not a guarantee:

The decision alone: a few days to a week – If you first want to know which framework fits, we need your page list, a look at the existing site and one conversation. The written assessment usually lands within a week – with the reasoning, and explicitly including the option "stay where you are".
Lifting a contained marketing site out of a Next.js project: 4 to 7 weeks – Up to roughly six distinct page types, content carried over rather than rewritten, no CMS, one language, ordinary integrations such as analytics, consent and a form. That covers the page-type inventory, the rebuild, the URL and redirect map, sign-off on staging and the go-live itself.
A grown site with an archive, a CMS or several languages: 8 to 14 weeks – Eight to fifteen page types, a connected headless CMS, two language versions with their hreflang logic, several routes rendered on demand. A blog archive with thousands of posts belongs here, and so does a shop, booking or search system with its own runtime. Anything beyond that we cut into phases rather than claim a date.
What moves the range – and what does not – Not the number of pages. It is: the number of distinct page types; whether content is migrated or rewritten editorially; whether a CMS joins and who fills it; the number of languages; every integration with its own runtime; and the approval cycles on your side. Two review rounds per template are weeks, not days – the single most underestimated line item.
The cut-over itself is short – We build in parallel: your existing Next.js site stays online until the new one is signed off on staging. The switch happens through DNS or hosting configuration, with the redirect map going live at the same moment. We put that window outside your peak hours and plan for normal DNS propagation – not for zero minutes.
After go-live: 8 to 12 weeks of watching – Search engines need time to fully re-process a moved site. So we keep checking indexing, redirects, structured data and positions across that window and correct whatever shows up. That is a commitment about our attention in those weeks, not about your rankings. We do not promise that not a single position will move – some movement is normal in every migration.

The process in detail

Steps, checkpoints and handover are written up on the migration page: migrating Next.js to Astro.

What drives the price

The same variables that move the timeline move the budget. How we calculate it: Astro development cost.

And afterwards?

Who handles updates, monitoring and small changes is agreed before go-live – see Astro support and maintenance.

06 — At a glance

Astro vs Next.js at a glance.

This page condensed into one table – descriptive, not scored. The final row is our opinion, clearly labelled as one.

Aspect	In one line
What it comes down to	Astro is a framework for content-driven websites; Next.js is a React framework for applications. The question is not which one is better, but which kind of site you are building.
Default output	Astro: static HTML, with client-side JavaScript only where a component asks for it through a `client:*` directive. Next.js: React as the foundation of the page; Server Components move a lot to the server, but a client share is part of the model.
UI library	Astro is framework-agnostic – official integrations for React, Preact, Svelte, Vue, SolidJS and Alpine.js. Next.js is fixed on React, which is also its strength: one model, one ecosystem, one onboarding path.
Content	Astro ships Content Collections with Zod schemas, generated TypeScript types and built-in caching. Next.js ships no content model – you pick the library, CMS or database yourself and build the wiring.
Hosting and operations	A static Astro build sits on any web server or CDN; on-demand rendering needs an adapter (Node, Vercel, Cloudflare). Next.js runs as a Node server or serverless; it is developed by the hosting company Vercel, and self-hosting is explicitly supported.
Licence	Both are MIT-licensed open source. Neither framework charges licence fees – cost comes from development, hosting and operations.
Hiring pool	React developers are far more numerous on the market than Astro specialists. Anyone who knows React picks Astro up quickly – but the larger market remains a genuine argument for Next.js.
Effort to switch	A contained marketing site: 4 to 7 weeks. A grown site with an archive, a CMS or several languages: 8 to 14 weeks. Process, checks and cost logic are on migrating Next.js to Astro.
Our take	For anything that is primarily read, we would choose Astro today – because of the default, not because of anyone else's benchmark: what is never shipped never has to run. For anything behind a login we would choose Next.js and not spend long debating it. And in the most common case – a website plus a product – we would use both and separate them cleanly. Anyone who names a winner without having seen your page list is selling you their standard process.

07 — FAQ

Astro vs Next.js: common questions.

Is Astro faster than Next.js?

For a content-driven site, usually yes – not because one framework is better engineered, but because of a default. Astro removes all client-side JavaScript from components by default, while Next.js ships React as the foundation of the page. Less JavaScript to execute tends to mean better numbers. For an interactive application that advantage disappears, because the interactivity is needed anyway. Only a measurement on your site is conclusive.

Can we reuse our React components in Astro?

Yes. Astro is UI-framework-agnostic and has an official React integration; existing components keep running as islands and receive their JavaScript through a directive. Inside a single .astro file, components from several frameworks may even sit side by side. Even so, it is worth converting purely presentational components into .astro components – that is where the reduction in delivered JavaScript actually comes from.

Can Astro do server rendering and dynamic routes, or only static pages?

Both. Prerendered is the default: by default the entire site is prerendered and static HTML is sent to the browser. Individual routes render on demand via export const prerender = false; with output: server the default flips and individual pages opt back in with prerender = true. On-demand rendering requires an adapter for the target runtime – first-party adapters exist for Node, Vercel and Cloudflare.

Astro or Next.js for SEO – is there a difference?

For indexability, barely any: both deliver server-rendered HTML, so crawlers see finished content either way. The difference shows up in Core Web Vitals, because the amount of JavaScript delivered feeds directly into interactivity and loading metrics. In practice, though, information architecture, internal linking and the content itself outweigh the framework difference almost every time. A framework change is not a substitute for SEO work.

Is it worth migrating from Next.js to Astro?

Only with a trigger. Good triggers: the marketing site lives in the product repository and every copy change needs a product deploy; the site is almost entirely content yet ships the full application runtime; hosting costs for server rendering are out of proportion to the content. A bad trigger: a framework is currently fashionable. If your site performs, stay. Details on the migration page.

Will we still find developers and maintenance for Astro in a few years?

The React job market is considerably larger – that is a genuine advantage for Next.js and belongs in the decision. On the other side: Astro is MIT-licensed, follows semantic versioning, and maintains exactly one previous major version with security fixes; the current line is Astro 7. And anyone who knows React gets productive in Astro quickly, because the React components stay the same.

Can we really maintain the site by chat afterwards?

Yes, within a defined scope. Because Astro content lives in a typed, Zod-validated content model or in a headless CMS with an API, an agent can write to it in a structured way: change a paragraph, publish a post, swap an image, correct a price – as a message, for example through a Telegram bot. Every change becomes a reviewable commit and a deploy. Structural changes remain development work, and which fields are opened up is agreed per project.

"Our product team has worked in React for years. Do we give that up if the website runs on Astro?"

No. Astro is UI-framework-agnostic and has an official React integration – your components keep running there as islands, and the application behind the login stays where it is anyway. What changes is the default: not everything is React any more, only the parts that need interactivity. For a React team that is a few days of adjustment, not relearning. The real work is sorting out which component stays an island and which becomes an .astro component.

"We have 4,000 blog posts. How long does a switch take, and is there downtime?"

The number of posts is rarely the problem: four templates for 4,000 posts are four page types, and Content Collections are explicitly documented with built-in caching for thousands of entries. The effort sits in the state of the content – inconsistent markup, embedded components, stale image paths. For a site that size we plan 8 to 14 weeks. We build in parallel, the old site stays online until sign-off, and the cut-over happens in a scheduled window with the redirect map ready.

"We are happy with our hosting. Does Astro force us to move?"

No. A static Astro build is plain HTML and sits on any web server or CDN – including the one you use today. Only on-demand rendering needs an adapter for the target runtime; first-party adapters exist for Node, Vercel and Cloudflare. If your Next.js application runs on Vercel today and that works well, the Astro site can stay there too. This is an operations decision, not a framework decision.

"Marketing wants to publish without waiting for developers. Is Astro enough for that?"

Only with something on top. Astro itself ships no editing front end; content lives in Content Collections or in a connected headless CMS. Three routes are workable: a headless CMS with an editorial interface, a Git-based CMS, or our chat route through a Telegram bot. If editorial autonomy is your most important criterion and nobody in-house wants anything to do with deployments, Webflow is often the more honest answer – we build that as well.

"We need personalised content for signed-in users. Does that rule Astro out?"

Not automatically. Astro has Server Islands: dynamic components rendered independently on the server via server:defer. The page shell and the main content can therefore be cached aggressively while the personalised element loads afterwards, without blocking the initial render. For a greeting name, a cart counter or a recommendation block that works well. If nearly every route is personalised and everything hangs off a session, Next.js is the leaner route.

"Can we switch gradually instead of all at once?"

Yes, and for larger sites that is often the calmer path. The usual approach is a split by path or subdomain: the blog or the landing pages move to Astro first, the rest stays in Next.js for now, and a reverse proxy or the hosting configuration routes the requests. It costs some operational complexity during the transition and demands careful redirect planning – but it lowers the risk considerably compared with a single-night switch.

"What happens if you disappear, or we part ways? Can we carry on in-house?"

Yes. The repository, hosting accounts and domains are in your name from day one – we work in them, we do not own them. What you get is a standard, MIT-licensed Astro project with no proprietary layer in between: ordinary conventions, documented structure, no black box. Anyone who knows React can read into it in a day. Handover includes a setup document and, if you want, a joint session with your team.

"Who is liable if something breaks after launch?"

We stand behind what we ship. Before go-live we put in writing what counts as a defect and how quickly we respond; the contractual side of that belongs in the proposal, not in an FAQ. Technically we work so that defects surface early: sign-off on staging, a checklist for URLs, redirects, meta data and structured data – and every change as its own commit with deploy history, so a rollback takes minutes.

"What does the decision cost, and what does the switch cost?"

We do not charge for the initial assessment. For the rebuild we deliberately publish no flat rate, because without your page list it would be a guess. The cost drivers are the same as the time drivers: number of distinct page types, number of interactive surfaces, whether content is migrated or rewritten, CMS or no CMS, languages and integrations. After the first call you get an estimate with every line item named.

Is Astro free?

Yes. Astro is free open-source software under the MIT licence. There are no licence fees – nor for Next.js, which is MIT-licensed as well. Cost comes from development, hosting and operations, not from the framework itself.

Does Astro need a server?

Not for a prerendered site: by default the entire site is prerendered and delivered as static HTML, which can sit on any web server or CDN. Only on-demand rendering needs a runtime and a matching adapter – first-party ones exist for Node, Vercel and Cloudflare.

What is the Islands Architecture?

Astro coined the term: a component-based web architecture optimised for content-driven websites. The documentation defines an island as "an enhanced UI component on an otherwise static page of HTML" – most of the page stays static HTML, and interactive components are added only where they are needed.

Which Astro version is current?

The current major line is Astro 7. Astro follows semantic versioning, and extended maintenance with security fixes covers exactly one previous major version. For you that means upgrades are predictable but need planning – Astro ships major versions at a brisk pace.

Who builds Next.js?

Next.js is developed by the hosting company Vercel and is MIT-licensed. Its own platform accordingly offers the tightest integration, while self-hosting as a Node server is explicitly supported. Astro is likewise MIT-licensed open source and is developed in the open, in the withastro repository on GitHub.

Can Astro and Next.js run side by side?

Yes, and it is more common than people assume: website on Astro, application on Next.js, separated by subdomain or path. Two repositories, two deploy rhythms, no mutual blocking. What it does require is one consistent navigation, a shared design system and clean canonical tags.

Not sure which kind of site you actually have?

Send us your page list or the URL of your current site. You get a reasoned read on whether Astro, Next.js or a split fits – and the reasoning behind it. Including when the answer is "stay where you are".

Request an assessment

A framework decision with nothing to sell.

Describe your project in three sentences – you get a reasoned recommendation for Astro, Next.js or a clean split between them. Usually within 24 hours.

Get a framework read

08 — Go deeper