Service Workers as Network Layer
You switch the browser to Offline, reload the notes app you shipped, and fetch('/today.json') still comes back 200 with today's list, no request having left the machine. Something answered in the network's place.
- ▸Register a worker, reload nothing, and its handler fires for zero requests: control starts on the next load.
- ▸Set
Cache-Control: no-storeand the worker's own cache serves the response anyway: that header steers a different store. - ▸Ship a new worker with one tab open and users keep the old code until every controlled tab closes.
The browser is still set to Offline, and the request in the Network panel still reads 200 OK. Its Size column does not name a byte count from the server; it says (from ServiceWorker). A service worker answered: a script the browser runs on its own, beside the page but not part of it, sitting on the client side of the network.
The arrangement is simple once you see it. The worker registered earlier and now stands in the request path. Every network request the page makes fires an event inside the worker, and the worker's fetch handler receives that request before a single byte reaches the network. The handler holds one decision. It can call event.respondWith(r), and the browser hands r straight back to the page as the response, the network untouched. Or it can do nothing at all, and the browser makes the request exactly as it would have with no worker present.
That is the whole mechanism behind the offline 200. The handler built a Response from a string it already had and passed it to respondWith. The page called fetch('/today.json') and received a real response object, with a real status and a real body, and nothing in the page can tell that the bytes were assembled locally rather than pulled down a wire. Flip the handler's respondWith call off and the same request falls through to the network, which is offline, and fails. The worker is standing in the path, and one line decides whether it answers.