Astro vs Next.js — the honest version of the choice from someone who ships both
Most Astro vs Next.js comparisons are written by people who have only used one. This is the read from an agency that ships marketing sites on Astro and SaaS apps on Next.js — with the specific decision tree, the Core Web Vitals numbers, and the cases where each is genuinely the right answer.
This site is Astro HostList.io is Next.js Headless WordPress builds on both Updated 2026-05-13
The short answer
Astro for content-led sites — marketing, blogs, documentation, small-catalogue ecommerce, anything where most pages are read-only by anonymous visitors. Next.js for app-led sites — SaaS dashboards, authenticated experiences, large-catalogue ecommerce, anything where Server Components, server actions, and route interceptors earn their keep. The frameworks overlap in the middle; they are not equivalent.
Decision tree
Three questions in order. Answer them honestly and the right framework falls out.
1. Do most of your visitors log in?
If yes — Next.js. The authentication, session management, route protection, and server-action patterns that Next.js has spent five years building are not duplicable on Astro without fighting the framework. Astro can do auth; it does not do app shells.
If no — continue to question 2.
2. Do most pages need server-rendered dynamic content per request?
If yes — Next.js. Personalisation, A/B testing at the page level, server-side data fetched per visitor — Next.js does this cleanly. Astro can do server rendering but its sweet spot is static or ISR-style rendering with light per-request work.
If no — continue to question 3.
3. Is your team already React-aligned for other reasons?
If yes — Next.js is the lower-friction choice even if Astro would technically fit the shape. Switching frameworks costs more than the marginal Core Web Vitals improvement Astro would deliver.
If no — Astro. Lighter front-ends, simpler component model, better defaults for the content-led shape, no React tax on every page load.
The performance numbers, honestly
Representative 30-page marketing site, identical content and design, built on each framework and deployed to Vercel:
Astro
JavaScript shipped: 50-90KB (excluding fonts and images). LCP on a decent 4G connection: under 1.2 seconds. INP: typically under 100ms. Lighthouse mobile: 95-100. The framework ships almost no JS by default; only the components you explicitly mark as client-side hydrate.
Next.js (App Router, Server Components)
JavaScript shipped: 180-300KB. LCP on the same connection: 1.6-2.4 seconds. INP: 100-200ms. Lighthouse mobile: 80-92. The framework itself plus React account for 80-120KB before your own code; Server Components reduce the gap vs older Next.js versions but do not close it for pure content shapes.
The performance gap narrows the moment you add interactivity. A site with significant client-side state, animations, or framework-dependent libraries will not see the full Astro advantage — at which point you are usually past the threshold where Next.js was the better choice anyway.
Headless WordPress on each
Both frameworks pair cleanly with WordPress as a headless CMS. The trade-offs are framework-shaped, not WordPress-shaped.
Astro + WordPress + WPGraphQL
The lightest version of headless WordPress. Fast Core Web Vitals, simple build pipeline, clean ISR-style on-demand rendering when content changes. Best when the marketing site is the main product and visitors do not need authenticated features.
Next.js + WordPress + WPGraphQL
The version most agencies default to — partly for technical reasons, mostly because the React + Next.js talent bench is deeper. The right choice when the front-end will eventually need authentication, member areas, or app-shell behaviour beyond the marketing site.
See headless WordPress development for the broader pattern across Next.js, Astro, and Nuxt.
Where each framework breaks down
Where Astro breaks down
- Authentication and session-heavy patterns. You can do it; you will be fighting the framework.
- Heavy interactivity on every page. The framework is designed to ship minimal JS, and forcing it to behave like a SPA defeats the design choice.
- Real-time features (websockets, streaming UI, server-sent events). Possible; not the framework's sweet spot.
- Component libraries that assume React-everywhere. Astro supports React islands, but a third-party UI library written for App Router will not work without adaptation.
Where Next.js breaks down
- Pure content sites where every additional KB of JS is unnecessary overhead. The framework ships more than the content shape needs.
- Documentation and blog sites. Astro renders them with a fraction of the framework weight.
- Marketing sites where the team is not committed to React. Onboarding non-React developers onto Next.js patterns (Server Components, server actions, route handlers) is steeper than onboarding them onto Astro.
- Static-first ecommerce with small catalogues. Astro plus on-demand rendering covers the same ground with less weight.
Frequently asked questions
Astro vs Next.js — which one should I use in 2026?
Astro for content-led sites (marketing, blogs, documentation, ecommerce storefronts where the catalogue is small enough to pre-render). Next.js for app-led sites (SaaS dashboards, authenticated experiences, ecommerce with thousands of dynamic SKUs, anything where Server Components and server actions earn their keep). The rule of thumb: if your site is mostly read-only content for visitors who do not log in, Astro is the more honest choice. If your site is software that users sign into and interact with, Next.js is the right answer.
Is Astro faster than Next.js?
For content-led sites, yes — typically by a meaningful margin on Core Web Vitals (LCP, INP). Astro ships zero JavaScript to the browser by default and hydrates only the components you mark as interactive. Next.js ships React to the browser even for pages that do not need it, and the framework overhead alone is 80-120KB gzipped before your own code. For app-led sites where you genuinely need interactivity everywhere, the speed difference flips — Next.js has been engineered for that case and Astro is fighting the framework if you push it that direction.
Can Astro do everything Next.js can?
No, and trying to make it would be the wrong fight. Astro is missing — by design — Server Components in the React 19 sense, server actions, parallel routes, route interceptors, and the deep authentication and session patterns that Next.js has spent five years building. You can do auth in Astro, you can do dynamic routes, you can do server rendering, but the moment your site shape looks more like an app and less like a content site, you are pushing Astro past where it was designed to go. At that point, switch.
Can Next.js do everything Astro can?
Yes, but with more JavaScript shipped to the browser and more framework overhead than the content shape needs. A Next.js marketing site will work and will be maintainable, but it will weigh 200-400KB more than the same site in Astro and the Core Web Vitals will reflect that. For pure content sites where the team is not committed to React for other reasons, you are paying a performance premium for no gain.
Which framework is better for headless WordPress?
Both work well. Astro plus WPGraphQL plus WordPress is the lightest-weight version of headless WP — fast, simple, and a clear pattern for editorial-led content sites. Next.js plus WPGraphQL plus WordPress is the right answer when the front-end will eventually need authentication, dashboards, or app-shell behaviour beyond the marketing site. Most agencies default to Next.js for headless WordPress because the React talent bench is deeper; the technical merit is closer to a wash than the default would suggest.
What is the performance difference in real numbers?
A representative 30-page marketing site on Astro ships 50-90KB of JS for the whole site (excluding fonts and images), reaches LCP under 1.2 seconds on a decent 4G connection, and scores 95-100 on Lighthouse mobile. The same site on Next.js with the App Router and Server Components ships 180-300KB of JS, LCP runs 1.6-2.4 seconds on the same connection, and Lighthouse mobile sits 80-92. The numbers narrow once you start adding interactivity on the Next.js side; the gap is most extreme on pure content shapes.
Which framework has the better developer experience?
Astro for content-led work — file-based routing is straightforward, the component model is simpler, the framework gets out of the way. Next.js for app-led work — Server Components and server actions feel like the right primitives once you have used them, and the React ecosystem around state management, forms, auth, and data fetching is materially more mature. The mistake is picking based on which DX is currently trendy rather than which fits the actual project shape.
Is Astro a fad? Will it still be around in 5 years?
Astro is well-funded (Series B closed 2024), has shipping enterprise users at scale (Microsoft Learn, Netlify own docs, several Fortune 500 marketing sites), and is on a release cadence that suggests serious engineering investment rather than hype-cycle exhaustion. Will it be the dominant framework in 5 years? Unknowable. Will the code you ship today still build in 5 years if you stay on it? Yes — Astro is small enough and its surface area is constrained enough that maintenance burden is genuinely low.
Which framework should I use for ecommerce?
Depends on catalogue size and dynamic shape. Small catalogue (under 500 SKUs), static-friendly product data, marketing-led brand: Astro is genuinely a better choice. Large catalogue (thousands of SKUs), heavy filtering, authenticated accounts, complex checkout flows: Next.js. The middle case (500-5000 SKUs) goes either way — Astro plus ISR-style on-demand rendering covers it; Next.js plus server actions for the cart covers it; whichever your team is better at is probably the right answer.
Can I mix Astro and Next.js in the same project?
You can run them as separate sub-applications on different routes (marketing on Astro at the root, app on Next.js at /app/) but you cannot blend them in a single codebase. In practice this is a useful pattern — Astro for the marketing site, Next.js for the product. Both deploy to Vercel cleanly, both can share a design system via a separate component library, and the editorial team only touches the Astro side. Some of my most successful builds use this exact split.
If you are still deciding
Bring three things to the 30-minute call. The product or site you are building. Whether your team is currently React-aligned, Vue-aligned, or framework-neutral. The Core Web Vitals or performance target the project needs to hit. By the end of the call you will have a written framework recommendation for your specific case — Astro, Next.js, or Nuxt — with reasoning you can defend in a stakeholder review.