
CSS Minification on the Fly - ncrovatti
http://shinylittlething.com/2010/01/20/css-minification-on-the-fly/
======
mark_h
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.

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

------
jeff18
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
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
But after gzipping most of that whitespace will be gone anyway.

------
geuis
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.

~~~
mgrouchy
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?

~~~
ncrovatti
I made a tool for this : <http://css-sprit.es>

~~~
mgrouchy
Thats pretty awesome, I will check it out.

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

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

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

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

