Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is it necessary to cache bust in HTTP/2?

Tags:

caching

http2

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?

like image 636
Jackson Avatar asked May 13 '16 01:05

Jackson


People also ask

Which HTTP request can be cached?

The POST response body can only be cached for subsequent GET requests to the same resource. Set the Location or Content-Location header in the POST response to communicate which resource the body represents. So the only technically valid way to cache a POST request, is for subsequent GETs to the same resource.

What is the purpose of cache busting?

Cache busting is a way to prevent browsers from caching your ad content. Cache busting adds a random string to your ad tag each time the tag fires — typically a random number. Because the tag has a different number each time, the browser sends a new request each time.

Should you cache HTML?

Do not cache HTML in the browser. Always set cache-control: no-store, no-cache before sending HTML response to the client-side. Embed fingerprints in the URL of static resources like image, JS, CSS, and font files. Safely cache static resources, i.e., images, JS, CSS, font files for a longer duration like six months.

Which HTTP caching header is used to avoid making requests to the origin server?

Expiration is the caching mechanism by which a client can entirely avoid making requests to the origin server. When the origin server specifies an explicit expiration time in the resource, a cache can check that expiration time and respond accordingly without having to contact the server first.


1 Answers

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

like image 77
dsign Avatar answered Oct 10 '22 20:10

dsign