- Shipped
- 20 Agosti 2026, 21:02 UTC
- Author
- Kamo
- Commit
- d268380
Two findings, and the second one was mine. THE DOCUMENT TOOK 1,259 ms BECAUSE OF THE NONCE WRAPPER. Measured against the live site: the HTML answered in ~900 ms while a static asset answered in 59 ms. The difference is `zlib.brotliCompress` called with no options, which runs at QUALITY 11 — the slowest setting — on ~490 KB of HTML, per request, for every visitor. q=11 565 ms 38,094 bytes q= 6 13 ms 43,705 bytes q= 5 5 ms 44,699 bytes gzip 8 ms 75,360 bytes Quality 11 buys 6.6 KB over quality 5. On a throttled mobile link that is worth about 30 ms of transfer, against 560 ms of server CPU: half a second lost, by everyone, on every page, to save a third of a second's worth of bytes. Quality 5 still beats gzip by 30 KB. Local TTFB through the wrapper goes ~900 ms -> ~21 ms. check-csp-nonce.mjs now fails the build if brotliCompress is called without an explicit quality. A timing assertion would be flaky in CI; the shape of the call is not. Verified by reintroducing the bug and watching it fail, then restoring. THE PRECONNECT IS NOW A DNS-PREFETCH. Lighthouse was right that it was unused, and the reason is that the work removing requests removed its customers. The hero backdrop goes through /_next/image, so it is same-origin; the wordmark is inline; the reel is tap-to-play; the SVG favicon is gone. Traced what actually contacts that origin: nothing until the chat widget at +9.3 s, and it is `lazyOnload`. Chrome closes an idle preconnect socket after about ten seconds, so the connection was opened at parse time and abandoned before anyone collected it. DNS resolution is the half that still helps and the half that survives — cached far longer than a socket, so the widget skips a lookup when it finally arrives, and nothing is held open in the meantime. Same shape as the analytics hint beside it, which is lazyOnload for the same reason. On the dependency tree itself: it is two levels, document -> stylesheet, which is already minimal. The chain was long because its FIRST link was slow, not because it was deep — so the fix above is the fix for both. Inlining the stylesheet to remove the second link stays rejected on the measurement already recorded in next.config.ts.