Next.js 16.2 brings 67-100% faster server Fast Refresh

Next.js 16.2 Turbopack brings Server Fast Refresh to Node.js, cutting reload times 67-100% and compile times 400-900%. Only changed modules reload, not whole chains. WASM Workers, SRI, and dynamic import tree shaking land; upgrade to cut dev latency.
WHY IT MATTERS: Development speed directly shapes shipping velocity. When server-side hot reloads blast away the entire require cache including untouched node_modules, engineers wait dozens or hundreds of milliseconds for every small change. Next.js 16.2 eliminates that waste by bringing browser-style Fast Refresh to Node.js server code through Turbopack. In production-grade applications, server reload times drop 67-100% and compile times fall 400-900%, scaling from small starters to large sites like vercel.com. For teams running substantial Next.js codebases, this removes a daily friction point that compounds across every edit and test cycle.
WHAT CHANGED: Turbopack now uses its internal module graph to surgically reload only the module that changed, leaving the rest of the server process intact. This replaces the previous behavior of clearing require.cache for the changed file and every module in its import chain. The release also corrects Web Worker origins so they point to the application domain instead of an empty blob URL, unblocking WASM libraries that rely on relative fetch or importScripts inside Workers. Subresource Integrity is now supported as an experimental alternative to nonce-based CSP, computing script hashes at build time so pages can remain static while enforcing execution policies. Dynamic imports are now tree-shaken the same way static imports are, so unused exports inside dynamically imported modules are removed from the bundle. Developers can also configure loaders per-import using import attributes rather than global turbopack.rules, and experimental Lightning CSS configuration options are available alongside postcss.config.ts support and log filtering.
WHAT TO WATCH: Proxy and Route Handlers still use the legacy reload system, with Fast Refresh support planned for a future release. The team is also targeting faster compiler performance and lower memory usage in upcoming versions. If you rely on Workers for heavy compute or WASM, verify your libraries now work without origin workarounds. Turn on experimental SRI if you currently use nonces and want to move pages back to static generation. With over two hundred bug fixes and performance changes in this release, upgrading should be low risk and immediately improve local iteration speed.
Source: Next.js Blog
Read the original → Next.js Blog
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.