Turbopack compile time for `next build`
vercel.com/home
~1.4× faster
vercel.com/geist
~5.5× faster
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` directory from one run to the next. When Turbopack sees the cache at the start of a build, it reads entries from disk before compiling any new changes.
Persistent cache for builds can be enabled with the [`turbopackFileSystemCacheForBuild` config flag](/docs/app/api-reference/config/next-config-js/turbopackFileSystemCache).
```ts
const nextConfig = {
experimental: {
// Enable filesystem caching for `next build`
turbopackFileSystemCacheForBuild: true,
}
}
```
## Experimental Rust React compiler
Next.js has provided stable support for the React Compiler [since the first 16.0 release](/blog/next-16#react-compiler-support-stable). Until now, the React Compiler has only been available as a Babel transform. On larger applications, we observed that it could slow down builds while waiting for JS execution resources. Recently, the React team published a native Rust port of the compiler, which we were quick to integrate into Turbopack.
Promising early tests against large React apps like [v0](https://v0.app) showed compilation wins of 20-50%, so we are releasing the native compiler integration as an experimental feature to drive more adoption.
To test out the Rust React Compiler, enable the compiler and use the experimental `turbopackRustReactCompiler` flag to use the native version:
```ts
const nextConfig = {
// enable the compiler
reactCompiler: true,
experimental: {
// use the Rust version, instead of the OG Babel one
turbopackRustReactCompiler: true,
}
}
```
There are many ways to configure the React Compiler for features like opt-in functionality. You can [read the full documentation](/docs/app/api-reference/config/next-config-js/reactCompiler) for more details.
## `import.meta.glob`
Turbopack now supports the Vite-compatible `import.meta.glob` API:
```ts
const posts = import.meta.glob('./posts/*.mdx');
```
This API can import all modules that match this pattern, without hardcoding their names. The result is an object keyed by the matching file paths. By default, each value is an async function that loads the module:
```ts
for (const path in posts) {
const post = await posts[path]();
}
```
Use `eager: true` to `import` each match immediately:
```ts
const posts = import.meta.glob('./posts/*.mdx', {
eager: true,
})
```
The implementation also supports named imports, multiple patterns, negative patterns, custom search path, query strings for loaders, and generated TypeScript types.
This functionality is powered by Turbopack's file watcher. When a file is added to or removed from this match set, it will trigger recompilation in dev mode, so your site always reflects the latest changes. This API is perfect for fetching sets of similar documents, like product descriptions or blog posts. We also expect that library developers will benefit from this API existing across the broader JS ecosystem.
`import.meta.glob` is available as a Turbopack feature, and will not work for Next.js apps built with the `--webpack` option.
See the [`import.meta.glob` reference](/docs/app/api-reference/turbopack#importmetaglob) for all of the available options.
## HMR improvements
By analyzing the performance of Turbopack in large Next.js apps at Vercel, we identified a number of performance improvements that could benefit all Turbopack users. Much of that investigation centered around making HMR subscriptions more efficient. One significant change streamlined the tracking of chunks that are loaded on a page. By reducing multiple subscriptions to a single one, we were able to reduce dev server cold start by over 15% on complex apps.
This is only the beginning of our HMR resource investigations, and we expect to deliver more memory and cold-start improvements in future Next.js releases.
## Smaller runtime size
Turbopack ships runtime code to every route that allows it to resolve modules and dynamically fetch new chunks. This also includes code for loading WebAssembly, workers, and top-level async modules. Not every Next.js application uses that functionality, though. Now Turbopack will only ship those features when they're needed, and avoids shipping extra runtime code the rest of the time.
## Local PostCSS configuration
Monorepos may need different PostCSS transforms for different packages.
The experimental `turbopackLocalPostcssConfig` option lets Turbopack resolve the configuration closest to each CSS file before falling back to the project root:
```ts filename="next.config.ts"
const nextConfig = {
experimental: {
turbopackLocalPostcssConfig: true,
},
};
```
This allows package-level CSS to use a local configuration while application CSS continues to use the root configuration.
## Compatibility and reliability
Next.js 16.3 rolls up all of the fixes from the 16.2 patch line and adds more improvements across module resolution, tracing, and HMR, including:
- Correct file URLs for `import.meta.url` on Windows
- Retry chunk fetching on failure
- Better support for `createRequire(new URL(..., import.meta.url))`
- Correct `worker_threads` URL resolution
- Support for the `module-sync` export condition
- Better errors when webpack loaders crash
- CSS HMR fixes in Safari