CSS Minification on the Fly

For django, I've been using django-compress: http://code.google.com/p/django-compress/

Works with javascript as well as CSS, nicely incorporates cache control, ahead-of-time or on-the-fly generation, etc. Works out of the box* in pure python, or it's trivial to plug eg YUI minifier or google-closure.

* Actually, last I looked there was a bug in the CSS minifier it ships with (http://code.google.com/p/django-compress/issues/detail?id=27), but I believe the upstream version has been fixed.

Hmm, I think this is an example of an unnecessary optimization. After gzipping, minifying a CSS file might cut your website from like 300k to 299k.

On the other hand, if this guy combined his CSS files into a single file, he would reduce several HTTP requests which would actually provide a noticeable difference.

We have several raw stylesheets that are full of documentation in the form of css comments. We run these through CSSTidy before concating them all into one file. CSSTidy, while a few years old, does a reasonable job of cleaning out a lot of the cruft that we need internally but don't want to deliver to the end user.

You should not be doing any kind of minification or cleanup on your css & js during the page request. These need to be done during your build process and cached on a CDN, or at least as a static file somewhere.

Edit As a further note, here's a short list of things to do before deploying css, images, and javascript live.

css/javascript/images should be considered static. Unless you're running a specialized application, these are resources that require no modification from one page request to the next. css & javascript are text files. Images are binary formats.

1) Minify css & javascript. If you have multiple stylesheets internally on your dev environment that you use for purposes of keeping code separated, but all the code ends up being used on all your pages, combine them together into 1 file. The same thing for javascript files. 2) Compress images. There are a number image compression techniques. Most of these are accessory applications that are run during deployment. They take your original images and create optimized versions that are smaller but same dimensions. The images are then stored elsewhere and don't affect the originals.

3) Images come in 2 varieties: Style and content. When and where possible, images used for Style should be turned into background sprites. Multiple images in one file can be moved around with css to achieve different affects. Content images tend to be more dynamic (imagine a news site with lots of new pictures each day). These images should be optimized but can't easily be sprited the same way background images can.

4) Serve static content (ie css/js/style images) from a server that does NOT pass cookies. Cookies are extra bandwidth that you don't need to transfer for things like this. So say you have www.mysite.com. Serve your static resources from a non-cookie subdomain like static.mysite.com.

5) Use multiple subdomains to serve static resources. Modern browsers allow something like 6 simultaneous connections to the same domain on average. So if you have a lot of stuff on your page (like a news or photo site), you can get a big performance boost by loading your static stuff from static1.mysite.com, static2.mysite.com, static3.mysite.com, etc. The technique I have used to good effect is a 'round robin'. During my build process, I do a search and replace on my default path variable {csspath} in my stylesheets. I rotate the replacement through each sub-domain. As the browser is loading the content of the page, its doing many more simultaneous requests. Each sub-domain is loading from the same place.

This is why websites is 'compiled', not written, in the future.

Other tools like Closure Compiler, CSS Sprites make it happen.

For rails, Sass ( http://sass-lang.com/ ) has a nice setting for doing this:

  Sass::Plugin.options = {
    :style => :compressed
  }