You deploy a blog post. It’s 1,200 words of static text and two images. Your framework ships 85KB of JavaScript so React can hydrate a page that has zero interactivity. The browser downloads, parses, and executes a virtual DOM reconciler to render an article that was already HTML on the server.
You’ve built a fighter jet to deliver mail. And in the astro vs nextjs debate, that’s the part most developers refuse to examine — because admitting it means admitting you overengineered your content site.
The Numbers That Should Embarrass Us
Here’s the part where I show you the receipts.
JavaScript shipped to the browser: Astro sends 0–8KB by default. Next.js ships 80–120KB of React runtime baseline. Same content. Same static HTML output. Ten times the JavaScript on the Next.js side, doing nothing the user asked for.
Lighthouse scores: Astro hits 100 without trying. Next.js static sites typically land at 88–95 — because the React runtime still loads, still parses, still executes. If you’ve been chasing performance scores with lazy loading tweaks or third-party script audits, your framework might be the thing holding you back.
Hosting costs at scale: Astro static on Netlify runs about $15/month for 500K page views. Next.js SSR on Vercel? Roughly $150/month for the same traffic. That’s not a rounding error. That’s a 10x difference in your infrastructure bill.
Build times: 1,000-page site. Astro builds in 18 seconds. Next.js takes 52 seconds. Three times slower, every deploy, compounding across every CI run.
These aren’t cherry-picked edge cases. This is the default experience. Every Next.js content site ships the React runtime whether you need it or not. Every Astro site ships nothing unless you ask.
The numbers are clear. But I know the objection already forming in your head: I already know React. Learning something new isn’t free.
You Already Know 80% of Astro
Fair point. Wrong conclusion.
Astro components look like JSX with a frontmatter fence at the top. If you’ve written a React component, you can read an Astro component in ten minutes. The syntax isn’t the barrier. The mental model is.
In Next.js, everything is React and you opt out of JavaScript where you can. In Astro, nothing ships JavaScript and you opt in where you need it. That inversion sounds small. It changes everything about how you architect a content site.
This is what Astro’s islands architecture actually means in practice: your blog post renders as pure HTML. Zero JavaScript. But that search bar in the header? That’s a React component, hydrated on its own, isolated from the rest of the page. A comment form at the bottom? Another island. A dashboard widget behind auth? Island.
The rest of the page — the 95% that’s just text and headings and links — ships as HTML. Because that’s what it is.
And here’s the part that dissolves the learning curve objection entirely: Astro supports React, Vue, Svelte, and Solid in the same project. Your existing React components work. You don’t rewrite them. You just stop shipping their runtime on pages that don’t need it.
Your React knowledge isn’t wasted. It’s targeted.
That handles the learning curve concern. But you’re a pragmatist — you want to know where the line is. When does Next.js actually win?
The Decision in 30 Seconds
I’ll draw it clearly, because every other astro vs nextjs comparison refuses to.
Use Astro: Blogs. Documentation sites. Marketing pages. Portfolios. Content-heavy sites with occasional interactivity. Any project where most pages are read-only. If users come to read, not to interact, Astro is the correct architecture.
Use Next.js: Authenticated dashboards. Real-time collaborative apps. E-commerce with complex cart and checkout flows. Applications where every page needs client state. If users come to do things, Next.js earns its runtime.
The honest middle: A marketing site with one authenticated section doesn’t need two frameworks. It needs Astro with a React island for the auth part. You don’t pick one framework for every page. You pick the right default and opt in to complexity where it’s justified.
The 2026 context makes this clearer. Astro 6 beta introduces Server Islands — deferred dynamic content rendered at the edge without shipping client JavaScript. Cloudflare acquired the Astro team earlier this year, which kills the “what if Astro disappears?” concern. The framework has commercial backing and a clear roadmap.
Next.js 15’s React Server Components reduce the JavaScript shipped, and that’s genuine progress. But RSC still requires the React runtime baseline. It’s optimization within the React paradigm — not a rethinking of whether you need React at all.
For content sites, the question isn’t “which React mode ships less JavaScript.” The question is “does this page need React.” If you’ve been through the bundle analysis exercise, you already know the answer for most of your pages.
That clarity helps if you’re starting fresh. But what if you already have a Next.js content site and the numbers above are making you uncomfortable?
The Migration Reality Check
Not every migration is worth it. Here’s how to know.
Two-day migration: Your Next.js site is mostly Markdown or MDX content with minimal custom React components. Astro’s content collections handle Markdown natively. Move your posts, adjust frontmatter, write a layout template. The hard part is CSS, not logic. If this describes your site, the migration is a weekend project.
Two-week migration: You have a significant React component library — custom hooks, shared state, complex data fetching patterns. You’ll need to decide what stays as React islands and what converts to Astro components. This is architecture work, not find-and-replace. Budget time for it.
Don’t migrate: Your “content site” is actually an application wearing a blog’s clothes. Heavy client interactivity on every page. Auth flows. Real-time updates. WebSocket connections. That’s a Next.js application. Own it. State management and all.
Quick self-assessment: count the interactive components on your average page. Fewer than five? Astro. More than five? You probably have an app, not a content site.
Still not sure? Look at your performance checklist. If most of your optimization work is fighting your own framework’s JavaScript overhead, that’s your answer.
Ship HTML, Not Excuses
Remember that blog post from the opening? 1,200 words. Two images. Zero interactivity. 85KB of React runtime.
The question was never “Astro or Next.js.” The question is whether your page needs client-side JavaScript. For content — articles, docs, marketing pages, portfolios — the answer is almost always no.
Astro’s default is zero JavaScript. Opt in where needed. Next.js’s default is the React runtime. Opt out where you can. One of those defaults is correct for content. We’ve been using app architecture to solve content problems, and that’s not a framework issue. That’s an engineering judgment issue.
Your blog post doesn’t need a virtual DOM. Ship the HTML.