Jorge Carvajal Hellsten // May 04 2018

Cache Busting

As I’m about to explain I saw a need for deeper understanding and knowledge about how to work with assets and how to fully benefit the local storage of browser caching. In this way we can easily optimize performance and reduce latency and network traffic. Especially with new or popular client side frameworks like React.js or Vue.js.

Problem

You know when you are developing locally and everything works. You update your Javascript(JS) and test it locally and everything just works. Then you deploy to stage and test and everything works there as well, but after deploy to production the client says that it doesn’t. This is probably because of that you didn’t cache bust your assets.
Normally in Drupal 8(D8), or any other common CMS tool, it will append a query string to your assets you are loading in with the

<link> or the <script>

-tags depending on the version number you have given it.

Cache Query String

This is not bad, this is how you tell the client(user browser) which version of the asset it should serve. And remember that browsers caches these files locally, on the users computer. And when you update your JS and everything looks good in you local computer, you will push your code and deploy it to the server. Your new asset is on the server but the client complains that ze (he or she) cannot see the new changes, this is because the client is loading the locally cached version of the file, because the browser doesn’t know that you have modified the file, it just sees that you are requesting the same asset that it has stored locally, and thus it will serve this.

“It just sees that you are requesting the same asset that it has stored locally, and thus it will serve this.”

Tell the client to clear their browser cache?

Should you tell the stakeholder to try to clear their browser cache so that ze will immediately see the changes. Is it enough? No. What about the other thousands of visitors who already has the assets stored locally. Are you gonna tell them too to clear their browser cache? Most likely not.

Now why can you see these changes locally?

Well, normally when we develop, we had set explicitly Chrome or whatever favourite develop browser you are using, to not to cache while your dev-tool is open.

Disable Cache While Dev Tool Is Open

This is convenient when you are constantly modifying scripts and assets locally for testing purposes. It gives you speed to see immediate changes while developing and testing your code.

Also in our developing environments we usually disable aggregation and caching in our

development.services.yml

CSS and JS aggregations

Why can’t we turn it off then? It’s cached by Varnish!

While you gain speed in local development you’ll lose performance and usability for your enduser who will have to fetch your assets from the server every time, thus also impacting on performance on the server which has to serve these every time instead of the browser serving it locally. For that reason we can’t only rely on server side caching, like Varnish or other server side caching solutions. For small sites this might not be a big of an impact, but imagine that you are serving a page for thousands of visitor, this will have a huge impact on performance on your server and bandwidth and what not. The client paying for the hosting has to pay bigger bills for bandwidth because of all the extra requests.

So what do we do then?

There are a couple of ways to handle this. Most easiest way is to just update your version number in your

MODULE_OR_THEME_NAME.libraries.yml

for D8 and

wp_enqueue_script

for WordPress. Commit it in your release branch which is going to be merged with your production code. As a suggestion you can update the version number to the date when you did the last change, in that way you’ll know when the JS was last updated only by looking for it in your network tab in the inspector OR you could add the git tag so you can easily see which release the asset belongs to. It is up to your development team to choose the convention you’d like to use for busting that cache.

Further reading:

Mozilla.org Web HTTP Caching
CSS-tricks Strategies for cache busting css
Keycdn – What is cache busting?
Varvy leverage browser caching

See also Google’s talk about performance:

Youtube: Google I/O 2013

 

Photo by Alexandre Debiève

This site uses cookies. A cookie is a small simple text file sent by a website that is stored on a computer, smartphone or tablet. We use cookies to remember your settings. They do not contain personal information. You can block cookies through browser settings, but bear in mind blocking may have a negative impact on site activity.

Close