At what stage do you compress/minimize javascript?

Question

When building, or "on the fly" (perhaps with caching) when the users request pages.

And what are the dis/advantages of each.

Answer 1

When the site moves from dev to the live server.

I always have an uncompressed version of the JS on the dev server and a minimized version on the live server.

The advantage of that is when developing i can run into JS trouble and fix it very simply, but i need to run each changed script through a minimizer, but for me its not that much.

Answer 2

When building or deploying to a stage environment is a good time to compress javascript. That way you will have a chance to test it in the stage environment and catch any errors that could occur.

Occasionally, there are errors that do come up when compressing. You may want to include a command-line version of jslint that runs before compressing, to make sure that the js passes. That will minimize, but not eliminate, all compression errors.

Answer 3

I'd imagine that on-the-fly would be an unnesessary unless you were adding dynamic data to the JavaScript (in which case there are better ways around it). IT's just a needless expenditure that will only slow down the page load.

Personally, I'd do so when deploying/building the app, it's a one-time thing really.

Answer 4

I'd say you have the js files as you'd code them in source control, when you kick off an automated build that's when, as part of your build script, it runs all the javascript files through a compressor. This way when you deploy it to a test / staging environment you've got the latest script but also compressed for performance testing and as they would be once they go to production.

Answer 5

I agree that on-the-fly is probably not really necessary (and eats up some cpu cycles) if the JS does not change.

There might be some middleware involved though which can check if the JS has changed and compress it only if requested (and maybe even group various JS files into one resulting one).

A good thing when deploying might also be to add some time stamp or random string as parameter to the JS link (e.g. .../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs). That way when the JS changes you use a different string and there will be no caching problems because it's a new URL. Same for CSS.