Stale-while-revalidate
A caching rule that hands over the cached copy instantly, then fetches a fresh one in the background for the next visitor.
See it
What it is
A cache directive that buys speed with a little staleness. 'Cache-Control: s-maxage=60, stale-while-revalidate=600' means: for 60 seconds the cached copy is fresh, and for 10 minutes after that the cache may still hand it over instantly while it fetches a new version in the background. Inside that window, nobody waits on the origin.
Reach for it on content that changes on its own schedule and does not have to be perfectly current: marketing pages, blog indexes, pricing tables, dashboards of yesterday's numbers. It also smooths out the traffic spike that hits your origin the moment a popular cache entry expires.
The gotcha that confuses everyone: the visitor who triggers the revalidation gets the old copy. You publish, you refresh, you see nothing, you refresh again and there it is. That is the feature working. If a change must appear immediately, pair it with an explicit purge instead of shortening the window to nothing.
The other half of the promise: it only covers requests that land inside the window. The first request for something the cache has never held is an ordinary miss and waits on the origin like any other, and once the fresh and stale windows have both run out, the next visitor waits too. Popular routes get the free ride; the long tail still pays.
Ask AI for it
Add stale-while-revalidate caching to these page routes: set 'Cache-Control: public, s-maxage=60, stale-while-revalidate=600' on the HTML response so the CDN serves a cached copy with no wait and refreshes it in the background. Keep the browser copy short with 'max-age=0, must-revalidate' so users always get the CDN's version, exclude anything personalized or session-based, and show me exactly where the headers are set.