Two caching policies, side by side. Both use a real cache, real network requests and real timings — nothing here is animated. The only difference is what each does when a page is not in the cache.
The browser fetches ~150 scripts, then asks 21 questions, then draws the page
stale-while-revalidate — re-render behind the scenes, never show nothing
What is real here. Both panels hit a live Cloudflare cache. The 220 ms render delay is the origin think-time we measured on a production commerce API (median 279.8 ms per uncached product lookup, of which ~22 ms is the Tasman crossing and ~7 ms the local hop). The 150 script fetches and 21 data calls are real HTTP requests, made by your browser, right now.
What it is not. This is not anyone's website. The content is deliberately generic — the demonstration is about delivery, not about any particular retailer.
The whole difference is one branch: on a cache miss, return
shell and let the browser build the page, or return the last known good
render and revalidate behind. Source is about fifty lines and is linked below.
This proves the principle, not the implementation. It shows that returning the last good page beats returning an empty one — with real numbers. It does not claim to know how any particular site would wire this into its own platform. On a real store the question that decides the effort is which parts of a page are personal to the customer; only that store’s own team can answer it. We diagnose and measure — we do not estimate someone else’s engineering.
Kaimai Security Limited · measurement notes available on request