Astro vs Next.js: which to choose for a marketing site or a product in 2026

Which one should you choose?

Choose Astro when most pages look the same to every visitor: a marketing site, a blog, documentation, a site in several languages. Choose Next.js when the project is mostly a signed-in product, with dashboards, editors, accounts and screens that keep state in the browser. The dividing line is how much of the site behaves like an application, not how many pages it has.

We build in both, through our Astro development and Next.js development services, and we run both in production: dardo.studio is an Astro site, and the front ends of Hyper and A medio tono are Next.js 16 on Cloudflare Workers. Either framework can do the other's job. What differs is the default each one starts from, and what it costs you to move away from it. Facts below are as of October 2026.

Two different starting points

Astro starts from HTML. Pages, routes and endpoints are pre-rendered at build time by default, and a route that needs a server opts out on its own, with one line of code and an adapter. Components render to HTML and their JavaScript is stripped, unless you mark one as a client island that loads at once, when the browser is idle or when it scrolls into view (Astro Docs). Islands can be written in React, Preact, Svelte, Vue or Solid, and server islands let a slow or personal fragment, such as an account menu, render separately so it doesn't hold up the rest of the page.

Next.js starts from a React application. In the App Router, layouts and pages are Server Components by default and anything interactive is a Client Component, marked with the use client directive. On a first visit the browser gets HTML, then the RSC payload React uses to reconcile the server and client trees, then the JavaScript that hydrates the interactive parts (Next.js Docs). With Next.js 16.4, released on 6 October 2026, the team recommends Cache Components for every app: new projects get it by default, and it becomes the default in Next.js 17. A page can then combine a prerendered shell, cached sections and sections rendered for each request.

The practical difference: in Astro, JavaScript is something you add, one component at a time. In Next.js, React and the client router come with every page, and the work is keeping your own code out of the bundle. One rule catches teams out: once a file is marked use client, everything it imports ships to the browser too.

What we measured on our own sites

On 14 October 2026 we downloaded pages from sites we built and added up the JavaScript each one loads on arrival, before a visitor clicks anything: the gzip-compressed size of every script file, not counting Cloudflare's analytics beacon. Next.js can prefetch more as links scroll into view; we didn't count that.

Across the web, the averages differ more than our two sites do: our website platform speed report shows how many Astro and Next.js sites pass Core Web Vitals for real visitors, and how much JavaScript each ships, by country.

The 43 KB on dardo.studio covers our own small scripts for the theme, menus and the analytics preferences panel, one page-transition library and Google's web-vitals library for our field measurements; no UI framework reaches the browser. PostHog's library, about 96 KB more, starts after the page has loaded, and not at all for visitors who opt out.

The A medio tono article is prerendered and served from Cloudflare's cache, so the server does almost no work; the weight is all in the browser. About 121 KB of it is the two files that hold React DOM and the Next.js client runtime; the rest is the site's own components and libraries. The RSC payload is a serialized copy of the rendered page that React uses in the browser, many times larger than the roughly 14,000 characters of text a reader actually sees.

This isn't a benchmark. The sites have different features, and A medio tono's tuner and metronome are interactive tools where a React codebase earns its place. It shows where each framework puts weight by default: Next.js buys client-side navigation and one React codebase, and a page that is mostly text needs neither. On Hyper, the largest file, about 167 KB, is three.js itself; on a 3D page like that, the graphics library outweighs the framework. Our website speed optimization work starts from measurements like these, not from the framework's reputation.

Content collections or data fetching

Astro treats content as data it loads during the build. Content collections give each content type a schema, and an entry that breaks it stops the build with an error instead of reaching a visitor. Loaders read Markdown, JSON or YAML from the repository, or pull from a CMS, a database or an API. Astro recommends build-time collections whenever possible and keeps live collections for data that must be current on every request.

The price of that model is a rebuild. On dardo.studio an article goes live two to three minutes after an editor publishes it, because the site rebuilds from the CMS. That suits articles and service pages; stock levels or prices that change during the day belong in on-demand routes.

Next.js fetches data inside Server Components, from wherever it lives, and caching is a decision written into the code. With Cache Components, use cache marks a function or component as cacheable, cacheLife sets how long it stays fresh and cacheTag labels it so it can be refreshed when content changes (Next.js Docs). Two details in that documentation matter for marketing sites:

