Every content site build starts the same way: someone types npx create-next-app without thinking. Then six months later the marketing team is waiting 40 seconds for a build to finish and no one can explain why a blog needs a Node runtime. The astro vs nextjs question has a clear answer for most content sites in 2026 — you just have to be honest about what you're building.
I've shipped both stacks this year. A docs site on Astro 5, a marketing site on Next.js 15, plus a blog migration from Next to Astro that cut build times from 90s to 6s. Here's the direct comparison, no hedging.
What is the difference between Astro 5 and Next.js 15?
Astro 5 ships zero JavaScript by default and hydrates interactive components as islands. Next.js 15 ships a full React runtime and treats every page as a React app, with Server Components as the opt-out. For content sites — blogs, docs, marketing — Astro sends 5-20x less JS to the browser without you doing anything clever.
The architectural split matters more than the version numbers. Next.js assumes you need React everywhere and lets you turn parts off. Astro assumes you need nothing and lets you turn interactivity on per component. If your site is 90% static content with a few interactive widgets, the default direction of these frameworks is doing opposite jobs.
Astro 5: The verdict
Verdict: Use Astro 5 for any content-first site — blogs, docs, portfolios, marketing pages, changelogs. It's the correct default when the primary output is HTML with sprinkles of interactivity.
Astro 5 landed Content Layer (stable), Server Islands, and typed getCollection pulls that finally make TypeScript-first content pipelines pleasant. The killer feature nobody talks about: you can drop a React, Svelte, or Vue component into an .astro file and only that component ships JS. No framework lock-in.
---
import { getCollection } from 'astro:content';
import SearchBox from '../components/SearchBox.tsx';
const posts = await getCollection('blog');
---
<h1>Blog</h1>
<SearchBox client:visible />
<ul>
{posts.map(p => <li><a href={`/blog/${p.slug}`}>{p.data.title}</a></li>)}
</ul>The client:visible directive hydrates SearchBox only when it scrolls into view. The rest of the page is static HTML. This is the whole pitch — and it works.
Real numbers from my docs site (170 pages, MDX content, Tailwind, one interactive search island):
- Cold build: 4.8s
- First page JS: 0 bytes (search hydrates on visible)
- Lighthouse performance: 100
Where Astro breaks down: apps with heavy shared state, real-time features, or auth-gated dashboards. If half your page is React talking to itself, you're fighting the framework.
Next.js 15: The verdict
Verdict: Use Next.js 15 when the site is actually an app — auth, personalisation, dashboards, e-commerce with cart state. For a blog or marketing site, it's overkill you'll regret in six months.
Next.js 15 is a great framework — for the job it's actually designed for. React Server Components, Server Actions, partial pre-rendering, and Turbopack (now stable as the default dev bundler) are genuinely impressive when you need them. If you're weighing bundler choice separately, my Vite vs Turbopack breakdown covers the tradeoffs.
The problem is defaulting to Next.js for content sites. You inherit:
- A React runtime shipped to every visitor even for pages that don't need it
- Vercel-flavoured deployment patterns that lock you into serverless thinking
- Build times that scale poorly with content count (2000-page docs sites hurt)
- Weekly framework changes because RSC APIs are still stabilising
The same 170-page site rebuilt in Next.js 15 with App Router and MDX:
- Cold build: 38s
- First page JS: ~85KB gzipped (React runtime + hydration)
- Lighthouse performance: 94
Not bad. Just not what a content site needs. And you're paying for it every deploy, every visitor, every Vercel invoice. Speaking of which — if your Next.js hosting bill has crept up, Coolify on a cheap VPS is a genuine alternative.
How do content collections compare?
Astro's Content Layer beats Next.js MDX handling by a wide margin. Typed frontmatter, schema validation with Zod, and remote loaders (Notion, CMS, JSON APIs) are first-class citizens.
// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';
export const collections = {
blog: defineCollection({
loader: glob({ pattern: '**/*.mdx', base: './src/content/blog' }),
schema: z.object({
title: z.string(),
date: z.date(),
tags: z.array(z.string()),
draft: z.boolean().default(false),
}),
}),
};Typos in frontmatter fail the build. Autocomplete works everywhere. Draft posts are filtered by type. This is what content pipelines should feel like.
Next.js has no equivalent primitive. You end up wiring Contentlayer (unmaintained), Velite, or hand-rolling fs.readdir loops with gray-matter. Fine, but you're building infrastructure the framework should own.
When does SSR actually earn its complexity?
SSR earns its cost when content varies per user or per request. Auth-gated pages, personalised feeds, real-time pricing, geo-targeted content, A/B tests that can't run client-side. If your page renders identically for every visitor, you're paying for SSR you don't use.
Astro 5 has SSR too — it just doesn't force it on you. You can render specific routes on-demand while keeping the rest static:
// astro.config.mjs
export default defineConfig({
output: 'static',
adapter: node({ mode: 'standalone' }),
});
// src/pages/api/subscribe.ts
export const prerender = false; // this route runs on the serverThe Server Islands feature in Astro 5 goes further — you can defer specific components to render server-side while the rest of the page is static HTML. Personalised greeting? Dynamic pricing block? Ship the static shell, stream the dynamic bit. Same benefit RSC promises, without the framework tax.
Which framework has faster build times?
Astro wins on build time by 5-10x for content-heavy sites. It's not close. Next.js has to bundle React trees, resolve RSC boundaries, and generate hydration payloads for every route. Astro emits HTML.
My rough numbers from real projects:
- Astro 5, 500-page docs site: 12s cold, 2s incremental
- Next.js 15, same content: 90s cold, 15s incremental with Turbopack
At scale this matters. Vercel bills by build minute. CI queues back up. The 10s-vs-90s difference compounds across every push, every branch deploy, every preview URL. If you deploy content-only PRs 20 times a day, Astro saves you real time and money.
Should you migrate an existing Next.js content site?
Migrate if build times, bundle size, or hosting costs actively hurt you. Don't migrate for aesthetics. The port itself is straightforward — Astro components are HTML with frontmatter, MDX moves over almost unchanged, most React components can be kept and hydrated as islands.
The pain points are usually: any custom Next.js middleware, ISR patterns, and image optimisation quirks. Astro's <Image /> component is different but honestly better once you learn it. Budget a weekend for a mid-size blog, a week for a docs site with custom infrastructure.
The bottom line
Pick Astro 5 for content sites. Pick Next.js 15 for apps. The dividing line is whether interactivity is the exception or the rule. If you're building a blog, docs, marketing site, portfolio, or changelog — Astro is the right default in 2026. If you're building a dashboard, SaaS product, or anything with per-user state — Next.js earns its complexity.
The default-to-Next.js habit is a hangover from a time when static generation was painful. It isn't anymore. Astro 5 is what "just the right amount of framework" looks like for the content web. Host it anywhere — Netlify, Vercel, or a $5 VPS. It doesn't care.
FAQs
Is Astro faster than Next.js for blogs?
Yes, significantly. Astro ships zero JavaScript by default and builds 5-10x faster than Next.js for content-heavy sites. Lighthouse scores of 100 are the norm rather than the goal.
Can I use React components in Astro 5?
Yes. Astro supports React, Vue, Svelte, Solid, and Preact as first-class integrations. You add a client:* directive to hydrate the component as an island — the rest of the page stays static HTML.
Does Astro 5 support server-side rendering?
Yes. Astro 5 supports hybrid output — static by default with per-route SSR opt-in via export const prerender = false. Server Islands let you defer specific components server-side while the shell stays static.
Should I use Next.js 15 for a marketing site?
Only if you already have a Next.js codebase and consistency matters more than performance. For a greenfield marketing site, Astro 5 gives you smaller bundles, faster builds, and lower hosting costs with no meaningful downside.
What's the migration cost from Next.js to Astro?
Roughly a weekend for a small blog, a week for a mid-size docs site. MDX and React components port cleanly. The tricky bits are Next.js-specific middleware, ISR patterns, and any deep coupling to the App Router file conventions.