Is it necessary to cache bust in HTTP/2?

Question

In HTTP/1, to avoid extra network requests that would determine if resources should remain cached, we would set a high max-age or Expires value on static assets, and give them a unique URL for each revision. But in HTTP/2, requests are cheap, so can we get by without cache-busting, and just rely on ETags, last-modified, et al?

The only advantage I can see with continuing to bust the cache (besides dually serving HTTP/1 and HTTP/2 clients) would be to save bandwidth checking if resources are out-of-date. And even that is probably going to be insignificant with HPACK. So am I missing something, or can I stop cache-busting now?

Defense

Answer 1

The "necessary" part depends on how extreme do you feel about performance. In short, if you can live with three or four round-trips cache busting is not required. Otherwise cache busting is still the only way to remove those.

Here are some arguments related to HTTP/2 vs HTTP/1.1, the issue of latency, and the use of HTTP/2 Push.

HTTP/2 requests are not instantaneous

• HTTP/2 requests are cheaper than HTTP/1.1, but not too much. In HTTP/1.1, once the browser opens the six to eight TCP connections to the server it has six to eight channels to do revalidations. In some scenarios of high TCP packet loss, high latency and especially at the beginning of the connections where TCP slow start is king, the many TCP sockets of HTTP/1.1 work better than a single HTTP/2 TCP connection. HTTP/2 is good, but not a silver bullet.

• HTTP/2 connections still have network latency. We have been averaging round-trip-time (RTT) for visitors to our site (It can be measured using HTTP/2 Ping) and because not everybody is in the same block that our server, our mean RTT is between 200 and 280 ms. A 304 revalidation will cost 1 RTT. In a site that doesn't use asset concatenation each new level of the asset tree will cost a further RTT.

HTTP/2 Push can save you as many RTTs as you want while working decently with the cache. But there are some issues, keep reading!

HTTP/2 Push works best with cache busting

The ideal scenario is that the server doesn't push fresh resources, but it pushes everything that has changed since the client's last visit.

• If a browser considers a resource fresh (e.g. because of max-age), it rejects or doesn't use any push for that resource. That makes impossible to refresh an asset that the browser considers fresh with HTTP/2 Push.

• Pushing 304 revalidations doesn't work due to a widespread bug in browsers. Those would be required with a small max-age.

Therefore, the only way of keeping RTTs to a minimum, not pushing anything that the browser already has and still being able to push a new version of an asset is to use cache busting, i.e, a new name or query parameter for new versions of assets.

See also

Url query parameters are still needed to update assets at clients

Interactions with the browser's cache

Prickle

Good answer. There's also the impact to consider on the server. 304s are cheap to generate for static resources but not free (and dynamic resources can be really expensive to continually regenerate). See interesting new feature from Firefox here: bitsup.blogspot.ie/2016/05/cache-control-immutable.html?m=1 as requested by Facebook to reduce both their server load as well as client side. – Thermel

Thanks for bringing this feature to my attention! I hope the other browsers also adopt this, it certainly makes sense to be able to mark assets as immutable with cache busting. – Prickle

@BazzaDP Interesting post. Although I wonder if the cost of 304s and the advantage of Cache-Control: immutable primarily applies to HTTP/1 servers. (I am guessing not, since Facebook seems to be using HTTP/2.) – Defense

As you state Facebook is HTTP/2 and this is only in latest version of Firefox (which also supports HTTP/2) so no I don't think so. However even if cost to client of making those 304 requests was zero (which it's not!) a server has to process and serve those 304s. This is especially costly to a site as popular as Facebook but yours as well. And there really is no benefit to serving that 304 each time someone hits refresh for some sources that will not change. That was my point and the post on immutable was just further confirmation of that. – Thermel