The short answer
If the site is mostly content — pages, articles, docs, campaign sites — choose Astro: it ships almost no JavaScript by default, so the performance budget holds after launch without ongoing policing. If the surface is app-like — dashboards, portals, logged-in product, heavy personalization — choose Next.js: the React runtime earns its weight there, and the ecosystem and hiring pool are unmatched. Most estates we audit are content-shaped with a few interactive moments, which is why Astro is our more frequent recommendation — but it’s the shape of your site, not a league table, that decides.
Where they differ
| Astro | Next.js | |
|---|---|---|
| Best-fit surface |  Content estates: marketing sites, docs, blogs, multi-brand publishing. | App-like builds: dashboards, portals, authenticated and personalized experiences. |
| JavaScript payload | Near-zero by default; JS ships only for the components (islands) that need it. | Ships the React runtime; Server Components reduce it, but the baseline is an application. |
| Rendering model | Server-first: static output by default, per-route SSR where needed. | Per-route choice of SSG, ISR, SSR, and edge rendering — the flexibility is the point. |
| UI layer | Framework-agnostic islands: React, Vue, Svelte, Solid, mixed per component. | React only — a constraint or a guarantee, depending on your team. |
| Performance defaults | Fast by default; new content pages add no client-side weight. | Fast when the rendering mix is right; holding a budget on content pages takes discipline. |
| Hosting & runtime | Static output runs anywhere; adapters cover Vercel, Netlify, Cloudflare, self-hosting. | Runs everywhere, but the smoothest feature set (ISR, previews, edge) is on Vercel. |
| Ecosystem & hiring | Growing fast; smaller pool of dedicated specialists, but any React/Vue/Svelte developer is productive quickly. | The deepest talent pool and library ecosystem in front-end development. |
| Lock-in & portability | Plain HTML and assets out; content collections are files or CMS-backed — low switching cost. | Portable in principle; deep use of platform-specific features raises the cost of leaving. |
Choose Astro when
- The rebuild is a marketing or content estate, and Core Web Vitals are a hard requirement rather than an aspiration.
- You’re consolidating multiple brands, markets, or locales onto shared content infrastructure and want each site to ship only the JavaScript it needs.
- Your existing components are spread across React, Vue, or Svelte and you want to reuse them without adopting one runtime everywhere.
- Editors publish frequently, and you want performance to be a property of the architecture, not of code review vigilance.
Choose Next.js when
- The center of gravity is an application: logged-in product, dashboards, portals, checkout, or heavy per-user personalization.
- Your engineering organization is standardizing on React and hiring depth matters more than default page weight.
- You need per-route rendering flexibility — static marketing pages, ISR for large content sets, SSR for personalized views — inside one codebase.
- First-party Vercel hosting features (previews, ISR, edge) are part of the operating model you want.
If you’re switching
Moving between the two is a real project, not a swap. Both are component-based and CMS-agnostic, which helps: a headless content model carries over unchanged, and React components move into Astro islands largely intact (Astro to Next.js means rewriting non-React islands). The work that needs planning is the rest: routing and redirect maps so SEO equity survives, rebuilding data-fetching around each framework’s model, re-testing rendering behavior page-type by page-type, and retraining whoever operates deploys and previews. Coming from a legacy platform instead — an old CMS front end, a Gatsby estate — the framework choice is the smaller half of the decision; the content model and migration controls are the larger half. Either way, the redirects, content mapping, and performance baselines are named workstreams in our website migration service, not assumptions.
The Bejamas take
We build with both, so the recommendation isn’t tribal. In an audit we model your page inventory against the content-vs-app line: how many routes are static content, how many are personalized or authenticated, what the team can hire for and maintain. Content-shaped estates — most multi-brand marketing platforms — get Astro. App-shaped builds get Next.js. Mixed estates sometimes get both, split along the same line. Then we build it: Astro development or Next.js development.