Skip to main content

Command Palette

Search for a command to run...

Google drops shared resource-cache

Published
2 min read
Google drops shared resource-cache
M

Hi, I'm Marco, Engineering Manager and a Lead developer with experience building and managing product-focused teams. My tasks include handling the engineering team delivering on time and with quality code, helping them grow in their role and guiding them towards their career goals. As a developer, I work extensively with JavaScript front and back (Vue, React and node) and other modern technologies (SCSS, GraphQL, NoSQL DBs, CD/CI, unit and e2e testing, development experience, etc.).Mentoring and teaching developers to grow and learn is a big part of my job and personal mission. Furthermore, I like seeking new technologies and staying up-to-date on industry trends and advancements. In addition to my roles as a front-end and engineering manager, I have often served as a Scrum Master, helping companies introduce an agile methodology or improve the existing one.

Starting with Chrome 86, Google has decided to remove a feature often leveraged by frontend developers: shared resource-cache. If you are not entirely sure of what it is, let me help you.

Let's take as an example Roboto font referenced from google font. Roboto is a very famous font and is used on the vast majority of material design websites and applications. Until now you were able to download this font once from the first visited website and then use the same cached version for every identical HTTP call even if coming from an entirely different domain or application. This feature is called shared resource-cache and is going to be rarer by the day.

Now that Chrome is joining Safari on this change, and that Edge has become Chromium-based, we are going to have the vast majority of browsers that don't support it anymore. Only Firefox is holding on for now.

Browser market share

Why are they changing this feature? The response is simple, privacy and security. This technique is allowing dodgy ways to track the users' history by sampling what is in their cache. For example, if a website calls Netflix font and obtains a fast response, knows that the user has been visiting Netflix lately because the font is cached in the browser. It is possible to trace down every kind of website using this method, including Twitter, Facebook, etc. If the website leaves a footprint, and almost every single one does, can be somewhat traced down, and it is a massive hole in privacy for the final user.

And now what are the effects of this change? The main effect is more privacy by breaking these tracking techniques. Still, the collateral effect is that from now on, users have to download the same resource for every single website they are visiting instead of being able to use what they have in the cache already. This change will result in longer loading times and TTI (Time To Interactive) significantly affecting all developers focussing on website/app performance. If your KPI revolves around performances, keep an eye on HTTP requests and how to change them based on this change.

Source: Google Developers

More from this blog