Astro or Next.js: choosing a stack for a marketing site

We build marketing sites on Astro or Next.js, and which one we reach for is one of the first technical decisions we make. They are both excellent. They are built for different jobs.

The default question: how much of this is an app?

A marketing site is mostly content: pages that look the same for every visitor and change only when someone edits them. An app is mostly interaction: dashboards, accounts, things that change per user, per click.

Astro is built for the first kind. Next.js is built to scale into the second. Picking well means being honest about which one you are actually making.

Astro: content-first, zero JavaScript by default

Astro renders your pages to static HTML and ships no JavaScript unless you ask for it. Interactive pieces — a menu, a form, a carousel — become small “islands” that hydrate on their own, while everything around them stays plain HTML.

For a marketing site, that is the right default. It is why this site is built on Astro. Pages arrive fast, Core Web Vitals stay green without a fight, and there is far less client-side code to slow a phone down. When most of your page is words and images, shipping a megabyte of framework to render them is a tax with no benefit.

Next.js: when the site is really an application

Next.js is a React framework, and React earns its weight when the interface is genuinely application-like — heavy client state, real-time data, complex forms that talk to each other, an authenticated area that is really a product.

If your “marketing site” includes a configurator, a logged-in portal, or a surface that will grow into a SaaS product, Next.js stops being overhead and starts being leverage. You are not paying for interactivity you do not use; you are using it.

How we actually decide

A few questions settle it most of the time:

• Is it mostly content, edited in a CMS? Astro.
• Does it need an authenticated, stateful, app-like surface? Next.js.
• Is performance on a mid-range phone a hard requirement? Astro makes that easy; Next.js makes it possible with more care.
• Will it grow into a product within a year? Build it on the stack the product will need.

Both pair with a headless CMS, so your team edits content the same way regardless. The decision is about what the site has to do, not about what is fashionable.

The wrong reason to choose

The wrong reason is résumé-driven development — picking the heavier tool because it is the one everyone lists. A landing page rendered through a full React app is not more sophisticated; it is slower, for nothing. Good engineering is mostly knowing when the simpler tool is the correct one.

If you are weighing a rebuild and not sure which side of this line you are on, tell us what the site needs to do — and see the work we have shipped on both.