Use Astro when most of your page is content and interactivity is the exception. Use Next.js when most of your page is application and interactivity is the rule. That one distinction decides this comparison more reliably than any benchmark, because it describes the architectural choice each framework made rather than a score either one can win.
The numbers still matter, so here they are first.
The measurable difference
| Astro | Next.js | |
|---|---|---|
| Default client JavaScript | Zero | React runtime plus page JS |
| Typical page load | Roughly 40% faster on comparable content pages | Baseline |
| JavaScript shipped | Roughly 90% less on comparable content pages | Baseline |
| Lighthouse out of the box | 95 to 100 typical, LCP under 1s, zero CLS | Achievable, but requires deliberate work |
| Best fit | Blogs, docs, marketing, publishing, portfolios | Dashboards, real-time feeds, auth-heavy apps |
Those Astro numbers are real and also somewhat unfair, because they compare content pages. Astro ships less JavaScript on a blog post because a blog post does not need JavaScript. Put a live collaborative editor on the page and the gap closes to almost nothing, since both frameworks have to ship the editor.
The architectural difference underneath
Astro renders everything to HTML at build or request time and ships no client JavaScript unless you explicitly ask for it. When you do want interactivity, you mark a specific component as an island:
Everything outside that island is static HTML with no runtime at all. The client:visible directive delays even that island's JavaScript until it scrolls into view. There are also client:load, client:idle, and client:media for different tradeoffs.
Next.js takes the opposite default. React runs through the whole stack, and Server Components let you opt specific pieces out of shipping to the client:
These converge more than the framework marketing on either side admits. Server Components narrowed the JavaScript gap considerably. Astro can render React components. The difference that remains is the default and what it costs you to fight it.
Where Astro wins clearly
Content sites, and it is not close. A blog, a documentation site, a marketing site, a portfolio. These are pages where the JavaScript exists to make a mobile menu open and a form submit, and Astro ships exactly that much and no more.
Astro also handles a specific situation Next.js does not really address: mixing component frameworks in one project. React component from an old design system, a Vue widget someone else maintains, a Svelte chart. Astro renders all of them on the same page. That is genuinely useful during migrations, and I have used it exactly for that.
Hosting cost is the underrated one. Static HTML on a CDN is close to free at any traffic level. Reported savings run 50% to 80% versus running the equivalent as a server-rendered app, which for a content site with real traffic is not a rounding error.
Where Next.js wins clearly
Anything where the page is an application. A dashboard with filters and live data. An authenticated product with per-user state on every view. Anything with complex forms, optimistic updates, or real-time subscriptions.
In these cases Astro's advantage evaporates because you end up marking most of the page as islands, at which point you have Next.js with extra steps and a less mature story for the app-shaped problems. Next.js has middleware, route handlers, streaming, and a data mutation story that Astro is still building out.
The ecosystem gap is real too. Auth libraries, ORMs, deployment platforms, and hiring all have deeper Next.js support. That is not a technical argument but it is a real cost.
The case that is genuinely ambiguous
A marketing site with a logged-in area. A documentation site with an interactive playground. A content site with a members dashboard. This is where most real decisions actually live, and the honest answer is that either works.
What I would ask: which half do you expect to grow? If the content grows and the app stays a small corner, Astro and put the app corner behind its own route or subdomain. If the app grows and the content stays a handful of pages, Next.js and accept slightly heavier marketing pages.
Guessing wrong is not fatal but the migration is real work in either direction, so it is worth ten minutes of thought rather than picking whichever you used last.
What I actually use
Astro for anything content-shaped, without much deliberation at this point. The performance is free rather than earned, which matters because performance you have to maintain tends to decay. A Next.js site that hits 95 Lighthouse on launch day drifts down over a year as people add things. An Astro content site mostly stays where it started because there is no JavaScript budget to blow.
Next.js when I am building something people log into. Not because Astro cannot, but because every problem I hit in an app-shaped project has a well-worn Next.js answer and I would rather spend that time on the product. If you are tuning either one, the same Core Web Vitals fundamentals apply regardless of framework.
Reference: Astro documentation and Next.js documentation.