Jorge Carvajal Hellsten // May 04 2018
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.
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.
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.
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
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
for D8 and
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.
See also Google’s talk about performance:
Photo by Alexandre Debiève