Service Worker Caching Strategies

## What a "strategy" is A service worker is a script the browser runs in the background for an origin. Once it controls a page, requests the page makes fire a `fetch` event in the worker, and `event.respondWith(promiseForResponse)` lets the worker decide what the page receives. A caching strategy is just the shape of that promise: which of `caches.match(...)` and `fetch(...)` you consult, in what order, and what you store afterwards. The five names below come from the literature and from Workbox's `workbox-strategies` package (`CacheFirst`, `NetworkFirst`, `StaleWhileRevalidate`, `CacheOnly`, `NetworkOnly`), but they are patterns, not APIs — you can write each in a few lines by hand. ## The five patterns - **Cache-first** — look in the cache; on a hit return it without touching the network; on a miss fetch, store, return. Fastest possible response and works offline, but the user gets whatever was stored until something else replaces it. - **Network-first** — fetch; if it resolves, return (and usually store a copy); if it rejects, fall back to the cache. Freshest possible response, but every load pays network latency, and offline is a fallback rather than the norm. - **Stale-while-revalidate** — return the cached response now, and in parallel fetch and store a fresh copy for the *next* request. One-load-stale by design. - **Cache-only** — never touch the network. Used for assets you precached at install and guarantee are present. - **Network-only** — never touch the cache. The default for anything you did not route. ```js async function staleWhileRevalidate(event) { const cache = await caches.open('api-v1'); const cached = await cache.match(event.request); const network = fetch(event.request).then((response) => { if (response.ok) cache.put(event.request, response.clone()); return response; }); event.waitUntil(network.catch(() => {})); return cached || network; } ``` Note `response.clone()`: a response body is a stream that can be read once, so you must clone before handing one copy to the page and the other to the cache. ## Why the asset class decides The question an interviewer is really asking is *what does this URL promise?* **Hashed bundles** such as `/app.8f3a1c2d.js` are content-addressed: the build renames the file whenever the bytes change. That makes the URL immutable, and immutable URLs are exactly what cache-first is for. There is nothing to revalidate, so a network round trip would be pure waste. **The HTML document** lives at a stable URL (`/`, `/products/42`) whose content changes on every deploy, and it is the file that names the current bundle hashes. Serve it cache-first and the user keeps loading last month's markup, which points at last month's bundles — the whole app freezes at that build. Network-first keeps the entry point fresh while still rendering something when the user is offline. **API JSON** is a judgment call. Stale-while-revalidate suits read-mostly, tolerant data — a feed, a product list, a dashboard that can visibly update a beat later. Data where staleness is dangerous (balances, permissions, anything the user just wrote) belongs on network-only, or network-first if you want a degraded offline read. ## Routing, not a global rule Because the strategy is per-asset, real service workers branch on the request before responding — commonly on `event.request.mode === 'navigate'` for documents, on `event.request.destination` (`'script'`, `'style'`, `'image'`, `'font'`), or on the URL path. Workbox expresses the same thing as `registerRoute(matcher, strategy)`. A worker that applies one strategy to everything is the single most common design mistake in this area. Two details worth stating out loud: only store responses you can trust (`response.ok`, and skip opaque cross-origin responses whose status you cannot inspect), and remember the worker's own `fetch()` still passes through the browser's HTTP cache, so a "fresh" revalidation can come back from there unless you pass `{ cache: 'no-cache' }` or similar on the request.