Simple Client-side Technique

In general, caching is good.. So there are a couple of techniques, depending on whether you’re fixing the problem for yourself as you develop a website, or whether you’re trying to control cache in a production environment.

General visitors to your website won’t have the same experience that you’re having when you’re developing the site. Since the average visitor comes to the site less frequently (maybe only a few times each month, unless you’re a Google or hi5 Networks), then they are less likely to have your files in cache, and that may be enough. If you want to force a new version into the browser, you can always add a query string to the request, and bump up the version number when you make major changes:

<script src="/myJavascript.js?version=4"></script>

This will ensure that everyone gets the new file. It works because the browser looks at the URL of the file to determine whether it has a copy in cache. If your server isn’t set up to do anything with the query string, it will be ignored, but the name will look like a new file to the browser.

On the other hand, if you’re developing a website, you don’t want to change the version number every time you save a change to your development version. That would be tedious.

So while you’re developing your site, a good trick would be to automatically generate a query string parameter:

<!-- Development version: -->
<script>document.write('<script src="/myJavascript.js?dev=' + Math.floor(Math.random() * 100) + '"\><\/script>');</script>

Adding a query string to the request is a good way to version a resource, but for a simple website this may be unnecessary. And remember, caching is a good thing.

It’s also worth noting that the browser isn’t necessarily stingy about keeping files in cache. Browsers have policies for this sort of thing, and they are usually playing by the rules laid down in the HTTP specification. When a browser makes a request to a server, part of the response is an EXPIRES header.. a date which tells the browser how long it should be kept in cache. The next time the browser comes across a request for the same file, it sees that it has a copy in cache and looks to the EXPIRES date to decide whether it should be used.

So believe it or not, it’s actually your server that is making that browser cache so persistent. You could adjust your server settings and change the EXPIRES headers, but the little technique I’ve written above is probably a much simpler way for you to go about it. Since caching is good, you usually want to set that date far into the future (a “Far-future Expires Header”), and use the technique described above to force a change.

If you’re interested in more info on HTTP or how these requests are made, a good book is “High Performance Web Sites” by Steve Souders. It’s a very good introduction to the subject.