2007 / March 17^th/ Common web myths: Optimizing CSS & Javascript

Many people give a big to-do about optimizing CSS & Javascript. Everything from removing line-breaks, to removing all comments & whitespace, to obfuscating compressors like http://javascriptcompressor.com. But is it worth it? Really?

I’d like to just make it clear that I really don’t care about CSS & JS sizes. Quite honestly, I think the sizes of these files are so minimal in today’s rich media world, it’s not worth fussing over. But let’s ignore my opinion, and continue on with my example.

Example: My CSS

My CSS file is far from optimized — in fact, it’s optimized for humans, not computers. I have lots of whitespace, lots of comments, and no regard for filesize. Currently, it sits at 17.7kb.

Now, let’s try compressing it at Clean CSS. The result?

Input: 17.7KB, Output: 11.684KB, Compression Ratio: 34%

not too bad, I ended up shaving about 6kb off the file.

But what if we take another approach and use a server-side module included in Apache: mod_gzip? Let’s give it a try over at a tester site The result?

input: 17.7KB, Output: 4.83KB, Compression Ratio: 71%

Well, now that sure seems like the previous test was a waste of our time, wasn’t it?

White-space optimizing is stupid

So what did we learn from this? Don’t destroy readability (even if only on the production server) for a false sense of optimization. Take a look at all of your options and take the road that gives you the most benefit. Just because you can, doesn’t mean you should.

At the end of the day, it’s your images and rich media that are going to take up your bandwidth. Not your HTML/CSS/JavaScript.

Edit: Paul has the low-down on how-to with PHP for those of you without server access.

1. 

   Justin Ruckman

   March 17^th | #

   Right on dude. Injecting a little common sense where it’s badly needed.

2. 

   Rob

   March 17^th | #

   FINALLY! Thank you for pointing that out. Unless you’re a big company and your website’s CSS file is getting well into the thousands (and it probably shouldn’t), not worth the trouble or the sacrifice.

3. 

   Ranjani

   March 17^th | #

   Thank you! I was hoping that trying to make my CSS file a little more organized and neat wouldn’t hurt things too badly, but I chickened out. I guess…I can…chicken into cleanliness once again?

   And another annoying thing about the optimizer. Unless you’re careful, it might change the way values are listed (for the sake of optimization), and affect what your site looks like — marginal differences, of course, but annoying all the same. We all work hard for those ten pixels, dammit!

4. 

   Tony

   March 17^th | #

   So what about running a compressed file through mod_gzip ?

   A major inconvenience I see is that one would have to start keeping track of two versions of the file: human readable (for any future changes), and the crunched down version. And as Ranjani says, as soon as some inconsistency is introduced, it’s trouble.

5. 

   Kyle

   March 18^th | #

   Tony: There’s the beauty in gzip: you don’t notice at all. It’s all handled server-side when the page is served. Meaning that on the server (physical file system) it’s a regular file, it only gets compressed just before it’s sent to the browser. Also, running a compressed file through gzip doesn’t give you much *extra* gains due to the fact that compression algorithms take stuff like whitespace into account automagically.

6. 

   Matthijs

   March 18^th | #

   The funny thing is, I have recently switched from using whitespace and coments in css to just writing declarations on single lines. Not for performance sake. It just makes my stylesheets a lot easier to read/work with. For me. The reason is that scrolling up and down and finding the section you’re looking for takes a lot more time then reading a single line with a couple of declarations (margin,padding,color, etc). So my css now looks like:
   h2 {font-size:2em;margin:1em 0; etc}
   h3 {font-size:1.5em;margin:1em 0; etc}
   Certainly if you use a common order, it’s no problem at all to find specific style declarations.

7. 

   Matt Wilcox

   March 18^th | #

   I have to voice my ‘here here’ for your conclusion. I’ve always felt that readability is far more important than shaving off a few Kb in a file that’s downloaded once, cashed immediately, and can be greatly compressed server side anyway. I’ve never been sold on ‘code optimisation’ utilities. They optimise very little but mean that the developer will take twice as long to figure stuff out if they ever need to revisit that css/javascript.

   NB: well written CSS using selector grouping and the cascade is a different form of optimisation, and one that I do support the use of.

8. 

   Matt Wilcox

   March 18^th | #

   @ Mattijs

   I used to use the one line technique, but find that horizontal scrolling is much worse than vertical scrolling for trying to find things. Good use of ‘comment anchors’ allow easy searching through your editor of choice too. If you’re interested you could take a look at the organisation techniques I’ve come to use after a few years of constant CSS development, and see if any tickle your fancy: http://mattwilcox.net/archive/entry/id/642/

9. 

   Matthijs

   March 18^th | #

   @Matt: indeed, horizontal scrolling is not pleasant. I avoid that as well. If an element has that many declarations, I use another line. And I am aware of using comment anchors and how they can be used to collapse/search. But for me, one move of my scroll wheel to get me were I want to go is faster then typing in a search term.

   But, I understand this is all personal preference. I also think it makes a big difference whether you work alone or in a team, on smaller or bigger sites, etc.

10. 

    Georges

    March 18^th | #

    Good point! Using mod_deflated for some time now and I even start having the feeling that most of my projects just load faster with compressions on the server-side!

    Just to point it out: since Apache2, mod_gzip does not exist anymore. It’s now mod_deflated. Here is a good article on how to set it up in less than 5 minutes: http://www.debian-administration.org/articles/137

11. 

    links for 2007-03-18 « kobak del.icio.us könyvjelzÅ‘i

    March 18^th | #

    [...] Common web myths: Optimizing CSS & Javascript - Warpspire (tags: css webdev wordpress HowTo optimization reference warspire) [...]

12. 

    Lukaszp

    March 19^th | #

    But you all forget about those who still use slow connections. For me, as an low level programmer, it’s good to squeeze as much as possible especially when i see those websites where images and all those pretty addons take 60-70% of screen not talking about bandwidth.
    Imagine what would happen if you optimized your css AND used transport compression? Remember that faster your HTML/CSS/JS gets to the browser faster it gets displayed and images can be downloaded later by browser so overall smaller your HTML etc. faster your page’s initial display.

13. 

    Mal

    March 19^th | #

    The gzip’d compress CSS is 3kb, which is 25% smaller than the gzip’d but uncompressed version. It’s also harder to steal, if you’re worried about that.

    While it’s important to keep your CSS readable for development and maintenance, this is only important within your editor. Your web server and browser doesn’t care, and there’s a number of ways to produce the optimized version automatically. You can have PHP pipe the file through cctidy, similar to Paul’s gzip setup, you can use modextfilter on Apache to do the same, or you can make the compression part of your build process, if you use Ant or similar.

    And when you need to examine the CSS of page in your browser, for that off the cuff tweaking, you can use Firebug or the IE Developer toolbar to see the current style of an element.

14. 

    Mike Papageorge

    March 22^nd | #

    I think if you can implement something on the fly that strips whitespace and gzips, you’re laughing. This can be easily done by we programmer types :-)

    Also, see The Definitive Post on Gzipping your CSS for some more PHP style solutions.

15. 

    Marcus Collinsworth

    September 27^th | #

    Why not take this a slight step further and cache the output compressed file? :)

Name

Email (will not be published)

Website (optional)