stale-while-revalidate
Allows caches to serve stale content immediately while fetching a fresh copy in the background. The user gets fast response times (cached content), and the next user gets fresh content. Specified as additional seconds beyond max-age during which stale serving is allowed.
Full Explanation
stale-while-revalidate is one of the most useful Cache-Control directives for performance. When a cached response becomes stale, instead of making the user wait while the cache fetches a fresh copy, the cache immediately serves the stale version and kicks off a background revalidation. The current user gets an instant response, and the next user gets the fresh content.
The value is specified in seconds beyond max-age during which this behavior is allowed. So max-age=300, stale-while-revalidate=60 means content is fresh for 5 minutes, and for the next 60 seconds after that the cache can serve stale while fetching fresh. After those 60 extra seconds, the cache treats it as a full miss.
Cache-Control: public, max-age=300, stale-while-revalidate=60
This completely eliminates the latency penalty of cache misses for returning visitors. The pattern is widely supported by CDNs and modern browsers. In Varnish, the equivalent is grace mode, configured in VCL:
sub vcl_backend_response {
# Allow serving stale for 60s while fetching fresh
set beresp.grace = 60s;
set beresp.ttl = 300s;
}
Examples
A common production header for content pages that balances freshness with performance:
Cache-Control: public, max-age=300, stale-while-revalidate=60, stale-if-error=86400
Fresh for 5 minutes. After that, serve stale for up to 60 seconds while fetching fresh in the background. If origin is down, serve stale for up to 24 hours.
In nginx, you can enable this with proxy_cache_use_stale:
location / {
proxy_cache_use_stale updating;
proxy_cache_background_update on;
add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";
}
Video Explanation
Frequently Asked Questions
Allows caches to serve stale content immediately while fetching a fresh copy in the background. The user gets fast response times (cached content), and the next user gets fresh content. Specified as additional seconds beyond max-age during which stale serving is allowed.
A common production header for content pages that balances freshness with performance:
Cache-Control: public, max-age=300, stale-while-revalidate=60, stale-if-error=86400
Fresh for 5 minutes. After that, serve stale for up to 60 seconds while fetching fresh in the background. If origin is down, serve stale for up to 24 hours.
In nginx, you can enable this with proxy_cache_use_stale:
location / {
proxy_cache_use_stale updating;
proxy_cache_background_update on;
add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";
}