It has long been conventional wisdom that if your website uses a third-party library, such as jQuery or Bootstrap, you should load it from the library's high-performance CDN. For example, jQuery has
code.jquery.com
from which you can include any version of jQuery on your website, e.g.:
<script src="https://code.jquery.com/jquery-3.3.1.min.js"
integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8="
crossorigin="anonymous"></script>
This was meant to give you two performance benefits: the browser could load jQuery from a global CDN, AND if another site the visitor had already opened included the same jQuery file in the same way, the file might already be in their browser cache. In that case the browser could reuse the cached copy and the page would load faster.
In practice, website visitors rarely see much benefit. The browser still has to open a separate connection to the third-party CDN, which can cancel out any latency advantage the CDN provides. There are also so many versions of major libraries in use that the chance of two websites using the same version, AND both loading it from the CDN in the same way, is small.
Cache Partitioning in Chrome and Firefox
Until recently, Chrome and Firefox used a shared browser cache for all websites that a user visited. This means that if you visited a website and it loaded this resource:
https://www.somesite.com/foo.js
and you then visited a second website that included the same resource, the resource would be loaded from the shared cache rather than being downloaded from the internet a second time. Cookies set by these resources would also be shared.
As of Firefox v85 and Chrome v86, the browser cache will be partitioned. This means that the same resource included on two sites will have to be downloaded from the internet twice and stored separately.
Why are they doing this?
The main reason is privacy. Shared browser caches have been used by unscrupulous operators to track users across different websites without consent. They do this by utilising cache side-channel attacks.
What Are Side Channel Attacks?
In computer systems, a program or algorithm can be correct and secure in itself, while its interaction with the computer still leaves information that an attacker can exploit. A useful analogy from the spy world is using a laser beam to measure the vibrations on a pane of glass, so you can hear a conversation inside a room that you otherwise could not hear.
Side-channel attacks can be ingenious, utilising techniques such as:
- observing power consumption/electromagnetic radiation;
- timing data moving in and out of memory;
- timing how long a CPU takes to execute an instruction;
- measuring sounds emitted by a hard drive.
For the browser cache, a simple attack starts with the user opening a malicious website. That website then requests resources (e.g., an image) from another site. By timing how long the browser takes to load that image, it can determine whether it was fetched from the browser cache or had to be downloaded over the internet. According to Google, this technique can be used to:
- Detect if a user has visited a specific site.
- Detect if an arbitrary string is in the user's search results by checking for 'no search result' images used by particular sites.
- Track users across sites using the cache.
GitHub user terjanq has published a cache side channel attack that can gather all sorts of information from Google services. He states that a regular Google user could have the following information leaked:
- search history
- videos watched
- the exact URLs visited
- time frames of the activities
- private book collection
- books read / purchased / bookmarked / favourite / etc.
- private emails
- tokens / credit card numbers / phone numbers / etc.
- contacts (including email addresses, names, phone numbers)
- bookmarked websites
- and more.
Perhaps it was simpler to implement cache partitioning in Chrome than to keep patching these vulnerabilities...
What you should do
Google estimates that the changes in browser caching will have minimal impact, as little as a 0.3% difference in FCP (First Contentful Paint). However, since there will no longer be any shared-cache benefit from hosting on a third-party CDN, you should:
- Host all third-party libraries on your own domain to eliminate the need for the browser to establish a second connection.
- Utilise a modern CDN, like Peakhour, which transparently caches and serves your website assets on its global CDN.
Conclusion
Some third-party resources really are shared across millions of websites. Google Fonts is the obvious example. Under the new cache partitioning implementations, these fonts will have to be downloaded for every site that uses them. That has a cost for site speed and data usage. It also has the side effect of improving Google's ability to track users, because each font request tells Google another site the user has visited.
Safari has been partitioning the HTTP cache since 2013, leaving Microsoft's Edge as the last major browser with global HTTP caches. However, future versions will be based on Chromium (the open-source version of Chrome) so should get cache partitioning by default.
