- Service worker
-
A special worker that acts as a
programmable network proxy for an origin
scope: it can intercept
fetch events for controlled clients, pair with
Cache Storage for offline/fast paths, and receive events like push
(later awareness). Same “worker” family as dedicated/shared workers
(no DOM, separate thread) — different job: network policy,
not CPU offload.
- Network proxy (SW role)
-
Mental model from
web.dev: the
service worker sits between pages in its scope and the network. Every
in-scope request can be answered from cache, network, or synthetic
logic — if your code chooses to.
- Client
-
A browsing context (page/window) or worker under the service worker’s
scope that the SW can control. Once controlled,
that client’s fetches go through the service worker’s
fetch handlers (unless bypassed, e.g. shift-reload).
- Scope
-
The URL path prefix the service worker is allowed to control. Default
is
./ relative to the service worker script URL (so
script location matters). Only one service worker registration is
active per scope.
- Registration
-
Calling
navigator.serviceWorker.register(scriptURL, options)
tells the browser to download, install, and manage a service worker
for a scope. Registration is not the same as “this page is already
controlled” on first visit.
- Control / controller
-
A client is controlled when an active service worker
owns its network requests.
navigator.serviceWorker.controller is that worker, or
null if none. First load often registers but does not
control until a later navigation (unless
clients.claim() — later lessons).
- Lifecycle
-
Install → (waiting, on updates) → activate → controlling clients, plus
update checks. First-SW path: lesson 2. Update dance: lesson 3.
- waiting
-
After a successful install of an updated service worker, the
new worker waits until the old active worker controls zero clients.
Prevents two versions of site logic fighting over shared storage.
- skipWaiting()
-
Call on the service worker (
self.skipWaiting()) to skip
the waiting phase and activate as soon as install finishes. Speeds
updates; can leave open pages half on old, half on new fetch behavior.
- redundant
-
Terminal state for a worker that failed install or was replaced. It
will not control clients.
- install (event)
-
First event a given service worker version receives. Fire once per
version. Typical work: precache shell assets via Cache Storage, extended
with
waitUntil. Failure discards
that worker.
- activate (event)
-
Fires when the worker is ready to control clients and handle functional
events. On updates, the usual place to delete obsolete caches after the
old worker is gone.
- waitUntil(promise)
-
On install/activate (and some other events), tells the browser to keep
the worker alive and treat success/failure of the promise as part of
that lifecycle step. Rejected install → worker never controls clients.
- clients.claim()
-
Called from an active service worker to take control of currently
uncontrolled clients in scope immediately, instead of waiting for the
next navigation. Optional; timing-sensitive; not default boilerplate.
- Secure context
-
Service workers require a secure context (HTTPS, or
localhost / loopback for development). No SW on plain
http:// production origins.
- Dedicated worker
-
Background thread for compute owned by one script
(
new Worker). Not a network proxy. Comparison label from
the Web Workers track.
- Shared worker
-
Multi-context worker for same-origin coordination. Still not a fetch
interceptor for navigations. Comparison only here.
- Cache Storage (Cache API)
-
Code-driven store of Request/Response pairs. Often used
inside a service worker’s install/fetch handlers, but
available outside SW too. Method map and strategies: Cache API track
in this repo.
- HTTP cache
-
Browser’s header-driven cache. Separate from Cache Storage and from
the service worker. Layers can cooperate or fight.
- Workbox
-
Popular library layer over service worker + Cache Storage primitives
(routing, strategies, precache manifests). Awareness only in this
mission — understand the platform first.
- fetch (event)
-
Fired on the service worker for network requests from controlled
clients (navigations and subresources). Your chance to intercept via
respondWith.
- event.request
-
The
Request for this fetch: URL, method, headers,
mode (e.g. navigate), etc. Input to matching
and strategy logic.
- respondWith(…)
-
On
FetchEvent: supply the Response (or
promise of one) that fulfills the page’s request. Must be called
synchronously in the event handler. Omit it → browser’s default
network path continues.
- Navigation request
-
Document load, typically
request.mode === "navigate".
Where app-shell / offline HTML policy usually lives, distinct from
image/script/API subresources.