Stale-While-Revalidate Strategy

The stale-while-revalidate strategy returns cached content immediately when available, while simultaneously fetching a newer version and updating the cache in the background. In a service worker, this reduces perceived latency while allowing cached resources to become fresh over time.

A service worker can intercept a request and check the Cache Storage API for a previously stored response. If a cached response exists, it can be returned immediately instead of waiting for the network.

At the same time, the service worker starts a network request for the same resource. When that request succeeds, the fresh response is stored in the cache so a later request can receive the updated content. The current request does not normally wait for this refresh.

If there is no cached response, the strategy generally waits for the network, caches the successful response, and returns it. This makes the first request behave like a normal network fetch while subsequent requests can benefit from the cache.

The strategy is useful for resources where slightly outdated data is acceptable, such as static assets, avatars, or frequently refreshed content. It is less appropriate when every response must reflect the latest server state immediately.

Key points

• Return an existing cached response without waiting for the network.
• Perform a network request in parallel to refresh the cache.
• Cache the successful network response for future requests.
• On a cache miss, fetch from the network and populate the cache.
• Use SWR only when serving briefly stale data is acceptable.

Interview questions

How does stale-while-revalidate work in a service worker?

The service worker first looks for a matching response in Cache Storage. If one exists, it returns that response immediately so the user does not wait for the network. It also starts a network request to obtain a newer response and stores that response in the cache. If the cache has no match, the request waits for the network and the successful response can then be cached.

Why does a service worker often use response.clone() when implementing SWR?

A `Response` has a body that is consumed when it is read or passed through a response-handling operation. In SWR, the network response needs to be returned to the browser and also written into Cache Storage. `response.clone()` creates another consumable response so both operations can use the body. Without cloning, the cache write or response delivery can encounter an already-consumed body.

What should happen when there is no cached response?

The service worker should obtain the resource from the network because there is nothing stale to return. After a successful response is received, it can store a copy in Cache Storage. The network response is then returned to the page. This first request is therefore typically slower than later cache hits.

What are the trade-offs of stale-while-revalidate compared with network-first?

SWR generally provides lower perceived latency because an existing cached response can be returned without waiting for the network. Its trade-off is that the user may see data that is no longer current during that request. Network-first favors freshness by waiting for the network when it is available, but this can increase latency and make poor connectivity more noticeable. The appropriate strategy depends on how costly stale data is versus how important fast responses are.

How would you prevent an SWR cache from growing indefinitely?

The service worker can use explicit cache versioning and remove obsolete caches during the `activate` lifecycle event. Cache entries can also be limited by deleting old or rarely needed resources according to the application's caching policy. Resource-specific expiration or metadata can be implemented when the application needs tighter freshness control. The important point is that SWR needs a cache lifecycle policy rather than assuming cached entries should remain forever.