Everything In Between

There has long been some talk about compressing CSS files to make them smaller and thus use less bandwidth. While compressing files transffered over HTTP is all well and good, some people have taken the ability to do this as a license to create badly-designed, bloated style sheets that inevitably turn into nightmares. What these people don’t realize is that optimized web pages shouldn’t need to be compressed.

(It should be noted that the folks over at FiftyFourEleven are not folks whom I believe are using CSS improperly. The referenced article merely provides additional information for compression techniques.)

When I optimize web sites, utilizing HTTP compression techniques (especially with PHP) is one of the last steps I take and sometimes it isn’t even necessary at all. If your CSS is so large you think you need to compress it, then quite frankly, you’re not using CSS properly.

It’s very, very rare that even large web sites’ CSS files will ever get so big that they need compression if they are written properly the first time. (I’m talking like 25 kilobytes and up here, and even that’s not considered “huge.”) Why is this? Because good CSS should include a couple of distinct characteristics which cuts down on their size dramatically:

• High-level DOM selectors should be used to take advtange of CSS inheritance.
• Duplicated and default-declaration rules should be omitted and grouped (as should selectors).
• Shorthand properties and value replication should be utilized as often as possible.
• Use the cascade to supply global rules for alternative styles and medias (screen, print, etc.).

Finally, CSS is cached (or should be). That means it’s only sent down the pipe on the first request for it, and using modularized CSS by following the above guidelines means you can re-use these cached files over and over again in many different ways without using a touch more bandwidth.

Thus, it is always a bad idea to rely on compression rather than to do things right the first time. (Band-aids don’t actually correct technological problems.) Thinking that it doesn’t matter how much code you write because you’re going to compress it anyway is foolish (though frighteningly common), and can cause serious problems later on in the course of maintaining and updating or redesigning a web site.

Furthermore, some of the main reasons some sites take so long to show up on a user’s display has very little to do with bandwidth. For instance:

• Complex tables will tax a user’s CPU by forcing the browser to perform many calculations to configure the table’s display area, slowing rendering speed.
• To make matters worse, in many cases browsers can’t display any part of a table until the whole table has been processed. If your entire page is contained within one big table, then you’re going to make people wait for the entire page to finish being processed. (Ouch.)
• On the same note, really long pages can quickly turn into usability nightmares for other reasons, as users easily lose their initial context and relevance, so it is advised to limit the vertical length of most web pages for usability as well as optimization reasons.
• Page load time increases exponentially for each distinct object (like images, multi-media, even JavaScripts and style sheets) that you place on a page. Reducing the number of HTTP requests is far more important than compressing the content of HTTP transactions because a delay caused by network latency is indefinite.

So what have we learned? If you’re really that concerned with the bandwidth your CSS (or HTML) is eating up, I’m not going to tell you not to compress it, but I am going to tell you that you should probably be dealing with other, more pressing concerns. Let’s talk image optimization, for instance! That, however, is a discussion for another time.

The bottom line is that CSS was designed with bandwidth in mind. Using CSS intelligently drastically cuts your bandwidth use which saves you money and headaches because it reduces code bloat for both style sheets and HTML files. HTTP compression is great and useful, but not as a band-aid to fix a problem it can’t solve.