How to Write Efficient CSS – Evaluation of CSS

29 August 2011 / Technology

I recently did a knowledge share at work on how to write efficient CSS, and one of my colleagues – a senior developer with a lot of experience – said "I felt the penny drop". High praise indeed, so I thought it was worth reproducing it here.

The write-up is pretty long, so I've divided the divs into Basic CSS in which I cover:

1. CSS
2. Selectors
3. The Cascade
4. Inheritance

and Evaluation of CSS in which I cover how CSS is evaluated and some things we can do to make it more efficient.

How CSS is Evaluated

The key information is these two points:

1. For each element, the CSS engine searches through style rules to find a match.
2. The engine evaluates each rule from right to left, starting from the rightmost selector (called the "key") and moving through each selector until it finds a match or discards the rule.

1. For each element, the CSS engine searches through style rules to find a match

The style system breaks rules up into four categories by key selector.

1. ID Rules – for example button#backButton { ... }
2. Class Rules – for example button.toolbarButton { ... }
3. Tag Rules – for example treeitem > treerow { ... }
4. Universal Rules – all other rules

The CSS engine then takes each html element in the document in turn. If it has an ID, then the engine searches through the style rules and checks rules that match that element's ID. If it has a class, only Class Rules for a class found on the element will be checked. Only Tag Rules that match the tag will be checked. Universal Rules will always be checked.

2. The engine evaluates each rule from right to left...

So in the example button#backButton { ... } the key is the id "backButton". In the example I give in Basic CSS the key is the class "blog-post".

The engine starts with the key and then evaluates the rule from right to left. So if you have a button with an id of "backButton", the engine first matches the id to the id and then compares the next selector – is the element a button? In the example from Basic CSS the evaluation for the second selector, ul#nav.dhtml li a.blog-post, is as follows. Does the element have a class of blog-post? If so, is it a link? If so, is there anywhere in its ancestry a list item? If so, is there anywhere in the ancestry of that list item an unordered list element with a class of dhtml and an id of nav?

You may be getting a slight clue now as to why I think that selector is inefficient.

Recommendations

There are some obvious ways we can start here.

• Firstly, remove unused CSS. It's not like, for example, unused Java code which really just slows things down for other developers. The CSS engine is going to search through every rule for every element. The fewer rules required to check for a given element, the faster style resolution will be.
• Avoid use of descendant selectors – they speed up page development, but they slow down page rendering.
• Avoid qualifying ID selectors at all – as IDs should be unique so adding extra qualification is unnecessary and costly.
• It's a good idea to avoid use of html elements in selectors for a couple of reasons:
  1. The style will be lost of the element type is changed
  2. The less specific the key the greater the number of nodes that need to be evaluated
• Avoid use of child selectors. They are more efficient than descendant selectors, but they are still inefficient: for each matching element, the browser has to evaluate another node. It becomes doubly expensive for each child selector in the rule.

These are just recommendations as to how to write the CSS. If you care about your website's performance you should already be minimising and gzipping your CSS. So how much of an edge will these recommendations give you?

CSS and Performance

CSS and performance is a fairly hot topic right now, especially with all the cool things that you can do using CSS3. Dave Hyatt, architect for Safari and Webkit, said "The sad truth about CSS3 selectors is that they really shouldn't be used at all if you care about page performance." (The comment can be found here).

That's certainly something I've heard, for example at conferences. However, another web giant, Steve Souders (works at Google on web performance) has a different opinion. It's worth reading the piece in full (there are charts and everything!), but the takeaway here is: "On further investigation, I'm not so sure that it's worth the time to make CSS selectors more efficient. I'll go even farther and say I don't think anyone would notice if we woke up tomorrow and every web page's CSS selectors were magically optimized."

So why am I bothering with this? Well, a few reasons. One is I think it's always worth taking the time to find out how things work and I'm glad to be able to make a reasoned judgment on this.

But also, there are various things to consider when thinking about writing efficient CSS. There is performance, obviously, but two other major concerns are ease of writing and (in my view more important) ease of reading. I love clean code, and I think it's crucial that code is easy for other developers to read. I'm not sure I care whether or not ul#nav.dhtml li a.blog-post is performant or not, it's certainly not clean, and it took me some brow furrowing to work out when it would apply. So personally, I'm going to follow the rules I've outlined above. What do you think? I'd love to hear your opinion.

Useful Further Reading

I gleaned most of the information about how the CSS engine works from Page Speed documentation and the Mozilla blog. I couldn't find any information about how IE evaluates CSS, please do let me know if you have any.

To take things further with writing nice CSS, you could look at Compass/SASS, or my current favourite, OOCSS.