Next.js 16.3 Turbopack build cache: cut CI build time up to 5.5x (2026)

Summary. Next.js 16.3 extends Turbopack's persistent file-system cache from next dev to next build, and on Vercel's own sites a warm cache cut Turbopack compile time from 30 seconds to 5.5 seconds, about 5.5x, with smaller 2.3x and 1.4x wins elsewhere (Next.js blog, 29 June 2026). Two experimental flags do the work: turbopackFileSystemCacheForBuild for build caching, and turbopackRustReactCompiler for a native React Compiler that trimmed 20-50% off compilation in early tests on large apps like v0. Memory eviction, on by default in 16.3, cut one dev server from 21.5 GB to 2 GB (roughly 90%). As of early August 2026, 16.3 is still a preview; the stable line is 16.2. This guide shows how to turn both on in CI, what to cache, and where they break.

Slow builds are a tax you pay on every pull request. GitHub reduced GitHub-hosted runner prices by up to 39% on 1 January 2026, but paid CI minutes past the free quota still add up, and when GitHub repriced Actions the small share of customers whose bills rose saw a median increase of about $13 a month (GitHub Changelog, 16 December 2025). For a team running hundreds of builds a day, shaving 10 to 60 seconds off every compile is the difference between a review that lands in minutes and one that stalls. Next.js 16.3 gives you two levers for that, plus a large dev-time memory cut. Here is what each one does, and how to adopt it without shipping a broken cache.

What changed in Next.js 16.3

Next.js 16.3 focuses Turbopack on compiler performance: less CPU and memory, faster builds, and a smaller runtime. The Turbopack team lists five headline changes: up to 90% lower dev-server memory, a persistent file-system cache for next build, experimental Rust React Compiler support, the Vite-compatible import.meta.glob API, and faster hot module replacement (HMR) and dev startup (Next.js blog).

Two points matter before you touch a config file. First, 16.3 is a preview as of early August 2026, published under the npm @preview tag while the stable line stays on 16.2 (Next.js release blog; Wikipedia: Next.js). Second, the build cache and the Rust compiler are behind experimental flags, so treat them as opt-in and reversible, not defaults you inherit on upgrade. If you are still moving an app onto the 16.x line, our Next.js 16 migration guide covers the async request APIs and Cache Components first; this piece assumes you are already there. The Next.js 16.3 instant-navigation features and the TypeScript 7 and Rust/Go toolchain changes shipped in the same release and cover different ground; this guide is only about build and dev performance.

The build-cache and memory numbers, in full

Persisting Turbopack's memory cache to disk has sped up next dev since the 16.1 release. After months of hardening on Vercel's own sites, the same persisted cache is now available for next build: when Turbopack sees the cache at the start of a build, it reads entries from disk before compiling any new changes. The published measurements, all from Vercel's own properties, are below.

Read the spread, not the headline. A content-heavy site with stable dependencies (vercel.com/geist) saw the biggest win because most of its work was already computed and cached. An app that changes more between builds (vercel.com/home) saw 1.4x. Vercel is explicit that there is no single reduction percentage for every application: results depend on the size of the route graph, how much of it changed, and how long the session ran (Next.js blog). Your first cached build is the one to measure.

Enable the persistent build cache

The build cache is off by default and lives behind one experimental flag in next.config.ts:

            // next.config.ts
const nextConfig = {
  experimental: {
    // Enable filesystem caching for `next build`
    turbopackFileSystemCacheForBuild: true,
  },
};

export default nextConfig;
          

With the flag on, a local rebuild reuses previously computed work automatically. The payoff in continuous integration comes from carrying that cache between runs. Vercel's guidance is direct: CI setups can take advantage of this by copying the generated .next directory from one run to the next. In practice that means caching the .next/cache directory, the long-standing Next.js CI caching target, so a fresh runner starts warm instead of cold.

Wire it into CI (GitHub Actions)

Here is a minimal GitHub Actions job that restores the Turbopack build cache before next build and saves it after. The cache key is scoped to the lockfile and source, so a dependency change starts a clean build instead of trusting stale output.

            # .github/workflows/build.yml
name: build
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - name: Restore Turbopack build cache
        uses: actions/cache@v4
        with:
          path: .next/cache
          key: turbo-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('src/**', 'app/**') }}
          restore-keys: |
            turbo-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}-
      - run: npm run build
          

