What Is a Service Worker? A Proxy Inside the Browser
A service worker is a script the browser runs in the background, sitting between your app and the network so it can intercept requests and serve cached responses.
A service worker is the engine behind offline support and advanced caching in modern web apps. Once registered, it runs separately from any page and can intercept every network request the app makes. That power makes it central to PWAs, but it also makes versioning and updates a careful, build-time concern.
How it intercepts requests
After registration and activation, the service worker handles fetch events for its scope. It can return a cached response, fetch from the network, or combine both with strategies like cache-first or network-first.
The lifecycle
A service worker installs, activates, then controls pages. A new version installs in the background and waits until existing pages close before taking over, which prevents two versions from running at once but means updates are not instant.
What it enables
- Offline access by serving cached assets.
- Faster repeat loads from local caches.
- Background sync and push notifications where supported.
The stale-cache risk
A misconfigured service worker can pin users to old assets, serving a stale app even after you deploy. Cache names and precache manifests must change with each build so the worker knows to fetch the new version.
Service workers in CI/CD
The build step generates the service worker and a precache manifest listing the hashed asset files for this release. Because the manifest is tied to content hashes, every CI build produces a worker that knows exactly which files changed, so users update cleanly rather than getting stuck on old code.
Key takeaways
- A service worker intercepts network requests to enable offline support and caching.
- Its lifecycle waits for old pages to close, so updates are not instant.
- CI generates a precache manifest tied to content hashes so users update cleanly.