Vercel says Turbopack's new cache makes builds 5.5x faster. The real number for most sites is 2.3x
Next.js 16.3 shipped on June 29, 2026, and turned on Turbopack's persistent file system cache for next build by default. Vercel's own launch post has three benchmark numbers for that cache, and the one making the rounds on social media is 5.5x faster builds. That number is real. It's also the best case on one specific route, and most solo projects will land closer to 2.3x, if their CI is even set up to see the cache at all.
What Vercel's own numbers actually say
The Next.js blog post ("Turbopack: What's New in Next.js 16.3," published by Andrew Imm) ran the cache against three real properties and printed cold versus cached build times for each. nextjs.org went from 21 seconds to 9.2 seconds, about 2.3x faster. The vercel.com homepage went from 66 seconds to 46 seconds, about 1.4x faster. And vercel.com/geist, a single design-system route, went from 30 seconds to 5.5 seconds, the 5.5x figure everyone is quoting.
Three numbers on one page, and the spread between them is the whole story. A 1.4x result and a 5.5x result sitting on the same chart tell you the win depends heavily on what you're building: how much of the route graph actually changes between builds, how much of it is cacheable module compilation versus something Turbopack can't shortcut. Geist is a component-heavy, low-churn route, which is exactly the shape that benefits most from "skip recompiling what didn't change." A big, frequently-touched homepage benefits less. Quoting 5.5x as the number for "Turbopack's new cache" the way most of the coverage did is technically true and practically misleading, which is a pattern I see constantly in framework benchmark marketing.
Where the speedup actually lives, and why your CI might never see it
Here's the part that got buried under the headline number: the cache is a directory on disk. Specifically .next/cache. Turbopack checks it at the start of a build and reads whatever entries are there before compiling anything new. That's a completely different mechanism from a benchmark run locally with a warm cache already sitting on the machine.
CI runners are ephemeral. Every job typically starts from a clean checkout with no .next/cache from the previous run, unless something explicitly saves and restores it. GitHub's own docs for Next.js state the obvious consequence directly: the cache lives in .next/cache, so CI builds only get faster if that directory is restored between runs. A stock actions/checkout plus npm run build in GitHub Actions, which is what most solo projects have, gets a cold cache every single time. You'd upgrade to 16.3, see zero build-time change in CI, and reasonably conclude the whole feature was hype, when actually you just never gave it a chance to do anything.
The two-line check (well, closer to eight lines)
If you're running Next.js in CI and want the cache to matter, you need an explicit restore step. The shape of it, using actions/cache, looks like this:
- name: Restore Next.js build cache
uses: actions/cache@v4
with:
path: .next/cache
key: nextjs-cache-${{ hashFiles('package-lock.json') }}-${{ github.sha }}
restore-keys: |
nextjs-cache-${{ hashFiles('package-lock.json') }}-
The restore-keys fallback matters more than the exact key: you want a partial match against the last successful build even when the current commit's exact cache doesn't exist yet. Vercel's own deployment pipeline does this automatically behind the scenes, which is a real advantage of building on Vercel specifically versus rolling your own CI. If you deploy elsewhere, whether that's a GitHub Action, a Dockerfile, or a cron job on a VPS, that restore step is on you to add, and it's easy to skip because nothing breaks if you don't. Your build just quietly stays slow.
Why this doesn't touch my stack at all
solooperatorstack.com runs on Astro, not Next.js, with close to 500 posts built as a fully static site and deployed by a cron job pulling from git on a Hetzner box. Astro's build model doesn't have this problem or this opportunity: there's no persistent Turbopack cache to configure because there's no Turbopack, and my "CI" is a shell script that runs astro build into a staging directory and swaps it in only if the build succeeds. That setup already has its own version of the caching question (mine is "did the last good dist/ stay untouched," not "did the module cache survive"), and it's answered by a completely different and, for a single-writer static blog, much simpler mechanism.
That's worth saying plainly because the instinct when you read "5.5x faster builds" is to wonder if you're leaving performance on the table by not using whatever shipped the number. For a 500-post static Markdoc site with one author, you're not. Turbopack's persistent cache solves a problem that mostly shows up at a different scale: teams shipping many PRs a day against a large monorepo, where every merge previously paid the full cold-compile cost. That's a real problem and a legitimate win for the people who have it. It's not a reason for a solo builder on Astro, Eleventy, or plain static HTML to feel behind.
Where I could be wrong
The "just check your CI cache config" framing assumes the cache is safe to restore across different builds, and that's not settled. A GitHub discussion opened against the vercel/next.js repo (Turbopack File System Caching feedback, #87283) raised exactly this: whether restoring a .next/cache produced by a different commit is a supported, correctness-guaranteed scenario, or whether Turbopack only guarantees correctness when reusing a cache in place on the same machine that wrote it. At least one report in that thread found that disabling turbopackFileSystemCacheForBuild was necessary to get deterministic output again. If that turns out to be a real limitation rather than an edge case, "restore the cache in CI" stops being a safe two-line fix and becomes a "test this carefully before you trust your production build output" exercise, which is a much bigger ask for a solo project than adding a YAML block.
And if you are running Next.js at real scale, meaning a monorepo with dozens of engineers, dozens of PRs a day, and cold-compile time that's actually showing up as a bottleneck in your deploy pipeline, this is a legitimate reason to invest real effort in getting cache restoration right, possibly including migrating CI providers to one with better native support for it. That's a different conversation than "should I read this as applying to my two-person SaaS build."
What I'd actually do
If you run Next.js in CI, spend fifteen minutes today confirming whether your pipeline restores .next/cache between runs. If it doesn't, add the restore step, watch your next few build times, and treat 2.3x as your realistic expectation rather than 5.5x. If you're on Vercel's own deployment pipeline, you likely already have this for free and don't need to do anything. And if, like me, you're not running Next.js at all, the headline number is interesting industry news, not a prompt to reconsider your stack. A 5.5x build speedup on someone else's design-system route isn't a reason to rewrite an Astro blog with 500 posts in it.
Author
Lukas
@lukcombinator