Reference guide · performance · Published 2026-08-16 · 3 min read
Service Worker caching strategies
Service Worker caching strategies: cache-first, network-first, stale-while-revalidate and when to use each for HTML, images, and API responses.
- ·The five core strategies
- ·Matching strategy to resource
- ·Serving HTML and navigations
The five core strategies
A service worker sits between the browser and the network and can answer any request it is asked to handle from its caches. The choice of strategy decides how fresh a response must be versus how fast it is returned. There are five standard strategies, and four of them are built by combining a cache with the network:
- Cache first, fall back to network: answer from cache if present, otherwise fetch and store. Fastest once primed; only as fresh as the cache.
- Network first, fall back to cache: try the network, store the result, and use the cached copy only if the network fails or times out. Freshest; slower when offline.
- Stale-while-revalidate: serve the cached copy immediately, then fetch the network version in the background and replace the cache for next time. Fast, always moving toward fresh.
- Network only: go to the network and never consult the cache. For content that must be live.
- Cache only: answer purely from cache and error if absent. Rarely used outside precached app shells.
The HTTP caching guide covers the related server-side Cache-Control layer; the service worker adds a runtime cache that sits in front of it and gives you programmatic control rather than just response headers.
Matching strategy to resource
Different resource types tolerate different freshness. A reliable mental model is to classify by how acceptable slight staleness is.
| Resource | Strategy | Why |
|---|---|---|
| HTML / navigations | Network first, or network first with a timeout | Must be reasonably fresh; fall back to cache only when offline |
| Versioned static assets (JS, CSS, fonts) | Cache first | Content-addressed filenames never meaningfully change, so cache hits are safe |
| Images, avatars, feed items | Stale-while-revalidate | Speed matters most; a briefly stale frame is fine and updates in the background |
| Payments, balances, order status | Network only | Serving stale data could be harmful |
| App shell (framework, shell UI) | Cache first | Non-critical common resources that define the experience |
Workbox exposes these as ready-made classes, so most projects get the routing and caching logic without hand-writing every handler:
import { registerRoute } from 'workbox-routing';
import { StaleWhileRevalidate, NetworkFirst, CacheFirst } from 'workbox-strategies';
registerRoute(({ request }) => request.destination === 'image',
new StaleWhileRevalidate({ cacheName: 'images' }));
registerRoute(({ request }) => request.destination === 'document',
new NetworkFirst({ networkTimeoutSeconds: 3 }));
registerRoute(({ request }) => request.destination === 'script' ||
request.destination === 'style',
new CacheFirst({ cacheName: 'static' }));Serving HTML and navigations
Navigation requests deserve their own care. The web.dev guidance is generally to satisfy navigations from the network with Cache-Control: no-cache, because caching HTML aggressively with Cache-Control can serve stale markup and its whole dependency chain. If you cache HTML at all, prefer network-first with a short timeout, or stale-while-revalidate when you know exactly which URLs are revisited, rather than a long-lived cache-first rule.
Two further details matter in practice. First, a lazy service worker that calculates a cached navigation can add latency to every page load, so enabling navigation preload lets the worker use a pre-fetched network response while the worker boots. Second, keep cache lifetimes and evictions bounded with a plugin such as ExpirationPlugin, so the cache does not grow without limit. Apply these ideas alongside the wider measurement flow in the web performance audit to confirm the caching changes actually move a field metric rather than just a single lab run.