Versioning for fun and profit

When people come to your website, often the majority of the time that they’re waiting for the site to load is caused by the browser needing to download files from your server. “Things like images, javascript and css. “Even when they’re properly minified and compressed these things take time to download. “Also, each time someone requests a file, your server needs to respond to it: it needs to”establish the connection, render the content (image or text) then it needs to travel down the wire through all the different connections to the visitor’s browser. And without caching it has to do this same thing every time for every visitor for every page they visit.

So to fix this you set cache-control headers on your content that allows them to be cached in the various proxies and caches that are between your server and the visitor’s browser, and also in the browser itself. “This, however, introduces a conflict: performance vs freshness. “If you set your cache times too long, you will have to wait a long time for changes that you release to be updated for everyone, too short and you lose a lot of the benefit of caching.

So which should you choose, quickly updatable content or well cached and fast responses? Why not have both?“The way to achieve this is by versioning your static files. “Versioning at its most simple is just adding something to the url with which you reference the file that changes the url. Imagine you have an image http://www.yourawesomesite.com/banner.gif. “This will get stored in the various caches and proxies on the internet and in the visitor’s browser with that address. “If you change the banner.gif file to a different picture, visitors won’t see the change until the caches between them and your server all expire. “However, if in your HTML you refer to that image as"http://www.yourawesomesite.com/banner.gif?v=1, when you change the image you can update your HTML to http://www.yourawesomesite.com/banner.gif?v=2. This doesn’t matter to your server, it will still serve the image, it just ignores the ?v=2 querystring, but all the proxies and caches will now not have that url in their cache and will go and get the new file, and store the new files in their cache with the new url. This means you can have very long cache times set on your content, you don’t need them to expire because when the content changes so does the url.

Maintaining this versioning by hand for all the static content on your site can become unmanageable if there is a lot. Fortunately there are a number of different ways of managing this. You can add a version number in your automated build process, where it puts the build number into the version querystring. Or you can use the last modified date of the content and generate the url with code. A lot of CMS systems have features built in to do this for you as well, you should check the documentation for that.

But before you take the time to version all your content automatically you can just try it out manually on a few of your most expensive and most frequently changing resources. “Just add a version querystring to the url for the content and update it by hand when you change it. “Then set a really long cache time on that content, say a year, and you will see far less requests for the resource coming to your server and improved load times for your customers.