Last week, I talked about the benefits of and how you can test for stale-while-revalidate support (RFC 5861.) This week, I’ve done the testing for you.
The below table shows some content delivery networks (CDN) and to what degree they support RFC 5861. The selection of CDNs included is skewed towards low-cost providers, and providers with a free trial period. I hope to expand the table in the future.
| Provider | stale-if-error |
stale-while-revalidate |
Using HTTP | Async | Documented |
|---|---|---|---|---|---|
| Azure CDN | Supported | Yes | No | Yes | |
| BelugaCDN | Unsupported | No | |||
| BunnyCDN | |||||
| CDN77 | Supported | Yes | |||
| CDNSun | Unsupported | ||||
| Cloudflare | Supported | No | Yes | ||
| Fastly | Supported | ||||
| KeyCDN | |||||
| Google AMP Cache | |||||
Update (): Corrected table to reflect that Cloudflare does not support asynchronous background revalidation.
Update (): KeyCDN now supports asynchronous background revalidation.
Why asynchronous revalidation?
Azure CDN, Cloudflare, and KeyCDN support stale-if-error and stale-while-revalidate, but they don’t support asynchronous background revalidation of expired cached items. This means that the first visitor to request an expired resource from the cache has to wait while it’s being updated at the cost of latency.
Subsequent requests to the same resource while another request is busy updating it gets served a stale copy from the cache. This isn’t RFC 5861 compliant and as such is marked in orange in the table as some visitors will experience higher latency than other visitors as compared to a fully asynchronous implementation.
I can’t explain this any better than RFC 5861 itself:
The
stale-while-revalidateHTTP Cache-Control extension allows a cache to immediately return a stale response while it revalidates it in the background, thereby hiding latency (both in the network and on the server) from clients.
All but one of the providers included in the above table use either Varnish Cache or Nginx. Neither servers support stale-while-revalidate out-of-the box; it has to be enabled in configuration. As discussed last week, Nginx requires additional configuration to support asynchronous updates to the cache that only recently became available. The table would have looked very different just .
CDN providers that deploy Varnish Cache or Apache Traffic Server are more likely to have support for stale-while-revalidate with asynchronous updates. The feature have been available in the two servers since 2015 and 2014 respectively. Nginx only recently added support in .
No documentation? No support?
The only two things that sets Fastly apart from BunnyCDN and KeyCDN is that Fastly runs on Varnish Cache rather than Nginx, and that Fastly have stated publicly that they support RFC 5861.
If there isn’t any official documentation about the feature from a CDN provider, you also don’t have any indication of a commitment from them that it will continue to be supported. If it stops working some time in the future, it’s also less likely that they’ll prioritize fixing it again. You may have a harder time reaching out to customer support if anything goes wrong.
Update (): BunnyCDN have since disabled support for RFC 5861. Demonstrating my above point perfectly.
You should choose a CDN provider that has official documentation, or at the very least an official acknowledgment of the features your website relies upon. RFC 5861 is no exception to this rule of thumb, which is why I included this in information in the comparison table.
Update (): Cloudflare has been added to the table. It supports RFC 5861 even on its free tier, but only when the Origin Cache Control feature is enabled.
Update (): KeyCDN has been added to the table.
You can submit new CDN providers that are missing from the table using the below corrections link. I’ll review it and add it to the article. Please include any links to official documentation from the provider you wish to include.