Revenir au blog

Follow and Subscribe

Disponible uniquement en anglais

Cette page n'est actuellement disponible qu'en anglais. Nous nous excusons pour la gêne occasionnée, merci de revenir sur cette page ultérieurement.

Stale-While-Revalidate, Stale-If-Error Available Today

Steve Souders

Chief Performance Officer

Fastly is excited to announce that as of today, we support stale-while-revalidate and stale-if-error. As a company dedicated to building a better Internet, we work hard to identify and support new standards that move the Web forward. Read on for an explanation of how these Cache-Control extensions make the Web faster and more reliable for browsers and CDNs, and check out documentation of these features.

Even Faster Caching

We've all experienced slow websites, especially on mobile devices. Much of this slowdown is due to network delays from fetching the images, scripts, stylesheets, and other resources needed by the page. Caching makes pages load faster by using a previous copy of a response rather than re-fetching it over the network. Resources get cached when you specify a Cache-Control response header. This example indicates that the response can be served from cache for one week:

Cache-Control: max-age=604800

For the next week the page is faster because the resource is read from cache, but after 604800 seconds have passed the cache will re-fetch the requested content, causing the page to load slower. This slowdown can be avoided by using stale-while-revalidate:

Cache-Control: max-age=604800, stale-while-revalidate=86400

By adding stale-while-revalidate we've told the cache that it can use the current (stale) version for up to one day while it re-fetches the latest version in the background. This achieves both of the goals that we're after: providing users with faster pages and keeping cached resources up-to-date, only now the updates are done in the background without having a negative impact on the user experience.

Avoiding Broken Pages

Re-fetching resources makes pages slower, but response errors result in broken pages which is an even worse user experience. This is where stale-if-error comes to the rescue. This example tells the cache that if the re-fetch fails within three days of the response becoming stale, then the cached response should be used.

Cache-Control: max-age=604800,
stale-while-revalidate=86400, stale-if-error=259200

This makes web pages more resilient. It's often acceptable to use a stale version of resources, for example, website graphics and stable JavaScript libraries, and the stale version is much preferred to a broken user experience.

Better Standards, Better Web

Stale-while-revalidate and stale-if-error are a win for browsers and CDNs. The benefits that produce faster and more reliable pages in the browser have the same benefits for the CDN’s cache. By specifying stale-while-revalidate, users aren't slowed down when a response cached at the CDN needs to be revalidated. If there's an issue at the origin server, stale-if-error lets users proceed without experiencing broken pages.

This feature is available worldwide today. To see these extensions in action, take a look at the Cache-Control response header for the new Polyfill Service from Financial Times:

Cache-Control:public, max-age=86400,
stale-while-revalidate=604800, stale-if-error=604800

Stale-while-revalidate and stale-if-error are also a proposed industry standard, meaning website owners aren't locked in to vendor-specific solutions.

As these cache extensions get adopted by browsers, users receive an additional performance boost. (Development is currently ongoing in Chrome.) By getting out in front of this emerging standard, Fastly customers can see the benefits today in their CDN and will get the browser benefits without having to do any additional work. This is the beauty of industry standards — they benefit website owners across vendors and levels of the stack. We like that.