0

We are in the early stages of developing an application, thus we are regularly releasing updates to the app to fix bugs or add new features. However, our users often accidentally run cached versions of the app instead of the most up-to-date version after a release. Our users are not technical and we can't step all of them through clearing their cache. Also, we do not want to set a no-cache because our app is rather large. From what I have seen on other SO posts programmatically clearing the cache is not an option. Any practical solutions?

Jon
  • 33
  • 2
  • 7
  • Not an answer, but you may find this useful: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en#validating-cached-responses-with-etags – Jefferey Cave Feb 05 '16 at 19:13
  • 1
    Possible duplicate of [Force browser to clear cache](http://stackoverflow.com/questions/1922910/force-browser-to-clear-cache) – Prusprus Feb 05 '16 at 19:16

2 Answers2

4

One trick is to place a different parameter in the URL. This should force the browser to download a new version.

For example:

<script src="main.js?version=1">

And: 

<script src="main.js?version=1.1">

And so on. Or even a longer random string, like a GUID, that should never repeat.

I'm not a huge fan of this approach myself, but it is quick and easy and common.

If you have full access to the expiry that your server sets on such files, and you know it's always going to be changing, you can tell the browser not to store its cached version for very long.

For example:

ExpiresByType text/javascript           "access plus 1 day"

Putting this in a .htaccess document on a server with the right permissions will tell the browser to only store a cached version of any JS for 24 hours.

Chuck Le Butt
  • 47,570
  • 62
  • 203
  • 289
  • The unique URLs are the safest way, I've tried etags and all other kinds of HTTP caching but it always seemed buggy in one browser or another, specially while developing. One option that I think is slightly better is to include a hash of the file in the URL, that way you can still cache some files if they haven't changed since the last build. – Ruan Mendes Feb 05 '16 at 19:21
  • I do this, generally with the current time since epoch. – dmgig Feb 05 '16 at 19:21
  • @dgig With the current time there will never be any caching. Probably not what the OP wants – Ruan Mendes Feb 05 '16 at 19:28
  • Ah yes true. I didn't realize this was for production. You're method, in that case, is very efficient and simple. – dmgig Feb 05 '16 at 19:32
2

Depends on your platform. Generally speaking, an effective strategy is to rewrite the URL used in any script includes in your HTML pages to include a hash of the files being referenced, appending said hash as a query string. This can be done as a build task.

So in your project, you might have an HTML file that has this:

<script type="text/javascript" src="js/myscript.js"></script>

Your post build task may scan this HTML and resolve the referenced js/myscript.js, create a hash of its contents, and rewrite it as js/myscript.js?v=[hash of js/myscript.js]. The query string is meaningless; it only acts as a cache buster for your browser.

You can use whatever value you want instead of the hash, such as a version (suggested in another answer), but I prefer a hash because it can be done independently of build labelling, can be done in place with simple tools when hotfixing/monkey patching a server, and files that have not changed can continue to be pulled from the browser cache.

Depending on your platform, there are a variety of ways to accomplish this task using existing tools. It's normally done as part of your bundling/minification task in a build process.

moribvndvs
  • 42,191
  • 11
  • 135
  • 149