Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache

Traditionally one of the advantages of loading web fonts from Google Fonts was that you’d potentially benefit from it already being in the browser cache from another site the user had previously visited. The concept is the same for any centrally loaded resource, services like cdnjs.com have popped up for exactly this reason.

All of that is about to change very soon for Chrome, the most popular browser in the world ( by a long shot, it isn’t even close, though you might be surprised who is the #2 position ). The important reference for this is: https://chromestatus.com/feature/5730772021411840 – Partition the HTTP Cache.

Here is the summary:

The HTTP cache is currently one per profile, with a single namespace for all resources and subresources regardless of origin or renderer process. Splitting the cache on top frame origins helps the browser deflect side-channel attacks where one site can detect resources in another site’s cache.

What This Means

Here is a simplified example of what currently happens:

1. Visiting SITE1 that loads jQuery from https://code.jquery.com/jquery-3.4.1.min.js
2. Browser loads the full jQuery file from https://code.jquery.com/jquery-3.4.1.min.js
3. Visit SITE2, which also loads jQuery from https://code.jquery.com/jquery-3.4.1.min.js
4. Browser has a cache hit for jquery, meaning it doesn’t need to load jQuery from code.jquery.com because it is already in the local cache

After this change is live, that visit to SITE2 will no longer result in a cache hit. It will still have to download the full resource from code.jquery.com.

This is potentially a big performance hit, so why is Chrome making this change?

Well, it turns out the details about cache hits can lead to information leakage. The most obvious one being, using the example above, is that SITE2 would be able to determine that a user had previously visited SITE1. Meaning sites can use this to track you across the web. Yes, this is yet another way your privacy may be at risk.

If you check out https://chromestatus.com/feature/5730772021411840 you’ll notice this has been marked as a security issue.

Implications

The biggest one is that using the argument that loading a common resource from a single source ( Google Fonts, jQuery, etc. ) because you believe that you’ll be more likely to get a cache hit is going out the window.

With HTTP/2 I’ve been generally advocating for more locally hosted resources anyway ( like web fonts ), the reason being that the cost of a new HTTP connection, even it a large CDN like Google, often takes more time than making another request on an existing connection. Don’t forget that those new connections can come with additional time for DNS, TCP, and HTTPS.

In the not too distant future this is going to be the reality we have to deal with.

What About Other Browsers

Chrome isn’t the only one to go done this road. It might not surprise you that Safari has been doing this for years. Firefox is also considering it.