Stale-While-Revalidate

The core mechanism relies on a non-blocking background update. When a request arrives during the stale window, the cache immediately returns the existing (stale) data to avoid latency. Simultaneously, it initiates a single asynchronous fetch to the origin server to populate the cache for the next request.

• Immediate Response: The user never waits for the network round-trip.
• Population Trigger: The stale response triggers the revalidation, not a separate cron job.
• Request Coalescing: Multiple simultaneous requests for the same stale asset typically trigger only a single origin fetch.

The behavior is controlled via the Cache-Control response header. The directive stale-while-revalidate accepts a delta-seconds argument specifying the maximum staleness lifetime.

• Standard Syntax: Cache-Control: max-age=60, stale-while-revalidate=3600
• Interpretation: The asset is fresh for 60 seconds. For an additional 3,600 seconds after that, it is stale but usable for background revalidation.
• Total Usability Window: The asset can be served from cache for a total of 3,660 seconds without blocking the user.

Unlike must-revalidate or no-cache, stale-while-revalidate eliminates the synchronous penalty. Standard revalidation blocks the user until the origin confirms the cached copy is still valid.

• Synchronous Wait: must-revalidate adds origin latency to the user's request.
• Asynchronous Update: stale-while-revalidate hides origin latency entirely from the user.
• Risk Profile: The trade-off is that users may receive slightly outdated data during the stale window.

stale-while-revalidate is often paired with stale-if-error to create a robust caching strategy. While stale-while-revalidate handles normal expiration, stale-if-error provides a fallback when the origin server is unreachable.

• Normal Expiry: stale-while-revalidate serves stale content while the origin is healthy.
• Origin Failure: stale-if-error serves stale content only if the background revalidation fails.
• Combined Header: Cache-Control: max-age=60, stale-while-revalidate=3600, stale-if-error=86400

This directive is supported by modern browsers and major CDN providers, making it a production-ready standard for web performance optimization.

• Browser Support: Chrome, Firefox, and Edge have supported it since 2019.
• CDN Support: Fastly, Cloudflare, and Akamai offer native implementations.
• Service Workers: The strategy can be replicated manually in a service worker using the Cache API for offline-first architectures.

The pattern is most effective for assets where eventual consistency is acceptable but immediate loading is critical. It is not suitable for transactional data requiring strong consistency.

• News Headlines: Tolerates a few minutes of staleness for instant page loads.
• Social Media Feeds: Prioritizes perceived speed over strict ordering.
• Product Images: Visual assets rarely change, making a long stale window safe.
• Anti-Pattern: Do not use for financial balances or inventory counts where stale data could cause errors.

The foundational HTTP directive that specifies the maximum time, in seconds, a resource is considered fresh. stale-while-revalidate extends this by defining a grace period after max-age expires. During max-age, the cache serves the response without contacting the origin. After expiry, the response becomes stale, triggering the revalidation window if stale-while-revalidate is set.

• Example: Cache-Control: max-age=60, stale-while-revalidate=30 means the resource is fresh for 60 seconds, then stale-but-usable for 30 seconds while a background refresh occurs.

A companion directive that allows a cache to serve a stale response when the origin server returns a 5xx error or is unreachable. While stale-while-revalidate optimizes for latency by serving stale content during a successful background refresh, stale-if-error optimizes for resilience by serving stale content only during origin failure.

• Combined usage: Cache-Control: max-age=60, stale-while-revalidate=30, stale-if-error=300 provides both latency hiding and fault tolerance.
• Risk: Overly long stale-if-error windows can mask persistent origin outages.

The HTTP revalidation mechanism that makes stale-while-revalidate efficient. When a cached response becomes stale, the cache sends a conditional request to the origin with an If-None-Match header containing the cached ETag. If the resource hasn't changed, the origin returns 304 Not Modified with an empty body, saving bandwidth. If changed, the full fresh response is returned.

• Efficiency: A 304 response is typically a few hundred bytes versus potentially megabytes for the full resource.
• Interaction: stale-while-revalidate triggers this conditional request asynchronously while serving the stale version.

Content Delivery Networks implement stale-while-revalidate at globally distributed edge nodes to absorb latency spikes. When a popular resource expires, thousands of concurrent requests can trigger a thundering herd problem. With stale-while-revalidate, the edge node serves the stale cached copy to all requestors while sending a single background refresh to the origin, collapsing thousands of origin requests into one.

• Key benefit: Prevents origin overload during cache expiration events.
• Providers: Supported by Fastly, Cloudflare, Akamai, and Vercel.

In browser-based Progressive Web Apps, stale-while-revalidate is implemented via the Cache API within a service worker. The strategy intercepts fetch requests, immediately returns the cached response, and then updates the cache from the network for future visits. This provides an instant-first user experience.

• Workbox implementation: workbox.strategies.staleWhileRevalidate() from Google's Workbox library.
• Use case: Ideal for API responses and assets where showing slightly outdated data immediately is better than a loading spinner.

The critical architectural distinction that defines stale-while-revalidate. A synchronous refresh blocks the response until the origin confirms freshness, adding origin latency to every expired request. Background revalidation decouples serving from fetching: the stale response is returned in single-digit milliseconds from cache, while the refresh happens invisibly.

• Trade-off: Users may see slightly outdated content for one request cycle.
• Mitigation: Combine with short max-age values for frequently changing data.