Astro vs. Next.js: architecture and performance compared

Astro and Next.js appear side by side in almost every discussion about how to build a modern site with JavaScript. Both generate HTML on the server, use file-based routing and accept React components. That is why they seem interchangeable.

They are not. They start from different questions. Astro asks, “how much JavaScript does this page really need?”. Next.js asks, “how do you deliver a fast React application, with parts on the server and parts in the browser?”.

This article compares the architecture and performance of the two based on the official documentation (Astro 7 and Next.js 16.4, consulted on October 8, 2026) and on public data from the HTTP Archive. Disclosure: the Token & Tech site is built with Astro. That is why we show, with the same care, the cases in which Next.js is the better choice.

Two different premises

The Why Astro? page presents Astro as a framework for content-driven sites, which prefers to render on the server and ships zero JavaScript by default.

Next.js is a framework for React applications. Astro’s migrating from Next.js guide sums up the difference: Next.js is treated as a single-page React application, while Astro is a multi-page site.

A single-page application (SPA) loads once and swaps the content on screen with JavaScript, without reloading the document. A multi-page application (MPA) delivers a new HTML document for each link clicked. Both approaches have merits, and much of the difference that follows comes from this starting choice.

How each one renders a page

In Astro, the page is HTML assembled at build time or on the server. The documentation on islands explains that client-side JavaScript is stripped from all components unless you add a directive such as client:load or client:visible. Each island loads independently. Server islands (server:defer) let you render a personalized section after the rest of the page.

In Next.js, with the App Router, pages and layouts are Server Components by default, according to the Server and Client Components page. They run on the server and can fetch data directly from the source. When you need state, events or browser APIs, you mark the file with "use client" and it becomes a Client Component.

The documentation describes what reaches the browser on the first visit:

1. The HTML, to show a fast, not yet interactive preview.
2. The RSC Payload, a compact representation of the server component tree, used by React to reconcile the two trees.
3. The JavaScript that hydrates the Client Components, that is, that attaches events to the HTML to make it interactive.

One rule weighs on the final size. According to the same page, when a file gets "use client", all of its imports and the components it renders directly are included in the client JavaScript bundle. The official recommendation is to mark only the interactive components, not large parts of the interface.

In the editorial team’s assessment, the two models have converged: both render on the server and isolate what is interactive. The difference lies in the starting point. In Astro, the default is no interactivity, and you add islands. In Next.js, the page is a React tree, and React itself and the router are part of the experience in the browser.

Navigating between pages

This difference shows up when you click a link.

In Next.js, after the first visit, the RSC Payload of the next pages is fetched in advance (prefetch) and cached, and Client Components are then rendered entirely in the browser, according to the components documentation. The result is app-like navigation that preserves state between screens.

In Astro, each link loads a new document. The transitions documentation shows two options. The browser’s native transitions only add animation and put no extra JavaScript on the page. The <ClientRouter /> component intercepts navigation and brings the site closer to an SPA, with state preserved between pages, but may require you to reinitialize scripts manually.

When content changes

Here is one of the most practical differences for anyone with many pages.

Astro, by default, generates everything at build time. Changed some text? Run a new build. For pages that need fresh data, you install a server adapter and mark the page with export const prerender = false. The rest of the site stays static.

Next.js offers more intermediate mechanisms. The main one is Incremental Static Regeneration (ISR). The ISR documentation lists what it allows: updating static content without rebuilding the whole site, serving prebuilt pages for most requests and handling large numbers of pages without long builds. You can generate only some pages at build time and create the others on the first visit, or invalidate a specific page when the content changes.

Since version 16, released in October 2025, Next.js has had Cache Components. With the "use cache" directive, you choose what gets cached. The caching documentation explains that the result is a “static shell” served from a CDN, with the dynamic parts arriving later, via streaming, inside <Suspense> blocks. This model is called Partial Prerendering (PPR).

The trade-off is complexity. The ISR documentation itself lists caveats: the feature only works in the Node.js runtime, does not work with static export, and, with multiple server instances, the default cache is separate per instance. The documentation also warns that background regeneration counts as extra processing on platforms that charge per request.

