Next.js 16.3 vs Astro 7 vs Nuxt 4.5 on the same blog design, 172KB vs 0KB JS

Vercel released Next.js 16.3 on August 3, 2026.
They call it the biggest update since 16.0, with dev-server memory reduction and a build cache as the headline items.

The other major frameworks all shipped new versions this summer.
Astro 7.0 landed on June 22 with Vite 8 and a Rust compiler, followed by 7.1 on July 16.
Nuxt 4.5.0 came out on July 18.
I covered Vite 8 separately → Vite 8.0 speeds up builds by up to 30x with Rolldown

With all three at a version milestone, I built the same blog design once in each framework and measured them under the same conditions on my M4 Mac mini.
The three sites came out looking identical. The numbers behind them, from build speed to the amount of JavaScript reaching the browser, differed by orders of magnitude.

What’s new in Next.js 16.3

Here are the changes from the official announcement that apply to existing apps just by upgrading.

Change	Official numbers
Less dev memory (disk cache + memory eviction on by default)	Up to 90% less. 21.5GB to 2GB on the vercel.com dashboard
Filesystem cache now on by default for next build	5.5x on CI for some projects; nextjs.org went 21s to 9.2s
App Router SSR switched from Web Streams to native Node.js streams	Up to 22% more requests under load
Experimental TypeScript 7 type checking (requires experimental.useTypeScriptCli: true)	Follows Microsoft’s release of TS7 as a native port, up to 10x faster
next dev auto-generates AGENTS.md when it detects an AI agent environment	Points agents at version-matched docs

The opt-in features are grouped under the name Instant Navigations.
Setting the cacheComponents and partialPrefetching flags in next.config.ts prefetches loading shells for linked pages, making navigation feel like an SPA.
It ships with Instant Insights, which automatically flags slow navigations, a Navigation Inspector for viewing loading states, and an instant() Playwright helper for testing that navigations stay instant.
ISR (Incremental Static Regeneration) also improved: a URL skipped at build time now serves an instant loading shell to its first visitor while the full page renders in the background.

On the experimental side there is a Rust-based React Compiler.
It runs inside Turbopack (Next.js’s Rust bundler) instead of going through Babel, and on a large app like v0 the time from next dev to a ready page dropped 34% cold and 46% warm, according to Vercel.

Test setup

The environment:

Item	Value
Machine	M4 Mac mini (16GB RAM)
Runtime	Node.js 25.3.0 / pnpm 10.27.0
Next.js	16.3.0 (released August 3)
Astro	7.1.6
Nuxt	4.5.1

The site is a small blog: a header, a top page listing posts, three posts, and a footer.
No templates or UI libraries. I hand-wrote the same HTML structure in all three, and the CSS file and the posts JSON are byte-identical copies shared across the implementations.
The implementations came out at 76 lines for Next.js, 74 for Astro, and 71 for Nuxt, excluding the shared CSS and JSON.
Source code and the measurement scripts are on GitHub → LiltingChannelLabo

I served each production build locally and took screenshots with headless Chrome under the same conditions. The three PNGs came out byte-for-byte identical, with matching MD5 hashes.
A single differing pixel would change the PNG bytes, so all three implementations render exactly the same page. That settles the premise of comparing sites with the same design.

Build times

I measured a cold build after deleting cache directories, a warm rebuild with no changes, and a rebuild after a one-line source change.

	Cold	Warm (no changes)	One-line change
Next.js	3.3–5.3s	2.0s	2.9s
Astro	0.6–2.3s	0.5–0.6s	0.8s
Nuxt	2.7–4.9s	2.4s	3.4s

The cold range is wide because only the very first run is slow. All three added a one-time setup cost on their first build.
With the build cache that became the default in 16.3, Next.js went from 3.3s cold to 2.0s warm and 2.9s after a one-line change.
At this project size the saving stayed around one second. The official 5.5x figure comes from CI repeatedly rebuilding projects whose builds take tens of seconds.
Astro’s compile itself finishes in 142ms, and the cache made almost no difference.

Dev server

I measured time from startup to the first HTTP 200, the first hit on each post page, and memory usage (RSS) after warm-up.

	First 200	Post page, first hit	Later hits	RSS
Next.js	1.4–1.5s	244ms	11–15ms	513–615MB (4 processes)
Astro	1.6s	8ms	2–3ms	288MB (1 process)
Nuxt	2.9s	8ms	3–4ms	593–607MB (5 processes)

Next.js compiles pages lazily, so the first hit on an unvisited page takes 244ms.
Memory tracked process architecture. Astro runs a single process at 288MB; Next.js and Nuxt split work across workers and land in the 500–600MB range.
The official up-to-90% reduction was measured in dev sessions that compiled many routes, with the disk cache and memory eviction active. My 6-page project never had enough routes to evict, so I could not observe that reduction.

One more thing: running next dev created an AGENTS.md at my project root.
It writes the file when it detects an AI coding agent environment, and agentRules: false in the config turns it off.
The file opens with the heading “This is NOT the Next.js you know” (from the generated AGENTS.md) and tells agents to read the bundled docs in node_modules because the APIs are newer than their training data.
It even tells you to commit it, since next dev regenerates it if you delete it.
Vercel simultaneously retired its old Skills, which existed only to deliver current docs, in favor of this mechanism.

Page weight

I served each production build locally, fetched the top page with gzip enabled, and summed the transfer size of the HTML and every referenced asset.

	HTML	External JS (gzipped)	JS files
Next.js	7.9KB	564KB (172KB)	6
Nuxt	2.9KB	58KB (21.5KB)	1
Astro	2.9KB	0	0

This site has no interactive elements at all.
Next.js still ships 6 files totaling 172KB gzipped, including the React runtime and the router. Even with every page statically generated (SSG), the client-side navigation machinery always comes along.
The HTML is large at 7.9KB because the React Server Components reconstruction data is inlined into it.
Nuxt ships 21.5KB including the Vue runtime. Astro drops not just external JS but the CSS request too: this CSS is only 1.6KB, so Astro inlined it into <head> and the page became a single HTML request.

Install and output sizes:

	node_modules	Packages	Build output
Next.js	317MB	24	.next 18MB (served by next start)
Astro	137MB	197	dist 16KB (4 HTML files, ready for any static host)
Nuxt	185MB	564	.output 2.4MB (bundled Nitro server)

Next.js has the fewest packages at 24 yet the largest install, because it bundles native SWC and Turbopack binaries.
The outputs are different in kind: Astro emits static files, Nuxt a complete Node.js server, and Next.js a build artifact tied to its own runtime.

lilting.ch runs on Astro, and nothing in these measurements gave me a reason to consider switching.
Next.js 16.3’s improvements target a much larger scale than this sample: the official memory figures were taken after compiling 50 routes, and the Rust React Compiler numbers come from v0.
I also covered Cloudflare’s reimplementation of Next.js on Vite → Cloudflare used AI to reimplement Next.js on Vite in a week, and vinext is already in production