Is it necessary to cache bust in HTTP/2?

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?

标签： caching http2

1条回答

老娘就宠你

2楼-- · 2019-05-09 10:36

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.