Lesson 0001 · ~10 minutes
One skill: place service workers on the worker / network spectrum and pick them only when the hard problem is origin-scoped network policy (offline shell, request routing, programmable cache on the fetch path).
After the quiz, you can defend “service worker yes / no” in a design
review without writing register() yet — and without
confusing it with dedicated workers or with “just Cache Storage.”
Networks are slow, flaky, or offline. Users still expect a shell that appears, a clear failure when a request can’t complete, and fast repeat visits. Server CDN rules and the browser’s HTTP cache help — but they are not your JavaScript policy on every request.
A
service worker
is a browser-managed script that acts as a
programmable network proxy
for pages (and other clients) in its
scope. When a controlled
client fetches something, the service worker can intercept that
fetch event and answer from Cache Storage, the network, or
synthetic logic —
web.dev
literally draws it as middleware between the app and servers.
The normative model is the Service Workers specification; MDN’s Service Worker API is the practical map.
You already know dedicated workers from the Web Workers track: move compute off the main thread. Service workers share a few surface facts (separate thread, no DOM, message-passing) and then diverge completely:
new Worker per task and
terminate() when done.
If someone says “put it in a worker” for offline routing, ask which worker. Wrong type = wrong architecture.
From the Cache API track: Cache Storage is a
warehouse of Request/Response pairs. Anyone with
caches can open and fill it — including a window.
What a bare window cannot do is sit on every navigation and
subresource request for the origin and answer offline. That
interception path is the service worker’s
fetch event. web.dev’s
SW + Cache Storage
pairing is the classic architecture: SW decides policy; Cache Storage
holds the bytes.
Cache Storage alone = storage. Service worker = policy on the network path. Strategies (cache-first, network-first, SWR) live at the intersection — you already have the strategy catalog on the Cache API track; this track owns lifecycle and control.
Ordered by “what hard problem does this tool own?” — not by buzzword density.
Header- and edge-driven. Great default for static assets. Not your app-defined offline shell or per-request JS policy.
Code-driven warehouse of HTTP resources. Useful; does not intercept fetches by itself.
Origin-scoped network proxy: register, install, control clients,
fetch + Cache Storage strategies, update policy.
CPU / data work off the UI thread. No fetch proxy for the page.
Multi-tab process coordination. Still not “offline network middleware.”
If the hard part is “pages in this origin need programmable network behavior — offline shell, runtime caching policy, request routing” and you accept HTTPS, lifecycle, and update complexity, reach for a service worker. If the hard part is heavy compute, use a dedicated worker. If you only need to store a few responses for a later explicit read, Cache Storage (or another store) may suffice without SW. If CDN/HTTP cache already solves the asset problem, don’t invent a SW for fashion.
| Signal | Leans service worker | Leans away |
|---|---|---|
| Hard problem | Offline shell, fetch policy, in-app network routing | CPU jank, multi-tab shared compute, pure data model |
| Where code runs | Must sit on the request path for navigations/assets | Only explicit caches.match from a page |
| Environment | HTTPS (or localhost); SW-capable browsers | Insecure origin; no SW support required for core UX |
| Ops appetite | Willing to own update lag, versioning, debug cost | “Ship Workbox default and never look” with no owner |
| Classic fits | App shell, offline docs, custom cache strategies, installable PWA network layer | Image filter CPU, form validation, “use SW instead of a CDN” |
Lifecycle is the hard part. New workers wait; old clients stay controlled; stale shells bite; debugging update lag takes real skill. Jake Archibald’s service worker lifecycle is the canonical primary for that — next lessons. web.dev also warns: treat SW as progressive enhancement, not a hard dependency for first paint of core features (Learn PWA · Service workers).
Choose the best default. Options are matched for length so formatting does not hint. Feedback is immediate.
Product goal: first open after airplane mode should still show the app shell HTML/CSS/JS for the main routes.
Photo editor: a large filter freezes the UI for several seconds on mid-range phones; network is fine.
Marketing site: fingerprinted JS/CSS on a CDN with year-long Cache-Control; no offline product requirement.
SPA: same-origin JSON APIs should be cache-first when offline, with a clear fallback response when nothing is cached.
web.dev Learn PWA — Service workers Best short primary for this lesson’s middleware mental model, scope, and lifecycle sketch. Optional depth (lifecycle deep dive, next lesson’s core text): The service worker lifecycle (Jake Archibald).