Cache Busting for A More Performant, Usable Web

Caching is good for web performance, but it can also create a problem when updating or changing files. Patrick introduces a tool that enables updates to still happen when using web caching.

A website contains a lot of files—JavaScript, CSS, HTML, and images—that your web browser must download before it can be displayed. If you had to get those files from the web server every time you refreshed the page or clicked a hyperlink, your browser would have to redownload all those files every time, wasting bandwidth and increasing the time it takes to load the webpage.

This is where cache comes into play. Your browser caches, or stores, all these files on your computer so it doesn’t have to redownload them every time you refresh. Those files are saved (cached) just once—the first time you visit the website. As Daniel noted in his Foundry article “Performance During Development,” caching improves web performance.

Though caching is good for web performance, it can also create a problem. If we “cache” those files, how do we update them when they are changed? Say we want to add a new font or change the color of a webpage’s background. If the CSS file is cached, that visitor would never see that update. If caches expire after a day or so, then users are left with old versions of the website files until the cache time expires.

Solution: Cache Busting

Cache busting is a way for updates to still happen when using web caching. If a file is “stored forever” on a visitor’s computer, we as developers must have a way to update that file at some point in the future. If we use cache busting, we simply get the updated file out for everyone (recache it) and the website is now the same (updated) for everyone! A few years ago, we wrote a cachebusting utility that used grunt and old node libraries. This, however, was in dire need of an update.

Introducing the cachebust: A straightforward asset fingerprinting “cachebuster” for production applications.

Here are instructions on how to install cachebust:

npm install @sparkbox/cachebust

We recommend adding the cachebust configuration to your package.json file:

{
 ...
 "cachebust": {
     "source": [
         "path/to/source/css/style.css",
         "path/to/source/js/script.js"
     ],
     "target": [
         "path/to/target/template.html"
     ]
 }
 ...
}

After adding this to your package.json file, running npm run cachebust in the root directory of your project will bust your website cache.

We also recommend you run cachebust only once on your production server (after the deployment step). Each time you deploy a “new” version of the styles or scripts on your website, a new copy of these files are pushed, and running cachebust on your production server will generate new “hashed” versions of your files.

To help, add cachebust on your production build task in your package.json.

"scripts": {

"build:prod": "... && npm run cachebust"

}

To try this locally, you can run npm run cachebust and verify that the files have been modified, and then run npm run cachebust:restore, which will return your files back to their original state.

How Cachebust Works

What cachebust does is change the name of the file so the browser believes it is a completely different file, which, technically, it is since it’s an updated file.

We add a “hash” to the file, so that styles.css becomes styles-66bb1e.css in which the hash (66bb1e) would be generated based on file contents. That means that if there is a single difference in the file, it will have a completely different hash.

The commonality is the HTTP headers being sent back from the web server. You can read more about HTTP headers for cache control on the MDN Web Docs platform.

Your web server is telling the browsers what to do with the files it downloads. Apache allows us to cache using something called an .htaccess file. Typically, a header is set by the webserver, in this case Apache, which tells the browser that our file is to be cached. The line ExpiresByType application/javascript "access plus 1 year" tells the browser to store that file, at access time, for one year. It will not ask for a new version of this file for an entire year.

Remember, this is based on filenames, so if that filename were using cache busting (scripts-66bb1e.js) and the name were changed, it’s now downloaded, cache busted!

For A Performant Web

Browser caching is important to a fast and performant web, and with cache busting you can be sure you can get both performance and the most recently updated files you’ve developed for your users. To learn more about browser cache with Apache web servers, this H5BP GitHib resource is a great starting, as is this configuration for nginx.