Next.js vs Astro — which framework is right for your project?

Next.js and Astro are both excellent frameworks. They're also built for fundamentally different use cases, and choosing between them based on popularity or momentum rather than actual project requirements is a common mistake.

Here's an honest breakdown of when each makes sense.

What they're actually optimised for

Next.js is a full-stack React framework. It handles server-side rendering, API routes, authentication, edge middleware, and React Server Components. It's built for applications — products where users log in, data changes based on user state, and interactivity is a core part of the experience.

Astro is a content-focused framework. Its core philosophy is "zero JavaScript by default" — pages are rendered to HTML, and JavaScript is added only for components that actually need it. It's optimised for content-heavy sites where most pages are static or nearly static.

The distinction matters a lot because it determines how much JavaScript the browser receives. A well-built Astro site sends almost no JavaScript. A well-built Next.js site sends the JavaScript needed for its interactive features, which is more than zero.

When Next.js is the right choice

• You have authenticated user experiences. Login state, user-specific data, personalised content — these need server-side data fetching and session management. Next.js handles this naturally.
• You have complex interactivity. Real-time updates, dynamic filtering, multi-step forms with state management, client-side data fetching. React's ecosystem is mature and deep for these use cases.
• You're building an app that also has a marketing site. Keeping them in the same codebase (same components, same deployment pipeline) often outweighs the performance advantage of separating them.
• Your team knows React. Framework expertise is a real asset. If your team writes React every day, Next.js lets them stay in their zone of competence.
• You need API routes. Next.js API routes let you handle webhooks, form submissions, and third-party integrations in the same codebase as your frontend.

When Astro is the right choice

• You're building a content-heavy site. Blog, documentation, marketing site, news site, portfolio. Astro's MDX integration and content collection API are genuinely excellent for these use cases.
• Core Web Vitals and performance are the primary concern. Astro sites are fast by default. Getting excellent Core Web Vitals scores in Astro requires less effort than in Next.js.
• You want to use components from multiple frameworks. Astro is framework-agnostic — you can use React components, Svelte components, Vue components, and plain HTML in the same project. Useful if you have a mixed team or want to migrate incrementally.
• The site is mostly static. If 95% of your pages don't change based on user state, serving static HTML is the right approach.

Performance: the honest comparison

Astro sites routinely score 99–100 on Lighthouse for performance on content pages. Next.js sites can achieve similar scores, but it requires more intentional effort — code splitting, bundle analysis, deferring non-critical scripts.

The gap closes significantly with Next.js App Router and React Server Components, which shift as much work as possible to the server and reduce the client-side JavaScript bundle. For new Next.js projects using App Router correctly, performance is no longer the clear differentiator it was two years ago.

The "just use Next.js for everything" temptation

There's a temptation to default to Next.js for every web project because it's the familiar, proven choice. This is usually fine — you won't get wrong results with Next.js, even for a simple marketing site.

The tradeoff is complexity you didn't need to take on. A marketing site in Next.js has App Router, Server Components, edge middleware, and RSC streaming — concepts that need to be understood to be maintained correctly. A marketing site in Astro is simpler to reason about, simpler to hand over, and simpler to maintain.

The right default for a pure content site is Astro. The right default for anything with auth or significant user-state interactivity is Next.js. The right default for an application that also has a blog is "make a judgment call based on which side dominates."

We build in both, and we pick based on what the project actually requires rather than what we're more practiced with. That's part of what we discuss at the start of any web development engagement. If you're evaluating this for a specific project, book a call.