Discussing CSS Management and Optimization

Published in CSS on Thursday, February 17th, 2005

As more large scale sites are migrating towards CSS, it is becoming apparent that the management of complex CSS documents is somewhat of an issue. What follows is the first post in a two post 'series'. Here in the first post we look at some of the ideas being used to manage stylesheets and the results of these tradeoffs. The second post will look at the balances that we can use to keep those results in check.

The "young-old" technology that is CSS has proliferated over the last few years thanks to projects like the Wired redesign (and later more high profile redesigns, more examples...) and the CSS Zen Garden.

Along with this, more and more designers are adding CSS to their toolkits and making their lives easier. Or are they?

Is it easier?

Not too many people - once they get into css - will argue that laying out and styling a website is harder with CSS than with tables. However it is becoming evident that managing stylesheets can be a difficult task on larger more dynamic and complex sites.

Stop the presses!

Before I go any further I need to stop and dispel a myth. When I wrote about gzipping CSS files, some people, either though e-mail or blog posts, indicated something to the point of "if your CSS files are large, you don't know what you are doing. Compressing them seems a little overzealous". Well, lets look at the following table and see just how small CSS files really are:

CSS file size details for some popular CSS based sites. The size is the sum of all of the screen type style sheets for the given site. Single line refers to code where line breaks are only present between selectors.
Name Size of CSS (kb) Notes
www.mezzoblue.com 20 325 lines of single line in the largest sheet
www.stopdesign.com 42.75 1200 lines in the largest sheet
www.wired.com 27.28 1014 lines in the largest sheet
espn.go.com 20.81 799 lines in the largest sheet, appx. 1/3 single line
www.blogger.com 26.52 1200 lines in the largest sheet
www.travelocity.com 31.79 400 lines of single line css

All of those sites have over 20 kilobytes of CSS, and when you are getting up to over 1000 lines of code, whether it's cleaned of line-breaks and whitespace or not, you are dealing with something rather large and complex. Size is an issue, and furthermore management becomes an issue.

But how often do you really tweak your CSS after a site is built?

For many sites the CSS will remain fairly static after it launches.

I know that I won't be making too many changes to the css for this site, once I get the bugs worked out. I bet Doug hasn't done a whole lot to his CSS files since he re-designed, but what about a site like www.travelocity.com? Or that special promotion you have to add to the site one month and change the next?

The truth is that for some sites out there, CSS isn't static. And for many larger sites out there that require a fair amount of CSS (or simply sites with more complicated layouts), having clean, commented and organized stylesheets is an asset.

Writing manageable CSS - the decisions

One thing that becomes clear right away after examining the CSS files for the sites outlined above is that there are some decisions that need to be made from the outset about how you are going to write manageable CSS:

  1. Dependant or redundant?
  2. How are you going to manage your hacks?
  3. Will you be optimizing it to single line for the live files but leave it multi-lined for coding?
  4. Will you be splitting up your stylesheets by purpose for easy management? (see digital-web, bleach)

Let's have a look at these issues independently, and then bring it all together to build an ideal strategy.

Dependency vs. Redundancy

Dave does a great job of tackling this issue in his post "Redundancy vs. Dependency". There is a spectrum between the two, and where on that spectrum a set of stylesheets should lie will depend on the project.

However in the scope of this article, dealing with managing larger more complex stylesheets, redundancy is generally favoured.

Hack Management

This issue is an important one as hacks are a necessary evil when it comes to building a site with CSS. While overall a very useful article, Integrated Web Design: Strategies for Long-Term CSS Hack Management gives three little pieces of advice that I think are very important:

  1. Know CSS and know your hacks
  2. Comment, comment, comment
  3. Surgical Correction Strategy

By applying the three tips above, one should end up with less hacks (knowing your hacks means knowing when to use them), which themselves are well documented (commented) and easy to remove (surgery). The result is a set of stylesheets that are easier to manage.

Multi-line to single and separating stylesheets by function

I put these two items together because they present similar trade-offs. If we want something that is easier to manage we're more than likely going to have greater code bloat and http requests, due to extra stylesheets, whitespace and line breaks.

[h4]No big deal?[/h4]

Some people would consider these non-issues. Extra sheets means a couple of extra requests, nothing too hard for a multi-threading browser. And CSS programs like TopStyle will zap your files into single-line with ease, so having a multi-line version for working and a single-line version uploaded isn't too difficult; even better if you have a little script to do it for you (single-line your file and then upload it).

