This post was originally published at Using Immutable Caching To Speed Up The Web

When Firefox 49 shipped it contained the Cache-Control: Immutable feature to allow websites to hint which HTTP resources would never change. At almost the same time, Facebook began deploying the server side of this change widely. They use a URI versioning development model which works very well with immutable. This has made a significant impact on the performance of Facebook reloads with Firefox. It looks like other content providers will adopt it as well.

The benefits of immutable mean that when a page is refreshed, which is an extremely common social media scenario, elements that were previously marked immutable with an HTTP response header do not have to be revalidated with the server. Lacking this hint, the browser needs to guess which objects may or may not change on reload – wasting time on one hand or risking website incompatibility on the other.

For smaller objects, the work of this revalidation via a 304 HTTP response code can be almost as much work as just transferring the response fully.

It turns out this can save a lot of work. The page’s javascript, fonts, and stylesheets do not change between reloads. More importantly, the dozens of images do not change either – different images may be included by the markup, but the content of individual images do not change. Indeed, about the only thing that might change is the markup itself.

For Firefox users reloading Facebook content this has been a tremendous boon – the fastest request is one that is never made, and that is exactly what happens over and over again when refreshing a Facebook page. In my testing a typical feed may initially be comprised of 150 different resources. Pressing refresh in Firefox 49 generates just 25 network requests.


As you might imagine, this radically speeds things up. In my testing, it can often cut page reloading time in half. Facebook was also an early adopter of the brotli compression encoding. They use that to reduce the bandwidth usage of the dynamic markup, which cannot be cached, saving around 20% of the bytes transferred when compared to the older gzip standard. Brotli has been available in Firefox since Firefox 44.

Facebook’s servers are big winners too of course – a request never made saves bandwidth and CPU utilization which can in turn be spent on making the site faster for other requests.

“This change effectively eliminated revalidation requests to us from up-to-date versions of Firefox which, in many cases, can improve load times by seconds.” – Nathan Schloss, Software Engineer, Facebook


Facebook has been a great partner in this effort. Lately I’ve been spreading the word about immutable and other developers are adopting it too.

The BBC has picked it up on a trial basis:

Anecdotally, BBC sees reload times improve up to almost 50%, and finds 90% of requests are optimized away by immutable.

Implementations as future-looking as the InterPlanetary File System are interested too:

Also, products as venerable as the Squid proxy:


This has enough experience in the wild now to heartily recommend its use. To ensure adequate documentation it has also been adopted into the IETF on the Standards Track. All you need is a proper caching header to get started with your development.

See the original post:  

This post was originally published at Using Immutable Caching To Speed Up The Web