概要
公開日: 2026-06-29
翻訳生成に失敗したため、原文をそのまま保存しています。
原文
Back to Blog Monday, June 29th 2026 Turbopack: What's New in Next.js 16.3 Posted by Andrew Imm @ setimmediate Next.js 16.3 Preview is ready for public testing! We've published a new Next.js release to npm using the @preview tag, so you can try out 16.3 today. We expect to ship a polished stable release in the coming weeks. We'd love to hear any feedback you have about the preview on GitHub . As the Next.js 16.3 Preview nears a stable release, we're sharing a series of posts about what's inside. Our previous posts cover new Instant Navigation features and the latest AI improvements . This third post details the latest improvements to the Turbopack bundler within Next.js. With Next.js 16.3 , Turbopack's latest stable release focuses on compiler performance. Many of the newest features are centered around reducing CPU and Memory usage, speeding up build times, and improving runtime experience. Reducing dev server memory usage by up to 90% Persistent file system cache for faster builds Experimental Rust React Compiler support import.meta.glob API support Faster HMR and dev startup Reducing memory usage in dev mode Turbopack's core design is focused on incremental compilation. By caching the work it previously did, it avoids recompiling files that haven't changed. When developing large Next.js applications, this means compile time is proportional to the size of your changes, not the size of your route. In pursuing this design, we made a very deliberate trade-off: caching more results in memory, for reduced CPU usage. Since Turbopack first launched, though, memory usage has been at a premium. Coding agents, IDEs, typecheckers, and linters all run at dev time, and each consumes a significant chunk of system memory. Over the last three months, the Turbopack team has been committed to reducing its contribution to system memory pressure. With an upgrade to 16.3, developers should immediately see less memory usage for long-running dev sessions. Memory usage after compiling 50 routes vercel.com (dashboard) ~90% smaller Before 21.5 GB 21.5 GB After 2 GB 2 GB nextjs.org ~82% smaller Before 4,600 MB 4,600 MB After 840 MB 840 MB Much of this was achieved through small incremental wins: compressing data structures and avoiding storing data longer than was necessary. The biggest win, though, comes from a new ability to evict much of the in-memory cache. Leveraging the file-system persistence feature that was first introduced in Next.js 16.1 , Turbopack is able to remove cached results from memory. This avoids unbounded growth of memory in dev sessions, since the memory cache no longer holds onto every visited route. Memory eviction requires the development filesystem cache to be enabled. In 16.3, both of these options are on by default. It can be disabled when investigating cache or development performance with the experimental turbopackMemoryEviction config value : const nextConfig = { experimental : { turbopackMemoryEviction : false , // disables memory eviction, default value is 'full' } , }; There is no single reduction percentage that applies to every application. Individual results depend on the size of the route graph, how much of it was touched during the development session, and how long the session was running. File System cache for builds Persisting the Turbopack memory cache to disk has been speeding up next dev sessions since the 16.1 release . After months of hardening in production with Vercel's own sites, the same persisted cache is now available for next build . Turbopack compile time for next build nextjs.org ~2.3× faster Cold 21s 21s Cached 9.2s 9.2s vercel.com/home ~1.4× faster Cold 66s 66s Cached 46s 46s vercel.com/geist ~5.5× faster Cold 30s 30s Cached 5.5s 5.5s With persistent disk cache, builds can take advantage of previously computed work and reduce the time it takes to compile your static assets. CI setups can take advantage of this by copying the generated .next