If the above is too funky for you, or there are too many pages to push at once – The next alternative is to enable the mod_expire extension in Apache. For the sake of performance, you might want to turn off these headers after some time, after most of the users have gotten the updated page. This will most likely cause the browser to reload everything on the page itself. Very important note – This page is now set to “no-cache, always reload”. On the page that you want to send the updated scripts, output the following HTTP headers: These examples are done in PHP and Apache, but there should be similar mechanisms in the other programming languages/webservers. Lastly, we can send some HTTP “no-cache” headers to encourage browsers to reload from the server. HTTP HEADERS – CACHE CONTROL & EXPIRES QUICK NOTES ON THIS METHOD It slows down the performance of your websites, just stick with changing the file name if possible. It really doesn’t do anything but fool the browsers into loading the script from the server every time.īut please take note that this is not a recommended practice in the long run, as browsers will not cache files with parameters. Yep, this is an old trick that we use – Just append a dummy timestamp behind the URL SCRIPT.JS?t=123456. We can quickly fall back to the older versions should something goes wrong, and check back on what has been changed over time. It is also a good practice to adopt versioning anyway. This is one of the easiest and most reliable ways to ensure that everyone is getting the latest version of the scripts – Simply change the file name, add a trailing version number behind the file name. If the system is already live, here are a few ways to remedy the situation. The script file if($('script').Of course, the above will only work for the developer. So, we found a way to load the newer version of the script each time user calls the original script
#CHROME FORCE REFRESH JS UPDATE#
We have been creating a SaaS for users and providing them a script to attach in their website page, and it was not possible to attach a version with the script as user will attach the script to their website for functionalities and i can't force them to change the version each time we update the script How are you ensuring clients update their cache when you update your code? If you're using the method described above, are you using a process that simplifies the change?
This definitely gets the job done, but updating the references on each release could get cumbersome.Īs I'm sure we're not the first ones to deal with this, I figured I would throw it out to the community. Our current thought is to simply attach a version number onto the name of the JavaScript files and then when changes are made, increment the version on the script and update all references. Obviously, on a support call, we can simply inform them to do a ctrl F5 refresh to ensure that they get the up-to-date files from the server, but it would be preferable to handle this before that time.
That being said, one issue we are running into is that after we push out an update with new JavaScript files, the client browsers still use the cached version of the file and they do not see the update.
We are currently working in a private beta and so are still in the process of making fairly rapid changes, although obviously as usage is starting to ramp up, we will be slowing down this process.