Service Workers

In this chapter

We'll meet Service Workers from scratch — registration, the real install/activate lifecycle, the fetch event that intercepts every network request, and the real HTTPS-only security requirement — as the one mechanism that makes genuine offline behavior possible.

10–12 min

The Problem in Real Life

"We have a place to store cached responses," Sarah says, looking at the Cache API notes on the whiteboard. "But nothing decides when to use them yet. A normal page can't intercept its own network requests — something else has to sit in front of them."

She sketches a new box on the whiteboard, positioned between the page and the network itself. "This is that something."

Something has to sit between the page and the network, deciding what actually goes out and what gets answered from cache instead.

Sarah

A Page That Asks the Network vs. Something That Intercepts the Question

Intercepts every request via the fetch event

The real mechanism that decides whether a request hits the network or gets answered from cache — nothing else in this Act can do this.

HTTPS-only, on purpose

A Service Worker's power to intercept and rewrite requests makes it a real security risk over plain HTTP — browsers require HTTPS (localhost excepted) deliberately.

A Service Worker is a real, special kind of script that runs independently of any specific page — it can start before a page loads, keep running after a page closes, and most importantly, it can intercept every network request a page makes and decide, in real code, how to answer it.

Registration — the real starting point. A page registers a Service Worker with navigator.serviceWorker.register('/sw.js'), pointing at a separate JavaScript file that becomes the worker's own code. Once registered, that file runs in its own real, separate context — not attached to any one page, with no direct access to the DOM at all.
A real, specific lifecycle: install, then activate. When a Service Worker is first registered, it goes through an install event — the real, natural place to pre-cache a known set of files using the Cache API from the previous chapter. Once installed, it waits, then moves to an activate event once no older version of the worker is still controlling open pages — the real, deliberate handoff point where an old cache can be safely cleaned up.
The real mechanism that makes offline work: the fetch event. Once active, a Service Worker can listen for a fetch event — fired for every single network request a controlled page makes. Inside that event handler, real code decides: answer from the Cache API, forward to the real network, or some real combination of both (a strategy — covered in the next chapter). This interception is the actual mechanism that makes "still works offline" genuinely possible, not a browser default.
A real, deliberate security requirement: HTTPS only. Because a Service Worker can intercept and rewrite every request a page makes, browsers require it to run only on HTTPS (with one real exception: localhost, for development). This isn't an inconvenience — a Service Worker running over plain, interceptable HTTP would be a genuinely serious security risk, letting anyone on the network path inject one.

A Service Worker registered with no real logic inside it does nothing useful — the real power is entirely in what its install and fetch handlers actually do. This chapter covered the mechanism itself, honestly and completely; the next chapter covers what GreenMart should actually build with it.

Key Takeaway

A Service Worker is the one real piece in this whole Act that can sit between a page and the network itself, deciding, in real code, whether a request even needs to leave the device at all — everything genuinely offline-capable in a web app depends on this one mechanism existing.

Why This Matters

Every other mechanism this Act has covered — cookies, localStorage, IndexedDB, the Cache API — stores data. Only a Service Worker can actually decide, live, whether a given request should touch the network at all. It's the real missing piece between "we have cached data" and "the app actually works offline."

GreenMart now has the real mechanism that makes offline behavior possible: a Service Worker, intercepting requests via the fetch event, deciding in real code how to answer them. The next chapter turns this mechanism into a real, working offline-first strategy — and finally builds Mike's original idea for real.