• Caches belong to a deployment. Cached results don't carry over to a new deploy, so anything cached at request time is computed again after each release.
• Some crawlers get a request-time render. When a page's metadata is dynamic, Next.js detects certain bots by user agent and renders the page on request for them; a data source that only works during the build can send those bots a 500 error.

The CMS behind either framework shapes the editors' day more than the framework does; our headless CMS development service and our comparison of Sanity, Contentful and Payload cover that choice.

Hosting and running cost

A fully pre-rendered Astro site is a folder of files that any static host can serve. On Cloudflare Workers, requests to static assets are free and unlimited (Cloudflare Docs), so the hosting line for a marketing site can be zero. Routes rendered on request need an adapter; Astro maintains official ones for Cloudflare, Netlify, Vercel and Node. dardo.studio is static on Workers except the CMS draft preview, which a Worker renders on request; Superame, a public ranking with verified payments that we built, runs Astro 7 in server mode on Vercel with a Postgres database.

Next.js supports every feature when it runs as a Node.js server or in a Docker container; a static export runs anywhere but drops everything that needs a server (Next.js Docs). As of October 2026 the verified adapters, which run the full Next.js compatibility test suite, are Vercel and Bun. Cloudflare and Netlify are building verified adapters and meanwhile offer their own integrations, whose feature support can vary, so check every feature you rely on.

Both of our Next.js sites run on Cloudflare Workers through OpenNext; A medio tono moved there from Vercel on 30 September 2026. Workers' paid plan starts at USD 5 a month with 10 million requests included and no charge for bandwidth. Wherever a Next.js app runs, a route rendered per request costs compute on every visit, which is why 16.4 added ensureStatic, a setting that fails the build when a dynamic component slips into a page meant to stay static. Our Next.js development page breaks down Vercel and Cloudflare bills in detail.

Upgrades and support windows

Next.js has shipped a new major version every October since 2021 and publishes a written support policy: the current major is in Active LTS, and the previous one gets critical fixes and security updates for two years after its first release. Astro moves faster and supports less: Astro 7 shipped on 22 June 2026, about three months after Astro 6, and the core team provides security fixes for only one previous major, with no end date published (Astro Docs).

A static Astro site that misses an upgrade keeps serving the same files, and no server code runs when a visitor arrives. A Next.js app runs server code for every request that isn't served from cache, so its security releases need applying quickly. In December 2025 a flaw in React Server Components, rated CVSS 10.0, left Next.js 15 and 16 App Router apps open to remote code execution; there was no workaround, only an upgrade (Next.js). Name an owner for upgrades; our website maintenance plans include them.

Ecosystem and the team you have

Next.js has the larger ecosystem by a wide margin. In the week of 6 to 12 October 2026, npm recorded about 67.5 million downloads of next and 7.3 million of astro (npm), roughly nine to one, and about 188 million of react itself. Downloads include automated builds, so treat them as a rough gauge of ecosystem size. Next.js is React all the way down, so every React library and every developer who knows React is available to it.

Astro asks less of a team. Its components are close to HTML, its docs say anyone who knows HTML can write one, and React components still work inside it as islands. Next.js asks the team to understand where each piece of code runs: which components are server or client, which props can cross between them and which caching rule applies to each read. That knowledge pays off when you're building a product. When the job is publishing pages, it's overhead.

A decision table

When the answer is both, or neither

A SaaS company can also use both: the marketing site on Astro at www and the product on Next.js at app, each deployed on its own schedule. One Next.js codebase works better when a single small team owns everything and wants one set of components. Designing the marketing side of that split is our SaaS website design service, and scoping the product is web app development.

Sometimes the answer is neither. If your marketing team needs to build and rearrange pages visually, every week, without asking a developer, a framework and a headless CMS will feel slow to them however fast the pages load. Our comparison of Webflow and Framer covers that route.

How we decide on a project

We list every route and mark it as the same for everyone, changing when content is published, or different for each visitor. If the last group is empty or holds a handful of routes, such as a draft preview, a search page or a payment return, we build in Astro. If the signed-in product is the reason for the project, we build in Next.js and keep the marketing routes static from the first commit.

If you're moving an existing site, our WordPress to Astro guide covers the most common migration, and our web development service covers builds where the framework is still an open question. If you'd like a second opinion, send us your route list and we'll tell you which framework we'd pick and why.