Hosting

A static Astro site is a folder of HTML, CSS and JavaScript files. It can be served by any web server. For on-demand rendering, there are adapters for environments such as Node.js, Netlify, Vercel and Cloudflare, according to the on-demand rendering documentation.

Next.js also runs in many places, but with different levels of feature support. The deploying page shows that a Node.js server and a Docker container support all features. Static export has limited support. Adapters vary: at the time of consultation, only Vercel’s and Bun’s were listed as verified, and Cloudflare and Netlify were working on their own versions.

The static exports documentation lists what stops working without a server, among other things: ISR, cookies, redirects and headers configured in the framework, Server Actions and image optimization with the default loader. In practice, Next.js delivers more when there is a server behind it.

What field data shows

To move beyond promises, the editorial team consulted the HTTP Archive technology report, an independent project that tracks the web. It measures the share of domains with good results on all three Core Web Vitals: loading speed of the largest element (LCP), visual stability (CLS) and responsiveness to interaction (INP), at the 75th percentile of page loads.

Data from August 2026, the most recent month available at the time of consultation:

Indicator	Astro	Next.js
Domains with all three metrics good, mobile	71.0%	35.1%
Domains with all three metrics good, desktop	83.6%	55.5%
Domains assessed on mobile	43,850	374,612
Median JavaScript on the page, mobile	~405 KB	~853 KB
Median total page weight, mobile	~1.40 MB	~2.24 MB

For reference, the average across all domains measured in the same month was 53.0% on mobile.

The difference is large and also appears in June and July 2026, in the same report. But it does not justify the conclusion that “switching from Next.js to Astro doubles the pass rate”. There are three reasons.

• Different sites. Next.js is widely used for applications, stores and dashboards, which have more interactivity and third-party scripts. Astro is concentrated in content sites. In the editorial team’s assessment, much of the difference comes from the type of site, not just the framework.
• Home page. According to the HTTP Archive FAQ, the crawl tests only the listed URL, usually the home page, which may not represent the whole site.
• Automatic detection. Technologies are identified by the Wappalyzer tool, which can lead to classification errors.

What about build speed? We did not find an independent, dated comparison between the two. The available figures come from each vendor. Astro published, in the version 7 announcement, builds 15% to 61% faster on real sites, measured on a MacBook Pro M4 Pro. Next.js stated, in the version 16 announcement, that the Turbopack bundler makes production builds two to five times faster than the previous one. Both measurements compare each framework with its own previous version, not with each other.

When Next.js is the better choice

• Applications with login and per-user data, such as dashboards, customer areas and SaaS, where almost every screen depends on who is accessing it.
• Interactivity across the whole interface, with a lot of state shared between screens and app-style navigation.
• Content that changes all the time across many pages, such as inventory and prices, where ISR and Cache Components avoid full rebuilds.
• A team already fluent in React and the Next.js ecosystem, with a Node.js server or a compatible platform available.

When Astro is the better choice

• Publications, blogs, documentation and catalogs in which most of the page is text, images and links.
• Thousands of pages that can be generated at build time, as explained in Astro: why use it for sites with thousands of pages.
• Simple hosting, where serving static files is cheaper and more predictable than maintaining a server.
• A mix of UI libraries, since Astro has official integrations for React, Vue, Svelte and others and lets you combine them on the same page.

Hybrid projects exist on both sides. Astro can render pages on demand, and Next.js can export a static site. The useful question is not which framework is “faster”, but which premise fits most of your project.

Takeaways

• Astro and Next.js render on the server, but Astro starts from zero JavaScript and adds islands, while Next.js starts from a React application with server and client components.
• Next.js has richer mechanisms for changing content (ISR, Cache Components), at the cost of more complexity and dependence on a server.
• HTTP Archive data from August 2026 favors Astro on Core Web Vitals and page weight, but it measures home pages of sites with different profiles and does not isolate the framework’s effect.
• Choose by type of project: publications and documentation favor Astro; interactive applications with per-user data favor Next.js.