Caching and hashing

To strive for shortest load times you want to make all your CSS and JavaScript files and images to be highly cacheable. So you send all kinds of headers that tell the browser to cache these files forever and never ask them from server again. Great. Now your website is comparable to the speed of light. Your server almost has no load, your clients are happy... and then you need to make a change in one of those cached files.

Because the file is cached, it's not enough to just put up a new version of it. We explicitly ordered browsers to never ask for new versions of files. Sure, we could ask our clients to clear their browser cache and reload the page, but that's far from good user experience and besides - it doesn't neccessarily work either when the file happens to be cached by some intermediate proxy server. So the only really reliable way is to rename the file.

So you rename your my-app.js to my-app2.js and then to my-app3.js and so on... but that's getting tedious. Especially when you have a lot of files to keep track of and you want to deploy new versions of you website as often as possible. So you need to come up with some automated scheme for renaming your files in each build.

Here are some choices:

Version numbers


A simple and often implemented scheme. But with several drawbacks:

Build or revision numbers


That's a lot more automated and we can also use it for internal test-deploys. But the third problem still remains. Additionally this technique doesn't work when you either don't have a centralized build system or you don't have a version control system available to give you the revision number when you make the build.

File content checksums


Here each filename contains an MD5 hash of its contents. This ensures that filename changes only when it's content changes. Although we recalculate the hashes in each build, the files who's content didn't change will get the same hash they had before.

The only disadvantage I see is that it adds quite a bit to the length of filenames. But this seems easy to overcome. First of all it's not really the hash that's so long - it's only the hexadecimal representation of the 128-bit hash, that's so long. One could use base64-encoding to reduce the hash a bit:


You could also only include the first half of the hash:


This theoretically means entire 1 out of 264 chance of getting a collision - you are more likely to be killed by a meteorite.

Anyway. That's the technique I have chosen to implement for SeeMe. Hopefully it will work just as fine in practice as in my theory.

Kirjutatud 18. jaanuaril 2010.


Eesti Trinoloogide Maja. Eesti trinoloogiahuviliste avalik kogunemiskoht.


Samal teemal

RSS, RSS kommentaarid, XHTML, CSS, AA