Astro vs Next.js for a Marketing Site: We Measured the Difference

Choose Astro when the marketing site is a separate thing from your product — a brochure, a blog, a docs site — and its interactive parts are a nav menu and a form. Choose Next.js when the marketing pages share code, design tokens, auth or data with an app you already ship. Both hit 100 on desktop Lighthouse. The difference shows up on a mid-range phone, and we measured ours.

We build landing-page templates in Next.js, so the bias is declared. This page includes the numbers from our own audit, including the ones that support Astro's argument rather than ours.

The decision in one table

If you take one row: the JavaScript floor. Everything else on this page is an argument about whether that floor matters for your site.

The floor, measured on our own site

Our storefront is Next.js 16 with Tailwind v4, statically rendered, with a build-time image pipeline and no request-time image optimiser. On desktop Lighthouse it scores performance 100, accessibility 100, SEO 100 on all eight main pages.

On mobile — Lighthouse's default preset, a simulated 4× CPU throttle on slow 4G — the same pages score 89 to 99. Accessibility and SEO stay at 100; performance is the number that moves.

Here is the part that matters for this comparison. We assumed the mobile gap was image bytes, so we tested it directly: with every image and every prefetch request blocked, the home page's LCP moved from 3786 ms to 3740 ms. Forty-six milliseconds. The bytes were not the problem.

What is left is React hydration, and the single largest chunk is react-dom itself at 221 KiB raw / 70 KiB gzipped. That is the framework floor for an interactive page, and it is paid on a throttled CPU before the page settles — whether or not the page needed it.

This is Astro's entire argument, and it is correct. On a page whose interactive surface is a mobile menu, shipping and parsing a React runtime buys you nothing. Astro's islands model exists precisely so that page pays close to zero.

Two honest caveats before you conclude too much:

• Our number is for a storefront, not a brochure. The interactivity is real: a preview modal, a wishlist, and an owner-download menu on every card in a 111-product grid. A five-section landing page with a nav toggle sits much closer to the floor.
• Google ranks on field Core Web Vitals — real Chrome user data for LCP, INP and CLS — not the Lighthouse lab score. Our CLS is 0 on every page. A lab performance score of 91 is not an SEO penalty; it is a hint about what real users on slow phones experience.

When Astro is the better answer

A brochure site with no product behind it. Five to fifteen pages, a contact form, a nav menu. Astro renders them as HTML files, ships no framework, and hosts for essentially nothing on any CDN.

A content or docs site. Content collections give you typed frontmatter, schema validation at build time, and a content pipeline that was designed for this rather than adapted to it. If your site is mostly Markdown, Astro is the more natural home.

A team that is not React-only. Astro renders React, Vue, Svelte and Solid components in the same project. If your designers write Svelte and your app team writes React, that is a real organisational win, not a party trick.

Genuinely static hosting. No serverless runtime, no cold starts, no per-invocation billing. Just files. For a site that changes on a deploy rather than per request, that simplicity is worth something.

When Next.js is the better answer

The marketing site is a surface of your product. This is the deciding case, and it is why most SaaS companies land on Next.js. If / is marketing and /app is the product, one repository means one design system, one deploy, one auth session, and a signup that does not hand the user across a domain boundary mid-funnel. Two codebases means two implementations of your button, and they will drift.

The page is interactive in ways islands make awkward. A pricing table that reads live prices and recalculates a quote. A dashboard preview with real state. A search field that hits your API. You can do all of this in Astro islands; you will spend the time you saved passing state between them.

Personalisation, experiments, or gated content. Anything that varies per request wants a rendering model built for per-request work.

You already have a React design system. Astro can render your React components, but not your routing, your layouts, your context providers, or your data-fetching conventions. "We can reuse our components" is true and smaller than it sounds.

Programmatic SEO at scale. Hundreds of pages generated from a data source, each with its own metadata, canonical, structured data and sitemap entry. Both frameworks can do it; Next.js's route-level metadata and generated-image APIs make it less bespoke.

The question that actually decides it

Not "which is faster." Ask this instead:

In eighteen months, will a logged-in user ever see one of these pages?

If no — the marketing site is a brochure that hands off to a subdomain, an app store, or a form — Astro is very likely the better tool, and you should not let framework familiarity talk you out of it.

If yes — the pricing page shows the user's current plan, the header swaps "Sign up" for their avatar, the docs know which features they have — you are building part of an application, and you will end up wanting an application framework. Starting there is cheaper than arriving there.

If you choose Next.js, close the gap deliberately

The JavaScript floor is a floor, not a fate. Most of the distance between a slow Next.js marketing site and a fast one is discipline, and it is the same discipline either way:

• Static-render everything. No cookies(), headers() or no-store fetches on a marketing route, or the whole page goes dynamic. Check your build output for the static marker rather than assuming.
• Default to Server Components. "use client" should be on the leaf that needs state — the menu toggle, the FAQ accordion — never on the section that contains it. This is the closest thing Next.js has to an islands model, and it works if you are strict.
• Audit what is in the initial bundle. Our own audit found the Supabase auth stack (~68 KiB gzipped) in the bundle of pages with no account UI at all, because a site-wide header imported the client at module scope. Moving it behind a dynamic import removed it from four page types. Look for this; there is usually one.
• Build image variants ahead of time. We serve pre-generated WebP derivatives from a build script and plain <img> tags — no request-time optimiser, no per-image cost. The full pipeline is written up here, including why the cover image went from 255 KiB to 33 KiB.
• Set priority on exactly one image. The LCP element on our /templates grid was loading="lazy", which cost 1.67 seconds of load delay because the browser could not discover it until layout ran. One image eager, everything else lazy.

The SaaS landing page guide goes through this as a build rather than a checklist.

Mistakes in this comparison

Frequently asked questions

Is Astro better than Next.js for SEO? Neither is better by default. Both output crawlable static HTML, both support per-page metadata, canonicals, sitemaps and structured data. Astro ships less JavaScript, which helps real-user Core Web Vitals on slow devices — a ranking input, though a modest one compared to content and links. If your Next.js site is statically rendered and disciplined about its bundle, the SEO difference is not the thing that decides this.

Can I use Astro for marketing and Next.js for the app? Yes, and it is a common setup. Two rules if you do: keep both on the same domain, using a path (/app) via a proxy rewrite rather than a subdomain, so you do not split search authority — and accept that the design system will drift between the two implementations. Budget a periodic reconciliation rather than being surprised by it.

Does Astro support React components? Yes, along with Vue, Svelte, Solid and others, via integrations. They render to static HTML by default and only hydrate when you add a client:* directive. What does not carry over is React-specific routing, layout and state conventions — those are Astro's own.

We already have Next.js landing pages. Should we migrate to Astro? Almost certainly not on performance grounds alone. Measure first: run mobile Lighthouse, then block images and re-measure to see whether your gap is bytes or execution. If it is bytes, fix the images and keep the framework. If it is execution and the pages have no app-shaped requirements, a migration is defensible — but price it against a bundle audit, which is a day and usually finds most of the difference.

What about Nuxt, SvelteKit, or Eleventy? The same axis holds. Eleventy sits where Astro does but React-free and more manual. Nuxt and SvelteKit sit where Next.js does with a different component language. The question is not the framework's name, it is whether your marketing pages are part of an application.

If you decided Next.js

Then start from a finished site rather than an empty one. Our landing templates ship statically rendered, typed, and accessible out of the box.

ASoc Lens is a product-analytics marketing site built around a dashboard-preview hero, a five-service capability grid and a three-step setup flow. ASoc Tempo markets a time-tracking product with a live timer preview, role-based use-case pages and three pricing tiers. ASoc Uptime is a web-hosting site with a domain-search widget, trust stats and a review wall — the kind of interactive marketing page that is the Next.js case rather than the Astro one.

Browse the full set of Next.js landing page templates, or the Tailwind landing page templates if you would rather bring your own framework. If your real alternative is a visual builder rather than another framework, Webflow vs Next.js runs the same decision against that option.