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 (CDNs) 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.
Why asynchronous revalidation?
While both Azure CDN and KeyCDN support both stale-if-error and stale-while-revalidate, neither 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 is not 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:
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.
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.
You can submit new CDN providers that are missing from the table. I’ll review it and add it to the article. Please include any links to official documentation from the provider you wish to include.