[h4]A look at reality[/h4]

But remember, we're looking at managing a file for a larger site here. Multiple stylesheets for a complicated (multi-themed, multi-tiered navigation) extranet could mean 4-5 sheets: color, nav, layout, forms, tables etc.

In addition to the above, have a crack at the source for the espn home page, and you may start to think that extra requests do matter. Work on a site on a daily basis (perhaps tweaking the CSS styles weekly, sometimes daily), and you'll also find that zapping your CSS to single line in order reduce it's size before you upload it is a pain in the you-know-what.

So where does this leave us?

Taking into account what has been discussed, our manageable CSS for a larger site would:

  1. Be coded overall on the side of redundancy.
  2. Be well Commented.
  3. Contain hacks in extra, hack specific stylesheets.
  4. Consist of more than one and possibly several stylesheets for easy management.
  5. Is multi-lined locally but hopefully single lined on the server for cheaper downloading.

Looking at the above, it is fair to say that the result of having a well documented and organized system in place for your stylesheets will be more code and more http requests to the server. While we all know that CSS need only be downloaded once and then cached, there are some easy ways to mitigate the resultant extra code and requests.

Balancing the bloat

So what can be done to balance this bloat that is a result of these methods of stylesheet management? Well, click through to Applied CSS Management and Optimization where some common methods of managing and optimizing CSS are outlined.


Please use the comments below to discuss the matters outlined in this article, and please at least skim Applied CSS Management and Optimization before commenting here, as your comment may be more appropriate to that post. Thanks!

Comments and Feedback

you do have to keep track of the file size of your CSS files. I am building a large site now that is around 40-45 KB. Managing what styles you have in the global style sheet is importatn. Also you need to be sure not to split up the CSS into too many different files, because that will also require more http requests, when you call the different styles.

Heh, as I said above Blake, hop over to the next article! ;-)

Good article indeed. Andy King's Speed Optimisation book addresses a lot on great optimisation techniques and allied issues with good practical examples. Its good to see this is getting out there more and more. I wish all or the major CSS Editors all had a white space remover and code compacting facility(compacting and reformatting). OmniWeb has has had this facilty for a while already.

Nice topic to discuss. My approach these days for smaller sites is to lump everything into one file, heavily commented, multi-line & gzipped.

On web apps usually I'll separate the files into chunks - color, positioning, tag overrides, custom classes & page-specific styles - all also gzipped.

It becomes a little difficult when controlling color from one file, as you have a lot of overlap from each style sheet (classes defined in more than one file). I've been playing with server-side variable substitution for colors and images (for themes), then caching the CSS file. This seems to work pretty well and offer a little more flexibility.

Anyone else doing the same thing?

Hey seth,

I've seen what you describe mentioned over in Webmasterworld a few times.

I'm going to reply to the rest of your comment over in the next article's comments...

When people complain about large style sheets as a "rebuttal", they get into a discussion akin to "open source is free". Downloading a 20K CSS file and having it cached is much better than pulling down the same bloated page multiplied by thousands or millions of views.

Also, compressing CSS and JavaScript doesn't work that well. We've seen some oddities with this and pulled the plug on it. So far we compress only HTML.

Milan, what sort of oddities have you seen? Have you reported this somewhere? I'd love to hear about it, drop me a line, would you?

Well, we observed inconsistent oddities. :) There was no consistency in how all browsers we tested with handled compressed CSS and JavaScript. I'm sorry, I wish I remembered exact details of which version of which browser in particular chocked on compression, but it was enough for us to fall back to what we knew worked, namely compression of HTML (well, technically, ASP.NET pages which rendered HTML).

The gains from compression were tremendous, though! I briefly thouched on this in an article on my site. You can take tweaking a step further with cache control extensions.

Thanks Milan. I haven't heard too many reports yet about trouble with compressed CSS (tho I did hear that people who tried it some time ago did have problems), however compressed JS is something that I still hear people complain about.

I'll keep on testing the CSS method and hope that it holds up...

CSS is very beneficial to websites. It should be used to almost all websites as much as possible

Home » Blog » Web Development » CSS

Check out the blog categories for older content

The latest from my personal website,
Mike Papageorge.com

SiteUptime Web Site Monitoring Service

Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:

The Principles Of Successful Freelancing

I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.

The Art & Science Of JavaScript

The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.

The PHP Anthology: 101 Essential Tips, Tricks & Hacks

Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..