I’m beginning a new project at work where, for the first time, I’m working with a large team of developers, and not just integration developers but front-end developers like myself. Since I’m the new guy, I’m finding myself required to learn the teams established vocabulary and this is making me realize just how much of my own vocabulary I have developed myself without even realizing how large it’s grown.

It all comes down to how we organize our code and that, of course, depends very much on how we are used to thinking about things. On a team of people working together for a common goal, such implementation-specific details are much more central to the success of the project than when working alone, such as in a freelance situation.

It’s interesting to me to see how many of the the established coding standards and naming conventions are obviously built off of the same kinds of ideas that I’ve already had and have been using for quite some time, and yet how different they are in implementation. This extends beyond the obvious case of using dash-separated class and ID names instead of camel case lettering or vice versa. It goes so far as to project management and workflow considerations, file name conventions, and semantics.

In some cases, optimizations are actually sacrificed on a team in favor of clarity, but this is actually a good thing. In my freelance work, I typically squeeze every last ounce of optimization into a project by using shorter names, more optimized files, and extremely dense code to ensure the best possible result. In a project with other developers however, the success of the project is far more dependant on everyone’s collective understanding of the code, so clarity is and should be prioritized above optimizations.

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