fix: include deployment id in the webpack cache key

[marcleblanc2]

Problem

Every font downloads twice in production. The HTML preloads fonts with ?dpl=<current deploy>, but the CSS url()s carry the previous deployment's dpl, so the browser sees two URLs per font (verified live with curl on the CSS chunk vs the HTML).

Cause: next/font bakes Vercel's skew-protection ?dpl= into the CSS at build time via the deploymentId loader option, but Next's webpack filesystem cache key (webpack-config.js, the configVars blob) does not include deploymentId. Vercel restores .next/cache, so the cached CSS module is re-emitted with the old id.

Fix

A webpack() hook in next.config.js appends NEXT_DEPLOYMENT_ID to config.cache.version, so each deployment gets a fresh webpack cache.

Tradeoffs

• The whole webpack cache is invalidated every deploy, so builds are cold each time (a few minutes on Vercel instead of ~2). Content changes dominate this repo, so it is probably fine, but it is a real cost.
• Alternative with no code: turn off Vercel Skew Protection for this project. Then there is no dpl query at all. Worth considering since this is a static docs site.
• The upstream fix is for Next to add deploymentId to configVars; happy to file that if wanted.

Verification

Reproduced and fixed locally with back-to-back builds on a warm .next/cache:

config	build 1	build 2	CSS dpl after build 2	HTML dpl
this PR	dpl_test123	dpl_test456	dpl_test456 ✅	dpl_test456
main	dpl_test789	dpl_testABC	dpl_test789 ❌	dpl_testABC

After the production deploy: curl -s https://sourcegraph.com/docs/_next/static/css/<hash>.css | grep -o 'dpl_\w*' | sort -u should match the dpl in the page HTML.

[vercel]

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

Project	Deployment	Actions	Updated
sourcegraph-docs	Ready	Preview	Sep 17, 2026 2:34am UTC

[github-actions]

Open the Diff Tour for this PR in Sourcegraph

[marcleblanc2]

From the docs site audit (crawl of all 502 pages).

Crawl evidence for the double font download: on 403 of 502 pages every font was fetched twice (~110 KB wasted, preloads unused), because the CSS was served under one ?dpl= deployment id but referenced font files under an older one. The pattern disappeared for pages crawled after a mid-crawl deploy, which fits the stale-webpack-cache diagnosis here.