JavaScriptDeveloper ToolsPerformanceDeveloper Experience

Next.js 16.3: Turbopack Cuts Dev Memory 90%, Builds 5x Faster

Next.js 16.3 Turbopack showing 90% memory reduction and persistent build cache performance improvements
Next.js 16.3 ships Turbopack memory eviction and persistent build cache

A 21 GB dev server is not a developer experience problem — it is a crisis. That was the reality for Vercel’s own dashboard app running Turbopack before this release. Next.js 16.3 fixes it with in-memory cache eviction, drops dev RAM by up to 90%, and ships a persistent disk cache that makes next build up to 5.5x faster on cached runs. The experimental Rust-native React Compiler arrives as well. This is the most significant Turbopack performance release since it went stable.

90% Less Memory in Dev Mode

Turbopack’s incremental compilation model works by caching every previously compiled module in memory. That means fast recompilation — but unchecked memory growth over a long dev session. On a large app like Vercel’s internal dashboard, that ballooned to 21.5 GB after compiling 50 routes. Most developer machines do not have 21 GB to spare, especially with AI coding agents, LSP servers, and Docker containers all competing for the same heap.

In 16.3, Turbopack can evict cached entries from memory to the filesystem — the same persistence layer introduced in 16.1 for next dev. The result on Vercel’s dashboard app: 21.5 GB drops to 2 GB. The nextjs.org site falls from 4,600 MB to 840 MB. Memory eviction is on by default. You do not need to change anything to get the benefit. To disable it for debugging, set experimental.turbopackMemoryEviction: false in your config.

The 90% figure comes from Vercel’s own flagship app — a favorable benchmark. Smaller apps will see less dramatic numbers, and results depend on route graph size, session length, and how many routes were compiled. Still, any project with more than a handful of routes should see a meaningful reduction.

Persistent Build Cache for next build

Filesystem caching for next dev shipped in Next.js 16.1. It took two more releases to harden the same feature for production builds. In 16.3, next build now reads from a persistent disk cache stored in .next/cache, skipping recompilation of files that have not changed. The benchmark numbers: vercel.com’s design system goes from 30 seconds cold to 5.5 seconds cached (5.5x faster). nextjs.org goes from 21 seconds to 9.2 seconds (2.3x). A larger production site sees a more modest 1.4x improvement.

There is a CI caveat worth calling out: you only get faster builds if you restore the .next/cache directory between CI runs. If your pipeline starts fresh every time, the cache does nothing for you there. Setting up cache restoration in GitHub Actions or your CI of choice is now worth the effort — this is the same pattern that Nx and Turborepo have offered externally for years, now built into Next.js itself.

Experimental Rust React Compiler

The React Compiler has been stable in Next.js since 16.0, but it ran as a Babel transform. On large applications, Babel became the bottleneck — JavaScript executing JavaScript transformations is inherently slow at scale. The React team published a native Rust port of the compiler, and Vercel integrated it into Turbopack. Early tests against large apps like v0.app showed 20 to 50% compilation speedups.

It ships as an experimental feature. To try it, enable both the compiler and the Rust flag in your config:

// next.config.ts
const nextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

The 20-50% range is wide, but even the low end is meaningful for teams building large codebases where compilation time adds up throughout the day. Test it on a staging branch first — it is experimental for a reason.

Vite-Compatible import.meta.glob

Turbopack now supports the import.meta.glob API familiar to Vite users. It imports all modules matching a file pattern without hardcoding paths:

const posts = import.meta.glob('./posts/*.mdx');

for (const path in posts) {
  const post = await posts[path]();
}

The implementation hooks into Turbopack’s file watcher — add or remove a matching file and recompilation triggers automatically. Useful for MDX-based blogs, product catalogs, or any feature that loads a dynamic set of similar files. One limitation: this only works in Turbopack mode. The --webpack option does not support it. See the full import.meta.glob documentation for options including named imports, negative patterns, and TypeScript type generation.

HMR and Runtime Size Improvements

Two smaller wins round out the release. Hot module replacement cold start is over 15% faster on complex apps, achieved by collapsing multiple chunk tracking subscriptions into a single one. The Turbopack runtime also now excludes WebAssembly, worker, and top-level async module code from the runtime bundle for apps that do not use those features — reducing the payload shipped to every route at no configuration cost. Safari CSS HMR bugs were fixed as well.

How to Upgrade

If you are on Next.js 16.x, upgrading to 16.3 is a standard package update:

npm install next@latest react@latest react-dom@latest

Memory eviction and persistent build cache are on by default — no code changes needed. The Rust React Compiler and import.meta.glob require explicit opt-in. Instant Navigations and Cache Components, covered in a separate Vercel blog post, also remain behind flags for now.

Upgrading from Next.js 15 or earlier? The version 16 upgrade guide covers the major breaking changes: async request APIs replacing synchronous ones, Babel removal in favor of SWC, and Turbopack as the default bundler. Budget more time than you expect for that migration — custom Webpack configurations in particular need to be re-evaluated.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:JavaScript