Definition

Stale-while-revalidate

Short definition

Stale-while-revalidate is a fetch-handling strategy that serves whatever is already in Cache Storage without waiting on the network, then kicks off a background fetch to refresh that cache entry for the next request. It gives cache-first speed with eventual freshness, at the cost of occasionally showing content that is one request-cycle out of date.

Reviewed July 31, 2026

A typical implementation: event.respondWith(caches.open("data-v1").then(async (cache) => { const cached = await cache.match(event.request); const fetchPromise = fetch(event.request).then((res) => { cache.put(event.request, res.clone()); return res; }); return cached ?? fetchPromise; }));, which returns the cached copy immediately if present but still lets fetchPromise update the cache in the background.

This pattern originates from the HTTP Cache-Control: stale-while-revalidate directive (see the IETF spec, RFC 5861) and service workers reimplement the same idea at the application layer with full control over cache lifetime.

It is well suited to content like user avatars, feed thumbnails or a dashboard summary where showing slightly stale data for one refresh cycle is an acceptable trade-off for instant load.

Workbox ships this as workbox.strategies.StaleWhileRevalidate, and it is one of the three strategies documented in Google's offline cookbook alongside cache-first and network-first: https://web.dev/articles/offline-cookbook.

Related terms

Cache-first strategy

Cache-first is a fetch-handling strategy: event.respondWith(caches.match(event.request).then((cached) => cached ?? fetch(event.request))). It serves cached content instantly and skips the network entirely when a match exists, making it ideal for versioned, immutable assets such as hashed JS/CSS bundles or app-shell icons that never change once deployed.

Network-first strategy

Network-first is a fetch-handling strategy: event.respondWith(fetch(event.request).then((res) => { cache.put(event.request, res.clone()); return res; }).catch(() => caches.match(event.request))). It prioritises up-to-date data and only serves a cached copy if the network request fails outright, making it the standard choice for API calls and frequently changing pages.

Runtime caching

Runtime caching means storing a response in Cache Storage the first time a matching request is actually made by the user, inside the fetch event handler, as opposed to precaching, which loads a known asset list upfront during install. It is the natural fit for content whose full URL set is not known ahead of time, such as user-generated images or paginated API results.

Precaching

Precaching means fetching and storing a known list of build-time assets (HTML shell, CSS, JS bundles, key icons) in Cache Storage inside the install event handler, so they are guaranteed to be available offline from the very first load rather than being cached only after a user happens to request them.

Workbox

Workbox is a collection of JavaScript libraries and build tools (workbox-precaching, workbox-routing, workbox-strategies, workbox-expiration, and more) maintained by the Chrome team that implement the recurring service worker patterns — precache manifests, route matching, cache-first/network-first/stale-while-revalidate strategies — so teams do not hand-roll them from scratch.

Push API

The Push API lets a service worker subscribe to a browser-run push service and receive encrypted messages from a server at any time, including when no tab or window for the site is open. Subscribing is done with registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey }), and incoming messages arrive in the worker's push event.