· nextjs / astro / comparison
Next.js vs Astro 2026 — when to choose static sites
Pick Astro for content-heavy sites that need minimal JavaScript and real Core Web Vitals. Pick Next.js when you are building an app, not a site.
By Ethan
2,068 words · 11 min read
Use Astro for content-heavy sites: blogs, documentation, marketing pages, portfolios. Use Next.js when you’re building an app — auth, user sessions, database mutations, complex navigation. The frameworks solve different problems. Reaching for Next.js on a Markdown blog because it’s the popular choice is the most reliable way to ship 40–50 KB of unnecessary JavaScript on every page load.
Who this is for
Frontend developers choosing a framework for a new project in 2026. Especially if you’re building something content-first and wondering whether the default Next.js pick is actually warranted. If you’re migrating an existing codebase, the technical tradeoffs below still apply — but migration cost is a separate calculation.
Versions in scope
- Astro 6.3.1 — current stable as of May 2026, initial release March 10, 2026
- Next.js 16.2.6 — current stable as of May 2026, initial release October 21, 2025
Both frameworks released major new versions since most “Next.js vs Astro” comparisons were written. The posts comparing Astro 4 to Next.js 14 are measuring different software.
The structural difference
This is the core of the comparison. Everything else follows from it.
Astro ships zero JavaScript by default for content pages. Next.js always ships the React runtime (~85 KB) even for static pages. The reconciler has to reach the browser for hydration boundary management — that’s not an optimization issue, it’s how React works.
For a pure Markdown blog with no client-side interactivity:
| Scenario | Astro | Next.js |
|---|---|---|
| Homepage JS bundle | ~8 KB | ~85 KB |
| Pure Markdown blog | 0 KB | 40–50 KB minimum |
| Docs site first load (measured) | ~9.3 KB | ~463 KB |
| Lighthouse score (Slow 4G) | >95 | ~75 |
| First content render (Slow 4G) | ~0.5s | 1–1.5s |
These numbers come from multiple independent benchmarks (BetterLink, Senorit, and others, 2025). They’re directional, not a single reproducible lab test — but the direction is consistent and the architecture explains why.
Astro’s islands model is what makes this possible. You only hydrate the components that need it. Add a React search widget to an otherwise static article page: that island gets React, the rest stays HTML. Data fetching runs at build time (or request time in SSR mode) without any client-side code:
---
// Runs at build time — no client JS for this component
const posts = await fetch('https://cms.example.com/posts').then(r => r.json());
---
<ul>
{posts.map(p => <li>{p.title}</li>)}
</ul>
The Next.js App Router equivalent with React Server Components looks similar in how the code runs, but React still ships to the client for hydration management of any client components on the page:
// Server Component — no JS for this component specifically
// But React runtime (~85 KB) still ships to client for the page
async function Posts() {
const posts = await fetch('https://cms.example.com/posts').then(r => r.json());
return <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>;
}
If your page has no interactive components at all, Next.js still ships ~85 KB. Astro ships nothing.
Performance: Core Web Vitals
The 2023 HTTP Archive CrUX dataset — the most recent publicly available framework-level comparison — shows the real-world gap:
| Metric | Astro | Next.js | Industry avg |
|---|---|---|---|
| Overall CWV pass rate | >50% | ~25% | 40.5% |
| INP pass rate | 68.8% | <60.9% avg | 60.9% |
| LCP pass rate | Above 52% avg | Below 52% avg | 52% |
Source: Astro 2023 Web Framework Performance Report, HTTP Archive CrUX data.
Next.js at ~25% is well below the 40.5% industry average. That’s the aggregate of all Next.js sites — many ship excess client JS because the developer didn’t think to optimize. A well-tuned Next.js site can score much higher. The point is that Astro’s architecture makes the bad path harder to take by accident.
No comparable 2025/2026 update to this dataset was available at publication. See caveats.
Build speed
A 1,000-page docs site builds roughly 3× faster on Astro than on Next.js based on independent testing (2025). Astro’s own Content Layer benchmarks report 5× faster Markdown builds and 2× faster MDX builds compared to the previous content collections API.
Next.js 16 significantly closed the dev build gap with Turbopack as the new default — 5–10× faster Fast Refresh, 2–5× faster production builds. Cold CI builds with a large Next.js app are meaningfully faster in 16 than in 15.
2026 state: Astro 6
Astro 5 (December 2024) introduced two features that covered the most common reasons teams reached for Next.js instead:
Content Layer (Astro’s name for its unified content API): Loads content from disk, APIs, and CMSs into a type-safe single data store. Up to 5× faster Markdown builds and 25–50% memory reduction compared to the previous content collections system.
Server Islands (stable in Astro 5): Combine cached static HTML with dynamic, server-rendered components on the same page. A personalization component loads independently without blocking the static article around it. Custom cache headers per island. This covers most of the “dynamic” use cases that previously required full SSR — and it does it without shipping React to every visitor.
Astro 6 (March 10, 2026) added:
Redesigned dev server: Uses Vite’s Environment API to run the exact production runtime during development. When you deploy to Cloudflare Workers, local dev runs workerd — Cloudflare’s Workers runtime — with access to Durable Objects, D1, KV, and Workers AI. The “works in dev, breaks on prod” class of bug disappears.
Live Content Collections: Request-time content fetching integrated with the Content Layer. CMS content updates the moment it’s published, without touching the build pipeline, and without the overhead of a full SSR deployment.
Built-in Content Security Policy: First-class CSP API for both static and dynamic pages. Automatically hashes scripts and styles, generates appropriate headers. Next.js has no built-in equivalent.
Experimental: Rust compiler (successor to Go-based), queued rendering (2× faster rendering in internal testing), platform-agnostic route caching API.
Breaking changes in Astro 6: Node 22 minimum (18 and 20 dropped).
2026 state: Next.js 16
Next.js 15 (October 2024) reset the caching model — fetch requests and GET route handlers are no longer cached by default, reversing the surprise behavior that burned developers in v14.
Next.js 16 (October 2025) delivered:
Turbopack is now the default for both next dev and next build. No flag required. 5–10× faster Fast Refresh, 2–5× faster builds. Turbopack filesystem caching (development only, enabled via turbopackFileSystemCacheForDev: true) persists compiler artifacts across dev server restarts — large projects see significantly faster cold dev startups after the initial build.
Cache Components (stable): The headline Next.js 16 feature. Replaces the old experimental.ppr flag. Enable via cacheComponents: true. The use cache directive can cache pages, components, and functions. Completes the PPR story — static shell plus dynamic holes — within the React/RSC paradigm. If you’re committed to React and need static-first delivery, this makes it possible without switching frameworks.
Proxy replaces Middleware: Cleaner network boundary semantics for request interception (Node.js runtime).
For Next.js deep-dives, see our Next.js 16 vs React Router v7 comparison — it covers data loading, routing complexity, and platform tradeoffs for full-stack React apps.
Hosting and the Cloudflare acquisition
On January 16, 2026, Cloudflare acquired The Astro Technology Company. The entire team joined Cloudflare. Financial terms were not disclosed.
The key details for developers:
- MIT license preserved. Public roadmap, open governance, unchanged.
- Portability confirmed. “You can deploy Astro to any platform or cloud” was explicitly reaffirmed.
- Cloudflare Pages is now Astro’s native home. Official
@astrojs/cloudflareadapter maintained by the combined team. Server Islands, Astro Actions, and session storage via Workers KV all work natively. Generous free tier for static sites. - The competitive framing is now explicit: Vercel backs Next.js; Cloudflare backs Astro. Platform competition overlapping with framework competition.
Netlify is the neutral ground. Netlify is an Astro Ecosystem Fund partner (they co-invested in Astro’s open-source future alongside Cloudflare, Webflow, Wix, and Sentry). The official @astrojs/netlify adapter supports both static and SSR modes. Netlify also supports Next.js. If you want to stay platform-independent, Netlify covers either framework without political baggage.
Vercel is Next.js’s native home. Zero-config deploys, Edge Functions, ISR, PPR all native. Image optimization, analytics, speed insights built in. Self-hosting improved in 15/16 — the manual sharp install requirement is gone. If you’re building Next.js and deploying to Vercel, you’re in the first-party lane.
Ecosystem size
Next.js: ~15 million weekly npm downloads, 139K GitHub stars. Astro: ~1.9 million weekly downloads, 59K stars. Next.js leads by roughly 8×.
More downloads means more tutorials, more third-party integrations, more Stack Overflow coverage, more production war stories. If your team is React-only and the Astro islands model is unfamiliar, the learning curve is real. A week of productivity loss onboarding a team to Astro matters when you’re shipping.
Astro grew from ~813K/week in 2024 to ~1.9M/week in May 2026 — 2.3× growth in roughly 18 months. The gap is real and closing, but the gap is real.
If you’re still weighing React vs Vue before committing to a meta-framework, see our React vs Vue 2026 comparison.
Choose Astro if…
- You’re building a content-heavy site: blog, docs, marketing site, portfolio, news
- Performance is non-negotiable: you need maximum Lighthouse scores and minimal JavaScript payload
- The site has little or no client-side state — logged-in user dashboards, shopping carts, or real-time features are not the main product
- You want to mix UI frameworks — React components alongside Svelte or Vue in the same project
- Deploying to Cloudflare Pages or Netlify, especially post-acquisition for Cloudflare
- You need Content Security Policy without wrestling with middleware configuration
- Build time matters: large content sites build ~3× faster
Choose Next.js if…
- You’re building a full-stack app: user auth, sessions, database mutations, admin dashboards
- You need complex dynamic routing: multi-level nested layouts, parallel routes, intercepting routes
- The team is React-only and wants the full React ecosystem (hooks, Auth.js, Clerk, RSC patterns)
- You’re deploying on Vercel and want maximum platform integration
- You need ISR with granular tag-based revalidation (
revalidateTag/revalidatePath) for a high-traffic content + app hybrid - The product will evolve from content site to app — starting with Next.js avoids the rewrite when that transition happens
Verdict
Astro wins on content-site metrics: bundle size, Core Web Vitals pass rates, build speed, and built-in CSP. Next.js wins on app-framework completeness: auth ecosystem maturity, routing depth, React ecosystem coverage.
The Cloudflare acquisition makes Astro’s Cloudflare platform integration story the best in the market, but doesn’t close the gap on the app layer. Astro still has no first-class auth story. Complex server state still tilts toward Next.js.
The deciding question is whether you’re building a site or an app. Content as the main product: Astro. User accounts, mutations, and complex navigation as the main product: Next.js. Hybrid? Next.js with PPR gets you the static delivery story without the framework switch — though you’ll pay for it in bundle size.
Caveats
Performance data dates: The Core Web Vitals comparison uses the 2023 HTTP Archive CrUX dataset. This is the most recent framework-level comparison using that methodology available at publication. The relative direction is consistent with the architectural explanation (zero-JS default vs React runtime floor), but exact numbers may shift as deployment patterns evolve.
Bundle size numbers: From multiple independent benchmarks (2025 sources), not a single reproducible lab test. The numbers are directional evidence, not manufacturer-certified specs. The architectural explanation is more reliable than the specific KB figures.
Affiliate links: Vercel and Netlify links in this article are affiliate links — see the disclosure above the article. Cloudflare has no affiliate program; that link is uncompensated. Neither affiliate relationship changed the recommendations.
References
- Astro 5.0 release post — Content Layer, Server Islands, simplified prerendering
- Astro 6.0 release post — redesigned dev server, Live Content Collections, built-in CSP
- Next.js 15 release post — Turbopack stable for dev, caching overhaul, async request APIs
- Next.js 16 release post — Turbopack default for build, Cache Components (
use cache), Proxy - Astro 2023 Web Framework Performance Report — CWV data, HTTP Archive CrUX dataset
- Cloudflare blog: Astro joins Cloudflare — acquisition announcement
- Cloudflare press release — acquisition details, MIT license and portability commitments
- npmtrends: astro vs next — download data (May 2026)
- Astro Cloudflare adapter docs — Server Islands, Astro Actions, KV session storage