NextjsLogotypeNextjsLogotype

Turbopack: What's New in Next.js 16.2

Tim Neutkens, Andrew Imm

Two releases after Turbopack became the default bundler for Next.js, we're focused on improving performance, fixing bugs, and increasing parity. Here are some of the latest features shipping as part of Next.js 16.2.

Looking forward towards our next release, we'll be focused on speeding up compiler performance and reducing memory usage.

Copy link to headingServer Fast Refresh

We've reworked how server-side code is reloaded during development. The previous system cleared the require.cache for the changed module and all other modules in its import chain. This approach often reloaded more code than necessary, including unchanged node_modules.

The new system brings the same Fast Refresh approach used in the browser to your server code. Turbopack's knowledge of the module graph means only the module that actually changed is reloaded, leaving the rest intact. This makes server-side hot reloading significantly more efficient.

In real-world Next.js applications, we've seen 67-100% faster application refresh and 400-900% faster compile time inside Next.js. These results scale from the smallest "hello world" starter project to large sites like vercel.com.

Server refresh time on a sample Next.js site

375% faster

Before

59ms

After

12.4ms

Next.js (40ms → 2.7ms)

Application (19ms → 9.7ms)

Today we're enabling this feature for all developers, by default. Proxy and Route Handlers will use the existing system today, but support for those is arriving in a future release. Share your feedback or any issues with this new feature on GitHub.

Copy link to headingWeb Worker Origin

Previously, Web Workers were bootstrapped through a blob:// URL. This streamlined loading the worker, but it set an empty location.origin value. Web Worker code that tried to use importScripts() or fetch() (usually in third-party libraries) would have been unable to resolve the request without changes.

With the updated Worker bootstrap code, the origin correctly points to your domain name, and relative fetches succeed. This should unblock anyone who had trouble running WASM code inside a Worker in previous versions.

Copy link to headingSubresource Integrity Support

Turbopack now supports Subresource Integrity (SRI). SRI generates cryptographic hashes of your JavaScript files at build time, allowing browsers to verify that files haven't been modified.

Browsers provide a technology called Content Security Policy that allows sites to restrict the JavaScript that can run, eliminating entire classes of security issues. However, the typical nonce-based method for implementing this requires all pages to be dynamically rendered, impacting performance. Subresource Integrity is an alternative that computes a hash of each script ahead of time, and only allows the browser to execute scripts with approved hashes.

next.config.js
const nextConfig = {
  experimental: {
    sri: {
      algorithm: 'sha256',
    },
  },
};
 
module.exports = nextConfig;

Copy link to headingTree Shaking of Dynamic Imports

Turbopack now tree shakes destructured dynamic imports the same way it does static imports. Unused exports are removed from the bundle:

const { cat } = await import('./lib');

This is now equivalent to a static import for tree shaking purposes — any exports from ./lib that aren't used will be tree-shaken.

Copy link to headingInline Loader Configuration

Turbopack now supports per-import loader configuration via import attributes. Instead of applying loaders globally through turbopack.rules, you can configure them on individual imports using the with clause:

import rawText from './data.txt' with {
  turbopackLoader: 'raw-loader',
  turbopackAs: '*.js',
};
import value from './data.js' with {
  turbopackLoader: 'string-replace-loader',
  turbopackLoaderOptions: '{"search":"PLACEHOLDER","replace":"replaced value"}',
};

This is useful when only a specific import needs special treatment, avoiding side effects on other imports of the same file type. The available attributes are turbopackLoader, turbopackLoaderOptions, turbopackAs, and turbopackModuleType.

You should still prefer configuring your loaders in next.config.ts when possible, since code using inline loaders is less portable. This option is more useful for code generated from plugins or loaders.

Copy link to headingLightning CSS Configuration

Lightning CSS is a fast, Rust-based CSS transformer used by Turbopack for CSS minification and prefixing. It also allows implementation of modern CSS features on older browsers, similar to what Babel or SWC do for JavaScript. Previously, the only way to toggle these settings was through a Browserslist configuration. Now with the experimental lightningCssFeatures option, you can force certain features to always or never transpile.

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  experimental: {
    useLightningcss: true,
    lightningCssFeatures: {
      include: ['light-dark', 'oklab-colors'],
      exclude: ['nesting'],
    },
  },
};
 
export default nextConfig;

Copy link to headingLog Filtering

Turbopack can now suppress noisy or expected warnings from streaming logs with the turbopack.ignoreIssue config option. This is useful for suppressing warnings from third-party code, generated files, or optional dependencies, as well as hiding expected errors from the Next.js error overlay.

You can match logs generated from specific code paths, as well as filter for specific title/description strings or patterns.

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  turbopack: {
    ignoreIssue: [
      { path: '**/vendor/**' },
      { path: 'app/**', title: 'Module not found' },
      { path: /generated\/.*\.ts/, description: /expected error/i },
    ],
  },
};
 
export default nextConfig;

Copy link to headingpostcss.config.ts Support

Turbopack now supports postcss.config.ts in addition to the existing .js and .cjs variants.

Copy link to headingPerformance Improvements and Bug Fixes

We've continued to invest in improving Turbopack internals. Over 200 changes and bug fixes have improved stability and compatibility across a wide range of projects. Optimizations in data encoding, internal representation formats, and hashing algorithms have improved memory usage and build time. We've made error logs clearer and expanded diagnostics to help you better understand compiler errors. We've also used your GitHub Issues as a guide for which features were missing since the 16.1 release.

Copy link to headingFeedback and Community

Share your feedback and help shape the future of Next.js: