Writing CSS Effectively: Smart rules

1. The biggest speed gains

The best way to improve the speed of your site is to reduce the number of HTTP requests. HTTP requests happen when a web page requests a file from the server: Scripts, CSS files, images, and asynchronous client-side/server-side requests (e.g. Ajax).

When it comes to performance, this is the most important area for improvement. The fewer HTTP requests, the better. Smart use of CSS can assist in this.

• Merge your external CSS files to one file (do the same with scripts)
• If possible, replace images with CSS - for instance, 1x1 or 1x2 pixel GIFs repeated to create lines can with CSS borders, and new CSS3 techniques can be used for gradients, shadows, and rounded corners
• If background images are small (or can be made small), consider converting them to data files and inlining them in the CSS - this way the will be browser cached if you cache your CSS.
• If you use several small images on the page, consider combining them into a CSS sprite. A sprite of 10 images will perhaps be big, but it will eliminate the loading of 9 images.

The load time savings you can achieve by reducing the number of HTTP requests are potentially an order of magnitude larger than what you can achieve by efficient use of selectors. This is ought to be priority # 1 if you want to speed up a web site!

See also Yahoo's performance rules

2. Use resets, but with moderation

Resetting the browser style rules once and for all is good practice. But resetting like in (1) or (2) below is bad:

(1) * { margin:0; padding:0; }
(2) html, body, div, h1, h2, h3, h4, h5, h6, ul, ol, dl, li, dt,
    dd, p, blockquote, pre, code, form, fieldset, table, tbody,
    th, td { margin: 0; padding: 0; } 

Both of them make the browser do unnecessary work. I have seen people write that rules of type 1 can bring old PCs with IE to a complete standstill. The point is: There is no need to reset tags you are not using - so why reset the table tags and the fieldset and h5 and h6 if you don't use them? Also, if you want to be very precise, you don't need to reset tags that you redefine both margins and paddings for later. If I have rules like these

p, h3, h4 { margin:0; padding: .3em 0 1em; }
h1, h2 { margin: 0 auto; padding: 1em }

there is no point in first setting the margin and padding of these tags to zero? So my advice is: Build your own site specific reset rules on the basis of what you need, and add and delete as required as you grow the site.

3. Avoid over-specified selectors

Don't use ul#whatever or div.something! They are over-specified. IDs are unique - it is redundant to say which tag it applies to. And classes are sufficiently defined without the tags too. #whatever and .something will suffice. The use of extra tags in these types of rules - I often call them "merged selectors" - is redundant!

If you want to be precise, they are actually most often worse than redundant. If you start to style sections of your pages with rules like that, you will very soon find that they are too specific, and that you have to stuff later rules that redefine tags for smaller parts of the sections with totally necessary descendant selectors just to make them specific enough. As a consequence, using this type of rules tend to result in bloated style sheets, full of wasted motion.

See also: Russian test of selector speed, Second test

4. Write the CSS after the content has been produced

Doing it this way prevents you from writing unnecessary CSS. Even more importantly, it allows you to evaluate the needs for styling and follow the simple rule that you want to style as much as possible once and only once.

This implies that I prefer to write the rules so that for instance the padding and margin of all paragraphs, headers and the like are defined in EMs, so that when I reset the font size in sidebars and fnutts, paddings and margins will be scaled automatically without me having to redefine them.

Also, styling as much as possible with element selectors (which apply everywhere) rather than within IDs and classes (which apply only within a division or context) saves style rules.

5. Avoid classitis and divitis

Seemingly, the fastest and most efficient CSS is one that uses lots of IDs and classes, thus reducing CSS expressions and descendant selectors. But using classes and IDs extensively has other disadvantages: It makes your style sheets grow long and your markup get ugly if you push it to the limit.

Personally, I am willing to use an extra class if the alternative is really bad, such as three or more descendant selectors. In lists and menus I am willing to mark up sub-levels with classes for the ULs, but I am not willing to mark every single LI in a menu or every link on a page as a class. That for me is classitis.

The point, however, is that there is no one best way, and that every web master and web designer has to make a decision about where to draw the line. The choice about when to use IDs and classes and when not to use them is one that one has to make - and not thinking about it and not making it is a choice too. Personally I like to use few IDs and classes, have short and maintainable CSS files, and use extra classes mostly when it also makes sense for other reasons than just more efficient CSS.

In other words, this rule says: Don't become an absolutist - find a good middle ground between the most effctive CSS and tidy CSS and markup.

 

Posted: September 2011