Astro vs Next.js: When to Use Which

Astro ships zero JavaScript to the browser by default. Every page is static HTML unless you explicitly opt in to client-side interactivity. Next.js ships a JavaScript runtime on every page — even static ones — because it assumes your app needs hydration, routing, and React on the client.

That single architectural decision drives every trade-off between these two frameworks: build speed, page load performance, Core Web Vitals, framework flexibility, and full-stack capability. We compared them using real data from PkgPulse. Here's what the numbers say — and when each choice is the right one.

At a Glance

Metric	Astro	Next.js
Default JS Shipped	0 KB	80-120 KB+ (React runtime)
Page Load (static content)	~40% faster than Next.js	Baseline
JS Payload (comparable pages)	~90% less than Next.js	Baseline
Build Time (1,000-page docs site)	~18 seconds	~52 seconds
Core Web Vitals	Near-perfect consistently	80-85 Lighthouse (static export)
Framework Support	React, Vue, Svelte, Solid, Preact	React only
Full-Stack Capabilities	Limited (endpoints, middleware)	Complete (API routes, SSR, ISR, middleware, Server Actions)
Rendering Modes	Static (SSG), on-demand SSR	SSG, SSR, ISR, PPR, Streaming
Hydration Model	Islands (selective, opt-in)	Full-page (automatic)
Primary Use Case	Content-driven sites	Web applications

See the full live comparison — download trends and health scores — at pkgpulse.com/compare/astro-vs-next

The headline: Astro pages load roughly 40% faster and ship roughly 90% less JavaScript than comparable Next.js pages. But Next.js offers a full-stack application framework that Astro doesn't try to compete with. These tools aren't rivals — they're built for different problems.

The Architecture Divide

This is the comparison that matters most. Everything else — performance, DX, ecosystem — flows from how each framework thinks about JavaScript in the browser.

Astro: Islands Architecture

Astro treats JavaScript as an explicit, per-component decision. The page renders entirely to static HTML at build time. Interactive components — a search bar, a carousel, a dynamic chart — are "islands" of JavaScript in a sea of static HTML. Each island hydrates independently, and only when you tell it to.

---
// This page ships ZERO JavaScript by default
import Header from '../components/Header.astro';
import BlogPost from '../components/BlogPost.astro';

// Only this component gets JavaScript — and only when visible
import SearchBar from '../components/SearchBar.jsx';
---

<Header />
<BlogPost />
<SearchBar client:visible />

The client:visible directive tells Astro to load the React component's JavaScript only when the user scrolls it into view. Other directives include client:load (immediate), client:idle (when the browser is idle), and client:media (at a specific breakpoint). Every byte of JavaScript is an intentional choice.

The result: a documentation site, marketing page, or blog built with Astro will ship near-zero JavaScript. The browser receives HTML and CSS. It renders instantly. No hydration delay, no JavaScript parsing, no Time to Interactive gap.

Next.js: App Router and React Server Components

Next.js takes the opposite approach. It's a React application framework, and React is always present on the client. Even with React Server Components (RSCs) in the App Router — where components render on the server and never re-render on the client — Next.js still ships the React runtime, the router, and the framework's client-side infrastructure.

// app/blog/[slug]/page.tsx — a Next.js Server Component
// This component runs ONLY on the server... but the page
// still ships ~80-120KB of React runtime to the browser

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

React Server Components reduced client-side JavaScript significantly compared to the Pages Router era. But the fundamental reality remains: Next.js pages include a baseline JavaScript payload that Astro pages don't.

That baseline pays for powerful capabilities — client-side navigation, streaming, suspense boundaries, server actions, and the full React ecosystem. For an application that needs those features, it's a worthwhile investment. For a content site that doesn't, it's dead weight.

Performance: The Numbers

We benchmarked both frameworks across build times, page load metrics, and JavaScript payload sizes. The differences are significant.

Build Times

Scenario	Astro	Next.js
1,000-page docs site	~18 seconds	~52 seconds
Speed difference	~3x faster	Baseline

Astro's build pipeline is simpler by design. It compiles pages to static HTML without the overhead of React's server-side rendering, code splitting, and bundle optimization that Next.js performs. For content-heavy sites — documentation, blogs, marketing pages — that 3x build speed difference compounds into meaningful CI/CD time savings.

Page Load Performance

Metric	Astro	Next.js (Static Export)
JavaScript shipped	0 KB (default)	80-120 KB+
Comparative page load	~40% faster	Baseline
JS payload (comparable pages)	~90% less	Baseline
Time to Interactive	Near-instant	0.5-2 seconds (hydration)
First Contentful Paint	Excellent	Good

