Keep Turbopack compile cache across production builds

[marcklingen]

Enable Next 16.2's Turbopack filesystem cache for production builds and stop deleting .next/cache after next build.

This is the only change from a local experiment pass that had a measured compile saving and no SSG/SEO risk.

Why

Vercel Enhanced (8 cores / 16 GB) spends most of pnpm run build here:

Phase	Vercel today
Turbopack compile	61s
TypeScript	16.5s
SSG (985 pages, 7 workers)	17.3s
prebuild	~5.5s
Gap after llms-txt	~31s (artifact upload of a 1.1 GB .next, not the script)

postbuild:cleanup (rm -rf .next/cache) was a Nov 2024 Nextra workaround. Next already keeps .next/cache when it cleans the dist dir. Without experimental.turbopackFileSystemCacheForBuild, that directory is only ~1.6 MB of fetch-cache, so deleting it does nothing for the 61s compile. With the flag, it becomes a real compile cache (623–850+ MB locally).

The flag is opt-in on Next 16.2 and becomes the default in 16.3.

Expected Vercel impact

• Warm compile (no-code-change / small-diff deploys after cache restore): 61s → ~40s (−20s)
• First deploy after merge stays cold
• Vercel build-cache cap is 1 GB. If restore drops a 850 MB+ cache, compile falls back to today's 61s. Watch the second deploy after merge.

What this PR changes

1. experimental.turbopackFileSystemCacheForBuild in next.config.mjs (on for Vercel / next build)
2. Remove postbuild:cleanup so the cache can survive into Vercel's build cache
3. Guard the flag off when STATIC_EXPORT=true so pnpm build:static does not write the compile cache under out/cache (Cloudflare Pages artifact)

What we measured and would not ship

Approach	Verdict	Why
Skip TypeScript (ignoreBuildErrors)	Do not ship	−16.5s on Vercel, but GitHub CI has no separate tsc job. next build is the only typecheck.
experimental.cpus: 8	Do not ship	Next already uses cpus - 1 (7 workers). ~1s SSG locally.
Skip/cache contributors GitHub fetch	Optional later	Only ~3s of prebuild.
Webpack instead of Turbopack	Do not switch	next build --webpack failed (fumadocs-mdx:collections/server).
Dynamic-render docs to cut SSG	Do not do	Faster build, worse TTFB/SEO. The 1.1 GB .next is 975 HTML + 7805 RSC pages.
Extra optimizePackageImports / outputFileTracingExcludes	Skip	Next already modularizes the big icon libs. Chromium in .next is ~8 KB. The upload gap is prerendered HTML/RSC.

How to verify on Vercel

1. First deploy after merge: compile should still be ~61s (cold cache).
2. Second deploy with a no-op or small content change: compile should drop if .next/cache restored. If cache restore fails or approaches 1 GB, turn the flag off or upgrade to Next 16.3 (default FS cache + eviction).

  

Greptile Summary

This PR enables Next.js 16.2's persistent Turbopack compilation cache and preserves it after production builds.

• Adds experimental.turbopackFileSystemCacheForBuild to the Next.js configuration.
• Removes the postbuild step that deleted .next/cache.
• Leaves sitemap, llms.txt, and static-export postbuild processing intact.

Confidence Score: 5/5

The PR appears safe to merge, with the cache-retention behavior consistently wired into the existing production and static build flows.

No concrete correctness, security, packaging, or workflow regression remains; environments that do not persist the cache simply receive no warm-build performance benefit.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Build[next build] --> Compile[Turbopack compilation]
  Compile --> Cache[.next/cache]
  Cache --> Vercel[Vercel build-cache persistence]
  Vercel --> Restore[Subsequent build restores cache]
  Restore --> Compile
  Build --> Postbuild[Postbuild sitemap and llms.txt]
  Postbuild -. no longer deletes cache .-> Cache

Loading

_{Reviews (1): Last reviewed commit: "perf(build): keep Turbopack compile cach..." | Re-trigger Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
langfuse-docs	Ready	Preview	Sep 4, 2026 1:07pm UTC

[github-actions]

@claude review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-04T12:53:06.637476Z	718d6c2	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[claude]

Claude Code Review

No review was started: this request came from a bot account. Manual reviews can only be requested by someone with write access to this repository. Ask a maintainer to comment @claude review, or have your automation post the comment from a user account with write access.

_{Tip: disable this comment in your organization's Code Review settings.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 718d6c23b1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Beyond the reported candidate issue, I checked that the next dependency is pinned to ^16.2.6 (matches the PR's claim that turbopackFileSystemCacheForBuild requires 16.2+) and that both edited files remain consistently formatted with their surroundings.

Extended reasoning...

This is a two-line-equivalent, self-contained config change (one experimental flag added in next.config.mjs, one script removed in package.json) with no bugs reported by the bug hunter. I independently verified the next version pin (^16.2.6) matches the PR's stated requirement for the flag, and that formatting is consistent. The one substantive risk — unbounded .next/cache growth without built-in eviction on Next 16.2 (eviction becomes default only in 16.3) — was already surfaced as a candidate issue and investigated this run, so I'm not re-raising it, just noting it was checked.

[cursor]

The Vercel preview failure is unrelated to this PR. No code change on this branch.

Deployment D2Rs97Wxt3cXUoGzvCqRzMwJa7uT went created → failed in ~1 second (12:46:01→12:46:02). A real next build of this site takes minutes, so this never reached compile, SSG, or cache restore. GitHub CI build-and-check-links on the same commit already ran next build successfully (✓ turbopackFileSystemCacheForBuild, compiled in 92s, 985/985 pages).

The same window failed previews for unrelated PRs (#3722, #3569, #3724, #3723, #3717, #3715, #3726). Last successful preview was #3705 at 12:32. Production deploys just before that succeeded. Vercel status is green — this looks like a project-level concurrent-build / rate-limit squeeze.

I could not pull inspector logs from here (no Vercel token). Redeploy this commit from the dashboard once the queue clears.