Two engineering notes. Scope the key to the Next.js version and lockfile, because a persisted cache is not guaranteed portable across framework or Node.js versions; when either moves, you want a fresh build, not a mystery. And keep secrets out of anything the cache can capture: GitHub itself now ships a read-only Actions cache for untrusted triggers, a reminder that cache contents cross trust boundaries in CI (GitHub Changelog).

The Rust React Compiler

Next.js has had stable React Compiler support since the first 16.0 release, but until now the compiler ran only as a Babel transform. On larger applications that could slow builds while the compiler waited for JavaScript execution resources. The React team published a native Rust port of the compiler, and Vercel integrated it into Turbopack. Early tests against large React apps, including Vercel's v0, showed compilation wins of 20-50% (Next.js blog).

It is experimental, and you enable it in two parts: turn the compiler on, then switch it to the native Rust version.

            // next.config.ts
const nextConfig = {
  // enable the React Compiler
  reactCompiler: true,
  experimental: {
    // use the native Rust version instead of the Babel one
    turbopackRustReactCompiler: true,
  },
};

export default nextConfig;
          

The compiler has options for opt-in behaviour and per-file control; the official React Compiler config reference covers them. Because the Rust integration is new, run it in CI against your full test suite before you trust it on a release branch.

Memory eviction and the dev-time wins

The 90% memory figure is a dev-server number, not a build number, and it comes from a new ability to evict much of the in-memory cache. Turbopack leans on the file-system persistence first added in 16.1 to drop cached results from memory, which stops unbounded growth during long dev sessions. In 16.3 both the dev file-system cache and memory eviction are on by default; you can disable eviction while investigating cache behaviour:

            const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false, // default is 'full'
  },
};
          

Three smaller dev-time changes round out the release. Turbopack now supports the Vite-compatible import.meta.glob API for importing sets of files without hardcoding names, though it works only under Turbopack, not with the --webpack option. HMR subscription changes cut dev-server cold start by over 15% on complex apps. And Turbopack now ships WebAssembly, worker, and top-level-async runtime code only when a route needs it, trimming the per-route runtime size.

Should you turn these on now?

A short decision table for teams weighing the upgrade while 16.3 is still a preview.

The honest read: memory eviction is a free win you already get on upgrade. The build cache is worth piloting now, because the payoff is real and the downside (a stale cache) is contained by a good cache key. The Rust compiler is the one to gate behind tests, since it is both experimental and preview-stage. None of this is a reason to run a preview release in production; it is a reason to start measuring in CI so you are ready when 16.3 goes stable, and to fold build performance into the wider 2026 web platform baseline your team is already tracking.

India-specific considerations

For India-based teams and the global capability centres that run large front-end fleets, the build-cache win is a direct cost lever. CI compute is billed per minute once you pass the free quota, so a pipeline that runs hundreds of builds a day converts a 2x compile speedup into fewer runner-minutes and a smaller monthly bill in rupees. Two cautions specific to shared or offshore CI. Keep build artifacts and caches scoped so they never carry secrets or personal data across projects, in line with the Digital Personal Data Protection Act 2023 principle of limiting where such data flows. And standardise the Next.js and Node.js versions across your fleet, because a persisted cache that is portable in theory becomes a debugging cost when every team runs a different toolchain.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation whose senior engineering teams build and maintain production Next.js and React applications, and build performance is part of that work. When a CI pipeline has grown slow, we profile where the time goes, set up a version-scoped Turbopack cache, and pair it with the wider Core Web Vitals and web performance work that keeps the shipped app fast for users, not just for the build server. We are CMMI Level 5, MSME, and ISO 27001:2022 certified, so cache and secret handling in your pipeline is treated as a security concern, not an afterthought. To review your front-end build and delivery setup, contact eCorpIT.

References

1. Turbopack: What's New in Next.js 16.3 — Next.js blog, 29 June 2026

1. Next.js 16.3: Instant Navigations — Next.js blog

1. Next.js 16.3: AI Improvements — Next.js blog

1. React Compiler configuration reference — Next.js docs

1. Next.js release blog

1. Next.js — Wikipedia (version history)

1. Update to GitHub Actions pricing — GitHub Changelog, 16 December 2025

1. 2026 pricing changes for GitHub Actions — GitHub resources

1. Read-only Actions cache for untrusted triggers — GitHub Changelog, 26 June 2026

1. Actions steps can now be run in parallel — GitHub Changelog, 25 June 2026

_Last updated: 2 August 2026._