The ~40% faster page load and ~90% less JavaScript aren't theoretical. They reflect what happens when you remove client-side hydration from pages that don't need it. Astro sends HTML. The browser renders it. There's no JavaScript to download, parse, compile, and execute before the page becomes interactive.

Next.js static exports still ship the React runtime, the router, and framework code — even when every component is a Server Component. That JavaScript needs to hydrate the page on the client, adding latency between First Contentful Paint and Time to Interactive.

Core Web Vitals

Core Web Vital	Astro	Next.js
Largest Contentful Paint (LCP)	Excellent	Good
Cumulative Layout Shift (CLS)	Near-zero	Low-moderate
Interaction to Next Paint (INP)	Excellent (minimal JS)	Good (hydration overhead)
Typical Lighthouse Score	95-100	80-85 (static export)

Astro achieves near-perfect Core Web Vitals consistently because there's almost nothing that can go wrong. No JavaScript bundle to block rendering. No hydration to cause layout shifts. No event handler registration delay to slow interactions. The page is HTML — it renders, and it's done.

Next.js Lighthouse scores for static exports often land in the 80-85 range. That's still good, but the gap is real — and it's caused by the mandatory JavaScript payload. For sites where Core Web Vitals directly affect search rankings (which is most sites), that 10-15 point difference matters.

Framework Flexibility: One Framework vs. Many

This is where Astro introduces a capability that Next.js fundamentally cannot match.

Astro: Use Any UI Framework (or None)

Astro is framework-agnostic. A single Astro project can include components written in:

• React — via @astrojs/react
• Vue — via @astrojs/vue
• Svelte — via @astrojs/svelte
• Solid — via @astrojs/solid-js
• Preact — via @astrojs/preact

You can mix frameworks on the same page. A React header, a Svelte carousel, and a Vue form — all coexisting as independent islands, each hydrating with its own framework's runtime, only when needed.

---
import ReactNav from '../components/Nav.jsx';
import SvelteCarousel from '../components/Carousel.svelte';
import VueContactForm from '../components/ContactForm.vue';
---

<ReactNav client:load />
<SvelteCarousel client:visible />
<VueContactForm client:idle />

This isn't just a novelty. It has real practical value:

• Migration paths. Moving from Vue to React? Use both during the transition.
• Best-tool-for-the-job. Svelte's animation system is excellent — use it for that one component without committing your entire site to Svelte.
• Team flexibility. Different teams can use their preferred framework without architectural conflict.

Next.js: React, Full Stop

Next.js is a React framework. Every component is React. Every page is React. The ecosystem, tooling, and mental model are React through and through.

That's a constraint, but it's also a strength. React has the largest ecosystem in frontend development — thousands of component libraries, battle-tested patterns, and a massive hiring pool. If your team knows React and your application is React, Next.js gives you the most complete and polished framework experience available.

The trade-off is lock-in. Choosing Next.js means choosing React. If you want to use Svelte for a component or Vue for a widget, you'll need a different tool.

Full-Stack Capabilities: Where Next.js Pulls Ahead

This is Next.js territory. If you're building a web application — not a content site, but an application with authentication, database access, real-time features, and complex server-side logic — Next.js offers a full-stack framework that Astro doesn't attempt to replicate.

Next.js Full-Stack Features

• API Routes — Build REST or GraphQL APIs alongside your frontend
• Server Actions — Mutate data from client components without writing API endpoints
• Middleware — Run logic at the edge before requests reach your pages
• SSR (Server-Side Rendering) — Render pages on every request with fresh data
• ISR (Incremental Static Regeneration) — Revalidate static pages on a schedule or on-demand
• PPR (Partial Prerendering) — Combine static shells with dynamic streaming content
• Streaming — Stream server-rendered content progressively with Suspense
• React Server Components — Colocate server logic with UI components

Next.js lets you build the frontend, the API, the data layer, and the server logic in a single, unified codebase. For SaaS products, dashboards, e-commerce platforms, and applications with complex data requirements, this is a massive productivity advantage.

Astro's Server-Side Story

Astro does support server endpoints and basic middleware, and it can run in SSR mode with adapters for Node.js, Deno, Cloudflare, and Vercel. But these capabilities are simpler and more limited:

• No equivalent to Server Actions
• No ISR or PPR
• No streaming with Suspense boundaries
• No built-in data mutation patterns

Astro's server capabilities are designed for content-delivery use cases — fetching data at build time, handling form submissions, implementing basic API endpoints. They're not designed to replace a full-stack application framework.

SEO and Core Web Vitals

Both frameworks produce good SEO outcomes, but Astro has a structural advantage.

