Service Worker
debt(d8/e5/b6/t7)
Closest to 'silent in production until users hit it' (d9), slightly better at d8 because Lighthouse/PWA audits can flag missing or misconfigured service workers, but most issues (wrong scope, stale cache, missing activate cleanup) only surface when users report broken offline behaviour or stale assets.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix shows a non-trivial implementation: sw.js at root, install/fetch/activate handlers, cache versioning. Fixing a scope mistake requires moving the file and re-registering; fixing stale-cache requires versioning strategy across the worker.
Closest to 'strong gravitational pull' (b7), scored b6 because while it shapes asset deployment, cache-busting strategy, and update flow across the whole frontend, it's contained to the client-side layer. Every static asset change must consider cache versioning.
Closest to 'serious trap' (t7). The misconception (registering a SW gives automatic offline support) directly contradicts reality — an empty SW does nothing. Scope rules (subdirectory placement silently limiting control) and cache versioning gotchas compound this; the 'obvious' mental model is wrong.
Also Known As
TL;DR
Explanation
A service worker is a type of web worker registered against an origin and scope. It runs in its own thread, has no DOM access, and persists beyond the page lifecycle. Its primary power is the fetch event — every network request from pages in its scope passes through the service worker, allowing it to serve cached responses, fall back to the network, or return custom responses. The service worker lifecycle has three states: installing (downloading and caching assets), waiting (ready but not yet active), and active (controlling pages). Cache strategies implemented in service workers include: cache-first (serve from cache, fall back to network), network-first (try network, fall back to cache), and stale-while-revalidate (serve cache immediately, update in background).
Common Misconception
Why It Matters
Common Mistakes
- Placing the service worker script in a subdirectory — a service worker at /app/sw.js only controls pages under /app/; place it at /sw.js to control the entire origin.
- Not versioning the cache name — when you update assets, increment the cache version string to trigger installation of a new worker and deletion of the old cache.
- Caching API responses that should never be stale — use network-first or stale-while-revalidate for dynamic data, not cache-first.
- Not handling the activate event to delete old caches — old cache versions accumulate and consume disk space if not cleaned up.
Code Examples
// Empty service worker — does nothing
self.addEventListener('install', () => {});
self.addEventListener('fetch', () => {});
// User gets no offline support despite registration
const CACHE = 'app-v1';
const ASSETS = ['/', '/style.css', '/app.js', '/offline.html'];
// Cache assets on install
self.addEventListener('install', e => {
e.waitUntil(caches.open(CACHE).then(c => c.addAll(ASSETS)));
});
// Delete old caches on activate
self.addEventListener('activate', e => {
e.waitUntil(caches.keys().then(keys =>
Promise.all(keys.filter(k => k !== CACHE).map(k => caches.delete(k)))
));
});
// Cache-first with network fallback
self.addEventListener('fetch', e => {
e.respondWith(
caches.match(e.request)
.then(cached => cached || fetch(e.request))
.catch(() => caches.match('/offline.html'))
);
});