I am currently building a Web application using a LAMP stack that relies on Javascript on the front end. As the app grows and expands, I naturally plan to expand and change the javascript files. I'm concerned that many of our users' computers will cache the files (which I usually want) but I want to be proactive to make sure that new files are grabbed when I update.

The obvious answer seems to version the javascript files throughout the application so that edit.js become edit.0.3.6.js and can be updated whenever the file changes so a new version is downloaded.

I think that this is the most fail-proof method, but I question if there is an easy way to manage these versioning changes automatically. We use Github to version control all our files.

  • Why not use the built in mechanisms of the HTTP protocol to force a cache refresh? Jun 7, 2013 at 20:31
  • 1
    @BenjaminGruenbaum: Probably because in the time between when the new version is up and when the caches update, the site may very well appear broken to whoever's pulling stuff from that cache...?
    – cHao
    Jun 7, 2013 at 20:34
  • @cHao It's possible in the HTTP protocol to respond to a request with a 304 "Not Changed" header, this means we're still checking with the server if the page has updated but not downloading the page again. This is all part of the protocol. Jun 7, 2013 at 23:52
  • @cHao that is the idea. Jun 8, 2013 at 0:50
  • 1
    Here is the official information from the actual protocol specification. I think this is also a pretty solid tutorial . Good luck! Jun 8, 2013 at 0:59

1 Answer 1


Another way to version javascript, CSS and other such files (say background images), is to add a parameter on the URL that they link to - for example edit.js?ver=1.

When the version changes, you update the parameter - ver=2. This ensures that it will be re-fetched.

An added bonus is that you can easily search for ?ver= in your source code and possibly do a global replace.

  • This works and I've used it. Although it doesn't really answer the question at all. I'm not sure how one would do what he wants, but I want to know too.
    – DJSpud
    Jun 7, 2013 at 20:29
  • C-C-C-Cache Breaker!!! This 'hack' Works well. I'd argue it does solve OP's issue, at least partially. I'd love to see a protocol level solution too though. Jun 7, 2013 at 20:34
  • I'd also say it entirely solves the OP issue, and that "versioning" here isn't needed (and was a side-effect of what OP wanted to achieve, which was to make sure that the newer versions would be available to clients without cache issues). That works just fine, and it's quite common to see it done in a slightly brutal way using random numbers or time in milliseconds (which can lead to the most obscure heisenbugs you'll never be able to reproduce...).
    – haylem
    Jun 7, 2013 at 23:29
  • This is a good idea and solves confusing Github with file names changing all the time. I have used a similar solution with timestamps as well on AJAX requests, but this is definitely nicer and allows some caching (which I want). My only reservation remaining is if there is a possibility to automate this, since it seems likely that we will forget to do that global search and replace. Though that would likely either take a decent bit of custom code or protocol level solution, I'm guessing. Jun 8, 2013 at 0:57
  • @DavidF - Depending on your build system, running a script on all source files that does a global search and replace for a specific ver=xxx is not difficult to automate.
    – Oded
    Jun 8, 2013 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.