Next.js 16.3 Preview cuts Turbopack memory up to 90% and warms builds 5.5x

• Next.js 16.3 Preview centers on Turbopack, with Next.js's preview overview listing up to 90% less dev-memory use, up to 5.5x faster warm builds, an experimental Rust React Compiler path, and import.meta.glob support.
• According to Next.js's memory explainer, the memory drop comes from file-system persistence, which lets Turbopack evict more of its in-memory cache during long dev sessions.
• Next.js's filesystem-cache post says the cache now applies to next build, not just next dev, and warm builds ran up to 5.5x faster when CI reused the .next directory.
• Next.js's React Compiler post says the Rust port removed the old Node.js worker and re-parse overhead, speeding route compilation by 20% to 50% in internal tests on apps like v0.
• In Guillermo Rauch's reaction, Vercel framed the update around agent-heavy workflows, where build tools, IDEs, linters, and coding agents all compete for the same RAM budget.

Next.js's preview overview links the whole package together, while its memory explainer includes a screenshot showing Vercel.com dropping from 21.5 GB to 2 GB after compiling 50 routes. The filesystem-cache thread shifts the story from dev-only wins to CI and warm-build reuse, and the React Compiler note adds a separate speed path that comes from moving compiler work out of a Babel transform.

The biggest practical change is not a new compiler trick. It is Turbopack keeping more cache state on disk so it can keep less in RAM.

According to the Next.js thread, that matters during long sessions because coding agents, IDEs, typecheckers, and linters all sit alongside the dev server. The attached chart shows route compilation memory falling from 21.5 GB to 2 GB on Vercel.com, and from 4.6 GB to 840 MB on a Next.js app.

Next.js had already shipped filesystem cache support for next dev in 16.1. The 16.3 cache update extends that same mechanism to next build.

The workflow detail is unusually concrete: CI can share the .next directory across runs, then Turbopack reads prior cache entries from disk. Next.js's post says warm builds were up to 5.5x faster on that cached path.

The React Compiler win is separate from the filesystem cache story. Next.js's compiler note says the old setup ran as a Babel transform, which forced Turbopack to spin up a Node.js worker and re-parse every file.

The new Rust port drops that overhead. When enabled, the same post says route compilation ran 20% to 50% faster in tests on apps like v0.

One more 16.3 item sits in Next.js's preview overview without much fanfare: import.meta.glob support.

That puts a Vite-style module glob primitive next to the bigger Turbopack performance work in the same preview. The overview tweet does not add implementation detail, but it is the only feature in the list that changes the module authoring surface rather than the build pipeline.