Astro's SEO edge comes from zero-JS by default. Search engines can render and index Astro pages instantly because they're static HTML. There's no JavaScript execution required to see the content. Core Web Vitals — which directly influence search rankings — are near-perfect out of the box. You don't need to optimize; the defaults are already optimal.

Next.js produces good SEO results with proper configuration. Server-rendered and statically generated pages are fully indexable. But the JavaScript payload can drag down Core Web Vitals scores, particularly LCP and INP, which means you need to actively optimize what Astro gives you for free:

• Code splitting and lazy loading
• Image optimization (Next.js Image component helps significantly here)
• Font loading strategies
• Minimizing client-side JavaScript

For content-driven sites where organic search is the primary traffic channel — blogs, documentation, landing pages, marketing sites — Astro's zero-JS default translates directly into better search performance with less optimization effort.

For web applications where SEO matters but isn't the primary concern — dashboards, SaaS tools, authenticated experiences — Next.js's SEO capabilities are more than sufficient.

When to Choose Astro

• Content-heavy sites — blogs, documentation, marketing pages, portfolios
• Performance is the top priority — you need near-perfect Core Web Vitals without optimization effort
• SEO-driven traffic — organic search is your primary acquisition channel
• Multi-framework teams — you want to use React, Vue, Svelte, or Solid components without committing to one framework
• Static-first architecture — most pages rarely change and can be built at deploy time
• Build speed matters — large sites with hundreds or thousands of pages
• Migrating between frameworks — you need a transition period where multiple UI frameworks coexist
• Minimal JavaScript philosophy — you want to ship only the JavaScript that's absolutely necessary

When to Choose Next.js

• Web applications — SaaS products, dashboards, e-commerce, authenticated experiences
• Full-stack requirements — you need API routes, Server Actions, middleware, and server-side logic in one codebase
• React ecosystem — your team is invested in React and wants the deepest, most polished React framework experience
• Dynamic, real-time content — pages that change per-user, per-request, or in real-time
• Complex data patterns — SSR, ISR, streaming, and Suspense for sophisticated data fetching
• Enterprise React — large teams standardized on React with existing component libraries and patterns
• Incremental adoption — migrating an existing React app into a framework with App Router and RSC

The Verdict

Astro and Next.js are not competing for the same use case. Choosing between them should take about 30 seconds once you understand the core question:

Is your project primarily content or primarily application?

If it's content — a blog, docs site, marketing site, portfolio, landing page — choose Astro. You'll get faster builds, faster pages, better Core Web Vitals, and the freedom to use any UI framework. The zero-JS default means your site is fast without optimization. Every performance benchmark we've seen confirms this: ~40% faster page loads, ~90% less JavaScript, 3x faster builds.

If it's an application — a SaaS product, dashboard, e-commerce platform, or anything with authentication, complex state, and server-side logic — choose Next.js. The React runtime overhead is the cost of a complete full-stack framework with SSR, ISR, Server Actions, streaming, and the largest component ecosystem in frontend development.

The wrong choice is using Next.js for a docs site (you'll fight JavaScript bloat) or using Astro for a SaaS app (you'll fight the lack of full-stack primitives). Match the tool to the problem, and both frameworks are excellent.

FAQ

Can Astro replace Next.js?

For content-driven sites, yes — and it will outperform Next.js on page load speed, Core Web Vitals, and build times. For full-stack web applications with complex server-side logic, authentication, and real-time data, no. Astro's server capabilities are intentionally simpler. The two frameworks target different use cases.

Can I use React with Astro?

Yes. Astro has first-class React support via @astrojs/react. You can use React components as interactive islands within Astro pages, and they'll only hydrate when you explicitly opt in with directives like client:load or client:visible. The difference is that Astro doesn't ship React to components that don't need it.

Is Next.js slower than Astro?

For static content pages, yes — measurably so. Astro pages load ~40% faster and ship ~90% less JavaScript because they don't include a client-side runtime by default. For dynamic web applications where you need SSR, streaming, and client-side interactivity, the comparison is less meaningful because Astro isn't designed for those use cases.

Should I migrate from Next.js to Astro?

If your Next.js project is primarily a content site — a blog, documentation, or marketing pages — and you're struggling with JavaScript bundle size, Core Web Vitals, or build times, migrating to Astro will likely solve those problems. If your project is a full-stack application that relies on Next.js's SSR, API routes, Server Actions, or ISR, Astro isn't a suitable replacement. Evaluate based on what your project actually does, not what's trending.

---

Compare live download trends, health scores, and ecosystem data for Astro and Next.js on PkgPulse. Explore more framework comparisons in our comparison hub.