Cache strategies — cache-first, network-first, stale-while-revalidate

Using a single cache strategy for all resources produces either stale data (cache-first on API calls) or poor offline experience (network-first on static assets). Developers apply one strategy universally and hit tradeoffs.

Match cache strategy to resource type:

// Cache-first (static assets: JS, CSS, images, fonts)
// Fast, offline-capable. Risk: stale assets until cache version bumps.
self.addEventListener('fetch', event => {
if (isStaticAsset(event.request.url)) {
event.respondWith(
caches.match(event.request).then(cached => cached || fetch(event.request))
);
}
});

// Network-first (API calls, HTML documents)
// Fresh data when online. Falls back to cache when offline.
function networkFirst(request) {
return fetch(request)
.then(res => { / clone and cache / return res; })
.catch(() => caches.match(request));
}

// Stale-while-revalidate (frequently updated but not critical: avatars, non-breaking API)
// Returns cache instantly, then updates cache in background.
function staleWhileRevalidate(request) {
return caches.open('dynamic').then(cache =>
cache.match(request).then(cached => {
const fetchPromise = fetch(request).then(res => {
cache.put(request, res.clone());
return res;
});
return cached || fetchPromise;
})
);
}

There is no universally optimal cache strategy. Static assets can tolerate cache-first with versioned filenames; real-time API data requires network-first; content that benefits from perceived speed but tolerates brief staleness suits stale-while-revalidate.

Designing service worker fetch handler for a PWA with mixed resource types