CSS Minification on the Fly

http://shinylittlething.com/2010/01/20/css-minification-on-the-fly/

by ncrovatti • 17 years ago

26 14 17 years ago

jeff182• 17 years ago

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.

olliesaunders• 17 years ago

What percentage of a CSS is machine-ignored whitespace? I'm willing to bet it's quite a bit more than 0.003%.

Edit: Here's a real world case. HN's news.css is 1779 bytes, 225 of those can be removed, that's 14.3%.

cwisecarver• 17 years ago

But after gzipping most of that whitespace will be gone anyway.

jeff182• 17 years ago

I was talking about the whole page itself -- I hope no one actually has a 300 kilobyte CSS file. ;)

My point is that it sounds impressive to say "Hacker News can cut down its CSS file by 14.3%"... however in the real world, shaving 225 bytes off of a single file (actually even less after gzipping) will not improve page-loading by more than a millisecond.

geuis2• 17 years ago

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.

mgrouchy2• 17 years ago

I think using css sprites is definitely a great technique. But I always find managing sprites a bit hard to manage.

Any tips for making managing sprites easier on developers/designers? Any tools in your toolbox?

tortilla• 17 years ago

I'm using auto_sprite (Rails) in my current project. Works pretty well.

http://fargle.org/auto_sprite/

geuis2• 17 years ago

No tools that I can recommend. Sigh I recommend sprites(I use them all the time) but I have been doing them so long directly in Photoshop that's my default action, especially when in a hurry. I have tried a few tools but found they are very inaccurate.

ncrovatti2• 16 years ago

I made a tool for this : http://css-sprit.es

est• 17 years ago

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

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

mark_h• 17 years ago

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.

ncrovatti2• 16 years ago

Thanks, it's nice to know since I was about to do something similar for django too.

sync• 16 years ago

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

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

CSS Minification on the Fly

Related Stories