Cashing In on Caching as a Frontend Engineer | by Sanjay Rajesh | Nov, 2022

Boost Your Website Performance By Learning Caching Policies

photo by shahadat rahman Feather unsplash

Modern JavaScript frameworks like React.js, Next.js etc. have advanced the end user and developer experience with a more modular, declarative development style. Virtual DOMS and deferring have helped optimize DOM manipulation.

But for the browser, painting the DOM is not the only concern. It also deals with files and network calls; A bunch of HTML, CSS, JS, fonts, images, etc. are used to build the page.

as Sam Thorogood talks in VideoFrontend engineers often focus on improvement Lighthouse Score, which mainly focuses on the first time loading experience of a website. We should also prioritize the second (or subsequent) load speed when users revisit the website. This is where caching and efficient caching policies come into picture.

Caching is the idea of ​​storing reusable data in a high-speed data storage layer, so it can be retrieved quickly to meet future requests.

If certain files don’t change frequently on a website, browsers can cache them so that they can be served faster for future requests and save a bunch of network calls. (and internet bill!)

“There are only two hard things in computer science: cache invalidation and naming things.” Phil Carlton

In this article, I want to share what I’ve learned about caching on the web.

Here’s a simplified approach to better understand the main players involved. Along with client-side caches, we also have shared caches implemented on proxy servers or CDNs that can be used by multiple clients.

browser cache and shared cache
browser cache and shared cache

Caching for a resource is done with the help of Cache-Control HTTP Headers. It contains both request and response instructions that tell the browser and shared cache how to access the resource (more on that later).

Here’s my Twitter profile page loading for the first time (or after emptying the cache and hard reloading). Inspect the Size and Time tabs.

Network tab of Chrome Dev Tools showing images on Twitter site on first load (without cache)
Network tab of Chrome Dev Tools shows image on Twitter site on first load (without cache)

Here this is the second time I am opening this. Note that the time is very short.

Network tab of Chrome Dev Tools showing images on Twitter site on second load (with disk cache)
Network tab of Chrome Dev Tools shows image on Twitter site on second load (with disk cache)

And here it is for every time I open it. It loads in 0 ms.

Images on Twitter site showing on network tab load of Chrome Dev Tools (from memory cache)
Network tab of Chrome Dev Tools shows images on Twitter site on load (from memory cache)

Items like the Twitter logo, icon, my profile banner, profile image, etc. don’t change often and are therefore cached.

But why is there a disk cache and a memory cache?

Google Chrome typically has four types of cache:

  1. Memory Cache: Memory cache is a short-term cache that stores all resources cached during the current document’s lifetime (nonpersistent). The resources stored here remain until the tab/session is closed. It is stored in memory.
  2. Disk Cache: Disk cache (HTTP cache) is a permanent cache that allows resources to be reused between sessions and sites. It is a disk-based cache.
  3. Service Worker Cache: Service worker has a cache API which we can use to control the cache and it is persistent. Service Worker is a JS file, which is a fundamental component of building PWAs (Progressive Web Apps).
  4. Push Cache: The push cache is where HTTP/2 push resources are stored. Pushing is a performance optimization technique where the server sends some resources to the browser before making the request. We won’t go into too much depth here as I’m also just figuring out how to use it (lemme know if you know more about push caching)

Read more about Here,

Comment: The service worker cache will only exist if a service worker is registered on the page.

Twitter’s JS files are loaded from Service worker cache. This is because Twitter Web App is a PWA, so it has a service worker registered.

Twitter site's JS files are cached in service worker cache
Twitter site’s JS files are cached in service worker cache

browser’s caching flow

According to web.dev, the browser follows the caching flow order when checking for a resource. The memory cache is present above the service worker cache (missing in the picture below).

browser's caching flow
browser’s caching flow

Let’s say you have a websiteindex.html , script.js And style.css , You want the item to be cached for a long time (like a year or more), but you’re also making changes to it script.js And style.css Deploy regularly. Since the name doesn’t change, users will be served files from the cache.

Cache busting is one way of dealing with this problem where we use versions or hashes in the file names so that the browser can load them and update the cache.

We will prevent browser from caching HTML file and loaded files either