CSS compression and union / js minification - Better to do at runtime or at build time?

Question

I need to come up with a compression solution, a version (for caching purposes) and potentially combine our JS and CSS files, and so far I have seen two dominant approaches:

1) During build: as an MSBuild task or similar. 2) Dynamically at runtime: as a custom HTTPHandler (we are ASP.NET btw) for .js and .css files, something like this ends up on your pages:

<link rel="stylesheet" type="text/css" href="~/StyleSheetHandler.ashx?stylesheets=~stylesheets/master.css" /> 

Can anyone provide information about everyone's pro and con? Personally, I don’t see the point of doing it dynamically and wasting CPU cycles during each request (I think you would only do this with work for the first time, and then with the cache, but still), but I feel like I can do something lacks?

Thanks! Mark.

Answer 1

I think a good approach is to use different strategies for different environments:

• no compression for development (for development and debugging)
• runtime compression for the test environment (flexible, not performance critical)
• Compression of assembly time for production and production (verified, critical)

I have experience using a YUI compressor for both Javascript and CSS, and have learned (the hard way) that testing mini JS and CSS is really very important.

Creating static miniature JS and CSS files as part of your assembly for production has the following advantages:

• they are tested
• static files can be serviced without ASP.NET overhead
• can be cached by browser
• should be webserver-gzipped

Answer 2

The best way is to not do this at all, since all modern browsers and servers handle Gzip encoding. Look at the numbers:

• cfform.js - 21k
• cfform-minified.js - 12k
• cfform.js.gz - 4.2k
• cfform-minified.js.gz - 2.2k

This is a fairly large JS file with a lot of extra spaces, but in the final equation you saved a whopping 2k !! Not only that, but also due to the caching of this savings - per visitor, not per page. Whoo-hoo, now it was worth the whole problem, right?

You would save 10 times more by trimming the pixel width from the top of your banner, and 99% of your users on a broadband network you saved them about 1 millisecond of download time. Break the streamers and champagne!

JS compression is even worse since you just hit your customers with the decompression burden on EVERY PAGE. And savings after gzip are just as unhappy.

Seriously. The added complexity and debugging is not worth it if you are targeting the mobile market (and even this assumes that the users are still on CDMA and not 3G) or have a billion hits per day. Otherwise, just don’t worry.

Answer 3

I would say that it is better to do this from the first request and cache. the reason for this is that you can update css as needed in a readable format without returning to recovery. you can create your cache in the css file so that as soon as it changes, the cache is updated.

Josh

Answer 4

You do this at runtime, but only when you need to. This gives you maximum flexibility. This is especially a problem with PHP, which otherwise does not have a build step (i.e. you do not want to add it if you do not have it), but still a problem for other platforms.

At the risk of self-promotion, you can read the Javascript allowance in PHP and CSS injection in PHP , which describes problems, approaches, and best practices. The examples are in PHP, but the code itself is trivial. Questions and principles apply to any web platform.

Answer 5

I think you should do this at runtime, unless your CSS and JS files are really huge (over 1 MB). The browser cache can be forced by setting multiple http headers , and when you want your application to force a restart from the client side, just change the http parameter:

 <link rel="stylesheet" type="text/css" href="~/StyleSheetHandler.ashx?stylesheets=~stylesheets/master.css&token=1" /> 

You can change the token to force a reload of client-side CSS.