How to deploy minified Javascript files to a web server without changing the file's Timestamp?

Question

We have several hundred javascript files in our app that are currently being served uncompressed. One piece of our solution to gain a little more client performance is to minify our javascript files. I've created an automated solution to do this on the build, however, when these new files are deployed, the files' timestamp that determines if it will be resent to the client will be changed. This means, that on every future release, all the javascript files will have a new timestamp. our clients will redownload ALL the minified javascript files again, and thus defeating the performance aspect of minification.

Is this an issue anyone else has encountered? What was your solution? Do you have seperate non-minified and minified javascript files used in your projects, and don't perform the minification on the build?

We have other solutions in mind (like only looking for the actual changed files in the source control repository), but this is one question for which I wanted to find out what others are doing.

Answer 1

You are going to have to determine which files have actually changed. Or just don't worry about it and enjoy the improvement you gain with the minified files. Clients may not hold the files in cache for very long anyway, so unless you're updating the files very, very frequently, there is likely to be little gain with trying to manage the caching behavior.

Answer 2

You could roll these script files out over a period of time so that no single user request takes an inordinately long time. But seriously, how much javascript are we talking about? Is a one-time re-download of the script associated with your page really that big a deal? Think of how much effort you're going to have to go through to get this done and weigh that against the benefit.

Answer 3

You could write a script that checks the CRC or MD5 hash of each file from the source and target folders, and only perform the overwrite if the file has changed. This would preserve the timestamps for files which have not changed, giving you the desired caching behaviour.

Similarly, you could record the previous timestamp, do the overwrite, then use the touch command (assuming these files are on a unix system) to set the timestamp back to it's original value.

The first option is probably better rather than just blindly setting the timestamp to the same value all the time, because that might mean that some clients don't pick up a modified JS file for a while because the server claims it hasn't changed.

Answer 4

Have a read of http://www.thinkvitamin.com/features/webapps/serving-javascript-fast by Cal Henderson of Flickr fame. Hopefully you will find it useful.