Performance
Stale-while-revalidate
Also called SWR.
Stale-while-revalidate is a caching strategy that serves a cached copy immediately, even if it has expired, while fetching a fresh copy in the background. Visitors get speed first and freshness one request later.
How it is measured
In HTTP it is a `Cache-Control` directive: `max-age=60, stale-while-revalidate=300` means serve as fresh for 60 s, then serve stale for up to 300 s while revalidating. Check the response headers, and the `Age` header tells you how old the cached copy is.
Observe it by requesting a URL repeatedly. The first request after expiry returns fast with an old body and a high `Age`, and the next returns the new body. Service workers and data libraries such as SWR and React Query follow the same pattern in code.
Worked example
A sports score API response is cached at the CDN with `max-age=10, stale-while-revalidate=60`. At 20:00:11 the entry is 11 s old. A fan's request gets the stale copy in 28 ms while the CDN refetches from the origin in 340 ms. Without it, that request would have waited 340 ms.
During a match with 800 requests a minute, the origin sees about 6 revalidation fetches a minute instead of hundreds.
How it differs
Stale-while-revalidate extends Cache-Control `max-age`: max-age says when a copy turns stale, and this directive says how long a stale copy may still be served. It does not suit content that must never be stale, like prices at checkout or auth state.
Common errors
Using it on personalised pages. Setting such a long window that stale data lingers for hours. Assuming every CDN honours it. Confusing it with `stale-if-error`. Expecting the visitor who triggers revalidation to see the fresh content.
In practice
Use it for content that can be a minute or an hour out of date: article lists, catalogs, public API responses. Start with something like `max-age=60, stale-while-revalidate=600` and watch the origin's request rate and the `Age` header. Keep it off carts and account pages.