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 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: 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
  2. Browser loads the full jQuery file from
  3. Visit SITE2, which also loads jQuery from
  4. Browser has a cache hit for jquery, meaning it doesn’t need to load jQuery from 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

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 you’ll notice this has been marked as a security issue.


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.

5 replies on “Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache”

Locally hosting my web fonts and then getting them working w/ http/2 push via Litespeed had a big impact when I was optimising my site.

Monirul Islam Monir – I’d recommend serving them from the site domain as your site.

This is good to know, I have been moving more resources to load locally when possible to get a patter PageSpeed score but was wondering if it was doing more harm than good since common resources would have to be reloaded. Turns out it may be that way soon anyway.

Benjamin – even more this I think people would commonly over estimate cache hits across sites, with this, it seals the deal.

Leave a Reply

Your email address will not be published. Required fields are marked *