Frontend Performance

Astro vs Next.js for Content-Site Performance

This guide is part of Astro & SvelteKit Performance, within Framework Performance. Content sites — blogs, documentation, news, marketing sites, e-commerce category and product pages — share a profile: most of each page is text and images that are the same for every visitor, with a few interactive elements. For these sites, the most important performance factors are fast HTML delivery (static or cached), small or no JavaScript, optimised images and fonts, and good interactivity for the few interactive parts.

Astro and Next.js can both build excellent content sites, but they start from different defaults. Astro ships zero JavaScript unless you add islands; Next.js ships the React runtime and hydrates client components, with Server Components (App Router) reducing how much code reaches the browser. The right choice depends on how interactive the site is, the team's existing stack, and whether the content site shares code with an application.

Astro vs Next.js for content sites Comparison of Astro and Next.js on defaults and characteristics that matter for content-site performance. Astro vs Next.js for content sites Aspect Astro Next.js (App Router) Default client JS none React runtime + client components Interactivity islands, any framework React client components Rendering static, SSR, server islands static, ISR, SSR, PPR Navigation MPA (+ optional client router) client router + prefetch Best fit mostly static content content mixed with app features

Rapid Diagnosis

  • Measure JavaScript per page on your current site and identify what is actually interactive.
  • Check the share of static content: if most pages are identical for all users, static-first approaches fit.
  • Check team expertise: React-heavy teams can use React in both.
  • Check integration needs: shared components with a logged-in app favour a single framework.

Root Cause Analysis: Why Content Sites Get Slow

1. App frameworks used for documents. Entire pages hydrate to support small interactive parts.

2. Client-side data fetching. Content loaded after JavaScript instead of in HTML.

3. Unoptimised media. Images and fonts dominate LCP.

4. Third-party scripts. Analytics, ads and widgets compete with rendering.

Step-by-Step Resolution

1. Quantify interactivity

List interactive components per template. If most pages have a handful of small widgets, Astro's islands model will ship much less JavaScript; if pages are largely interactive, the gap narrows.

2. Get the best from Next.js if you stay

Use the App Router with Server Components for content, keep client components small and at the leaves, prerender or use ISR, mark the LCP image with priority, use next/font, and load third-party scripts late. Well-configured Next.js content pages can ship well under 100KB of JavaScript.

3. Get the best from Astro if you move

Render content as static HTML, use islands with client:visible or client:idle, avoid multiple UI frameworks, use astro:assets for images, and use server islands for personalised parts.

4. Measure on your own pages

Build a representative template in both (or compare with an existing implementation), and measure JavaScript, LCP, TBT and INP on a throttled profile. Decide with data.

bash
# Compare JavaScript transferred for the same template built two ways (Lighthouse CLI).
npx lighthouse https://astro-preview.example.com/blog/post --only-categories=performance --output=json --quiet --chrome-flags="--headless" | jq '.audits["resource-summary"].details.items[] | select(.resourceType=="script") | .transferSize'
npx lighthouse https://next-preview.example.com/blog/post --only-categories=performance --output=json --quiet --chrome-flags="--headless" | jq '.audits["resource-summary"].details.items[] | select(.resourceType=="script") | .transferSize'
# trade-off: a single lab run is noisy; run several and compare medians, and
# confirm with field data after launch.

Blog post template, same design (median of 5 lab runs) Bar chart comparing JavaScript and total blocking time for the same blog template in Astro and in two Next.js configurations. Blog post template, same design (median of 5 lab runs) Next.js Pages Router 180KB JS Next.js App Router (server components) 92KB JS Astro (one island, client:visible) 11KB JS

Verification

Compare lab results on the same content and design, then verify with field data after launch: LCP, INP and CLS per template. Check build times and developer experience, since they affect how easily the site stays fast over time.

Worked Example: A News Publisher's Evaluation

A news publisher with a Next.js Pages Router site evaluated moving article pages to Astro. Their article template shipped 210KB of JavaScript, with LCP p75 2.8 seconds and INP p75 240ms. They built the template two ways: Next.js App Router with Server Components (95KB JS) and Astro with two islands (14KB JS). Lab LCP was similar (both server-rendered with optimised images); TBT was 280ms vs 40ms; INP in a field pilot was 160ms vs 80ms. Because article pages shared little code with their subscription app, they moved articles to Astro and kept the subscription flows in Next.js. Overall INP p75 across the site fell by 45%.

When Next.js Is the Better Fit

Next.js is often the better choice when content pages are tightly integrated with application features (accounts, carts, personalisation across pages), when the team wants one React codebase for marketing and product, when client-side navigation and shared state across pages matter, or when partial prerendering and ISR fit the content model. With careful use of Server Components, its performance on content pages can be very good — the gap with Astro is largest when Next.js is used with client components everywhere.

When Astro Is the Better Fit

Astro fits best when pages are mostly static, interactivity is limited and local, the site is content-driven (Markdown, MDX, headless CMS), and the team values minimal JavaScript by default. It also allows using components from several frameworks, which can ease migrations. For sites that later need more application-like features, Astro can host islands or link out to a separate app.

Choosing between Astro and Next.js for a content site Decision sequence for selecting Astro or Next.js for a content-focused website. Choosing between Astro and Next.js for a content site Are pages mostly static with small, local interactivity? Astro yes no Do content pages share state and code with an app? Next.js (App Router) yes no Is the team React-only and wants one codebase? Next.js with Server Components yes no Prototype one template in both and measure

Common Mistakes

  • Choosing by benchmarks alone. Your content, team and integrations matter.
  • Comparing a poorly configured Next.js site with Astro. Configure both well before deciding.
  • Ignoring images and fonts. They often dominate LCP regardless of framework.
  • Migrating without field measurement. Lab gains may not match real-user gains.

Edge Cases

Large documentation sites. Build times matter; both support incremental approaches, but check with your page count.

Personalisation. Astro's server islands and Next.js partial prerendering both handle personalised fragments on cached pages.

Search. Client-side search adds JavaScript; load it on demand in either framework.

i18n. Both support localised routing; check how locale handling affects static generation.

FAQ

Is Astro always faster than Next.js?

For mostly static content, Astro usually ships less JavaScript by default, which helps INP and TBT. With careful Server Component use, Next.js can be close. LCP depends more on images, fonts and delivery.

Can I use React components in Astro?

Yes, as islands, so React teams can reuse components while shipping less JavaScript overall.

Does Next.js App Router ship less JavaScript than Pages Router?

Typically yes, because Server Components do not ship their code to the client.

Which has better SEO?

Both server-render or prerender HTML, which is what search engines need. Performance differences can affect Core Web Vitals, a minor ranking factor.

Is migration worth it?

When JavaScript and hydration are the main bottlenecks on content pages and those pages are separable from the app, often yes. Prototype one template first.

What about client-side navigation?

Next.js navigates client-side with prefetching. Astro is a multi-page site by default, with an optional client router; speculation rules can make Astro navigations nearly instant.

How do build times compare?

Both handle large sites; build times depend on page count, image processing and data fetching. Measure with your content.

Can both deploy to the edge?

Yes. Both support static hosting and server or edge rendering through adapters on major platforms.

Can I combine Astro and Next.js on one domain?

Yes. Route marketing and content paths to Astro and app paths to Next.js at the CDN or reverse proxy. Shared design tokens and components keep the experience consistent.