Service Workers & Cache API
⏱️ ~3-minute bite · solve the sandbox to master
5-Year-Old Metaphor
— The physical, real-world picture. No jargon.🕵️ A Service Worker is a personal proxy running in your browser.
The proxy analogy
Every network request your page makes goes through the Service Worker first — like mail going through a proxy server. The SW can intercept (serve from cache), modify (add auth headers), queue (save for retry when offline), or forward (pass through to network).
It lives in a separate thread — not the main JS thread. It keeps running even after the user closes your tab (briefly), which is how push notifications and background sync work.
What Service Workers unlock
📦 Offline support
Serve cached assets when network fails. PWA apps work without internet.
⚡ Performance
Cache-first assets load in 0ms. No network round trip for repeat visitors.
📶 Background sync
Queue failed requests. Retry automatically when connection returns.
🔔 Push notifications
Receive server pushes and show OS-level notifications even when app is closed.
Critical constraints
- • HTTPS only (localhost exempted for dev)
- • Runs in separate thread — no DOM access
- • Scope-limited: /admin/sw.js can only control /admin/* pages
- • Different from Web Worker (SW intercepts network; Web Worker runs compute)
Interactive Sandbox
— Move something, see it react instantly.Pattern
navigator.serviceWorker.register('/sw.js')
Browser downloads and parses sw.js
self.addEventListener('install', e => e.waitUntil(precache()))
SW caches core assets (precache)
New SW waits — old SW still active
New SW in waiting state
self.addEventListener('activate', e => e.waitUntil(cleanOldCaches()))
Old SW deactivated, new SW takes control
self.skipWaiting(); self.clients.claim()
New SW immediately takes control of all pages
Challenge
Step through all 5 patterns to their final step. Understand the SW lifecycle and cache strategies.
Why Should I Care?
— The exact interview question + the bug it kills.Interview questions
Q: Why can Service Workers only work on HTTPS?
A SW sits between your page and the network — it can intercept and modify any request. On HTTP, an attacker with network access could inject a malicious SW that intercepts all your traffic. HTTPS prevents this: the SW file is delivered over an authenticated, encrypted connection, so you know it's your code running. Exception: localhost is allowed without HTTPS for development purposes.
Q: What is the difference between Service Worker and Web Worker?
Both run in separate threads (no DOM access, communicate via postMessage). The difference: Web Workers are for offloading CPU-intensive computation (image processing, data parsing) — they live only while the page is open. Service Workersare a network proxy — they intercept fetch requests, manage caches, and can run briefly after the tab closes (for push and background sync).
Q: How do you handle SW updates without breaking users?
The safest pattern: let the new SW wait (default behavior). Show a "New version available — click to update" banner when a waiting SW is detected via registration.waiting. When the user clicks, send the waiting SW a SKIP_WAITING postMessage, then window.location.reload() to load the new version. This gives users control and prevents mid-session breakage.
The Deep Dive
— Spec refs, engine internals, the minutiae.Workbox — production cache management
Writing cache strategies manually is error-prone. Workbox (Google) provides battle-tested implementations:
| 1 | import { registerRoute } from 'workbox-routing'; |
| 2 | import { StaleWhileRevalidate, CacheFirst, NetworkFirst } from 'workbox-strategies'; |
| 3 | import { CacheableResponsePlugin } from 'workbox-cacheable-response'; |
| 4 | |
| 5 | // Static assets: cache first, max 30 days |
| 6 | registerRoute( |
| 7 | ({ request }) => request.destination === 'image', |
| 8 | new CacheFirst({ cacheName: 'images', plugins: [ |
| 9 | new CacheableResponsePlugin({ statuses: [0, 200] }), |
| 10 | ]}), |
| 11 | ); |
| 12 | |
| 13 | // API: network first, fall back to cache |
| 14 | registerRoute( |
| 15 | ({ url }) => url.pathname.startsWith('/api/'), |
| 16 | new NetworkFirst({ cacheName: 'api-responses' }), |
| 17 | ); |
| 18 | |
| 19 | // App shell: stale-while-revalidate |
| 20 | registerRoute( |
| 21 | ({ request }) => request.mode === 'navigate', |
| 22 | new StaleWhileRevalidate({ cacheName: 'pages' }), |
| 23 | ); |
SW debugging in Chrome DevTools
SW update patterns comparison
| Pattern | When activates | Risk |
|---|---|---|
| Default wait | After all old-SW tabs closed | Low — safest |
| skipWaiting (auto) | Immediately on install | Old HTML + new SW mismatch |
| User-triggered skip | User clicks 'Update now' | Low — user controls timing |
Interview Questions
— Real questions from real interviews — with answers.Install → precache; waiting → new SW pauses until all old-SW tabs close; activate → clean old caches and take control.
Serve the cached version immediately while fetching a fresh copy in the background for the next request.
Responses are single-use streams — reading the body for caching consumes it; clone() gives you two independent readable copies.
Background Sync fires even after the user closes the app; a JS retry loop stops when the tab closes.
HTTPS is required (except localhost) because a SW intercepts all requests — on HTTP an attacker could inject a malicious SW.
Detect registration.waiting, show an update banner, send SKIP_WAITING on user click, then reload.
Memory Game
— Quick quiz — lock the concept in long-term memory.What is the purpose of `clients.claim()` in the `activate` event?