Caching: from HTTP to the layers you write yourself

Take a single style.css file and follow its day on a live site: first the browser downloads it, then it serves it from memory without asking the server, then it asks the server whether its copy is still current and usually gets just a confirmation instead of the whole file, and after you deploy a new version it downloads it again. That one story is all of HTTP caching - Cache-Control, ETag, 304, and stale-while-revalidate.

Turn off the internet, refresh the page - and it still works. Behind that is the Service Worker: a separate script that steps between the page and the network and intercepts every request for a file before it reaches the server. It decides whether to answer from the network, from its own cache (Cache API), or on its own terms - and from that one decision come all the caching strategies, offline mode, and the classic 'after a deploy the user sees the old version' trap.

The same server response can sit in several caches at once - app memory, the Service Worker, the HTTP cache, the CDN - and the whole page is held by bfcache on top of that. Each has a different owner and something different clears it, so "clear cache" hits one of them, sometimes none. What's left is the question every such debugging session starts with: which layer is holding the stale copy, and what invalidates it.