The 5 ms number and the 3,128 ms number do not describe the same population. One is a median of CPU wall time inside a handler [2]. The other is a 75th percentile of field TTFB, which includes DNS, TLS and the network before any of your code runs [1]. Subtracting gives 3,123 ms [1], and that is a check on scale rather than an accounting entry. The scale is the point. Worker CPU metrics exclude isolate creation, bundle download and V8 script compilation, so the dominant term was never in the chart [3].
The traffic figure explains why the cold path was the normal path. Roughly 0.1 requests per second is one request every ten seconds, about 360 an hour [2], and that total is divided across every PoP that answers for you, so an individual PoP can go minutes between hits. Cloudflare evicts idle isolates under sparse traffic [5]. Nearly every new visitor, particularly organic search arrivals, therefore landed on a fresh isolate that had to load and compile roughly 11MB of JavaScript first, which the team puts at a three-second penalty on first visit [4][6].
Now look at where the fix sits. The cache lookup runs inside the Worker's own fetch handler in `src/server.ts`, using `caches.default` [7]. On a cold isolate the isolate still boots and the script still compiles before `cache.match` executes. A hit removes the SSR render, measured at 5 ms of CPU [2], not the compile in front of it. That is a genuine win on a warm isolate and on repeat traffic to the same PoP; it is not obviously a win for the organic first visit the audit was about.
The safety boundaries around that cache are the part worth copying. A request carrying the `better-auth.session_token` cookie bypasses cache read and write entirely [8]. Caching is restricted to an allowlist of anonymous public paths, with `/dashboard`, `/api/*` and `/settings` never cached [9]. Writes require status 200, `Content-Type: text/html`, and no `Set-Cookie` [10]. And because a new Worker deployment does not purge `caches.default`, a plain URL key would keep serving stale HTML for days after a fix ships [11]. Their answer is a compile-time build stamp, `Date.now().toString(36)` injected by Vite and appended to the key as `__ev` [12]. Note what that does: it orphans the old entries rather than deleting them.
For the number to transfer you need both halves of the original condition, an 11MB server bundle and traffic thin enough that isolates get evicted. Change either and the same dashboard blind spot still exists, but the hidden term is small enough to ignore.
What the write-up does not show is the after. It lists edge HTML caching, client bundle decoupling and reduced mobile hydration TBT [13], and claims a 95+ Lighthouse score [14]. Lighthouse is a lab run; the 3,128 ms that started this was field RUM from Cloudflare Observatory [1]. No post-change Observatory percentile appears, so the field improvement is unverified on this evidence.
