Javascript and CSS file versioning

Lately, I was in conversation with our QA lead, which made us realize of an issue that, certainly will cause inconvenience to the end users of the web application on which we are working on. Although the issue is very much common and is to be faced by all web developers, though it came late to me, I would defend myself by saying, ‘better late than never’.

Now the problem,

Our web application relies heavily on javascript and css and we follow a rapid release cycles. Each release adds a whole bunch of new features and modifications. Hence a lot of changes to the same old javascript and css files. After a rigorous testing the product goes live for the end users. Now there will surely users telling the current released is buggy and everything on a page breaks. But wait a minute, why this would happen as all went fine during testing. Oh yes, but did we notify the end users browser that our so and so js and cs files have changed and it needs to get a fresh copy of it for the things to work properly. Of course we didn’t, so what to do, tell the end user to clear the cache(CTRL+F5), so that it makes browser to get fresh copy of all files, well isn’t this annoying.

The solution,

Well we can think of browser caching to be the culprit, but getting rid of that will impact page performance. Every time the page request is made, the browser will pull the same js and cs files. Or, we can think of expiring the files at some particular date in future. We can implement this both at page level or at server level.

For IIS 7,

1. In “Features View”, double-click “HTTP Response Headers”.
2. On the “HTTP Response Headers” page, in the “Actions” pane, click “Set Common Headers”.
3. In the “Set Common HTTP Response Headers” dialog box, select the “Expire Web content” check box and select one of the following options:
   • Select “Immediately” if you want content to expire immediately after it is sent in a response, that is no caching.
   • Select “After” if you want the content to expire periodically. Then, in the corresponding boxes, type an integer and select a time interval at which content expires.
   • Select “On (in Coordinated Universal Time (UTC))” if you want the content to expire on a specific day and at a specific time. Then, in the corresponding boxes, select a date and time at which the content expires.

This solution will work pretty well. But, how about mixing both the solutions. Letting the user’s get the new files when they are ready and the same time leverage the cache option also. We can achieve that in two ways:

• Either we can add the SVN version number / build number as query string.

<link type="text/css" rel="stylesheet" href="css/base.css?v=000">

The trick over here is, to change the number each time you update the CSS file to make sure the browser always downloads the new code. When a browser checks if it has anything cached it compares the file names. Now as browser will treat “base.css?v=000″ and “base.css?v=001″ differently, so it will download the new CSS file.

• Or, we can make the SVN version number / build number as part of the file name itself.

<link type="text/css" rel="stylesheet" href="css/base_000.css">

I prefer the later one, to be sure enough that the files are getting cached. As, although I don’t have the list of proxies, but have read, that a certain proxies do ignore the query string part of the url.
CodeProject