At White Whale, we’re of course always thinking about code efficiency: less queries, less code, fewer requests, et cetera. And much of this on the design side is rote best practices (semantics, accessibility, compatibility). But I still find myself sweating more nitty-gritty details, so I was fascinated to see jpsykes’ analysis of this one. The question boils down to, “How specific should I get with CSS selectors?”

We have:
#header #navigation .portal  { font-weight:bold; }
vs.
.portal { font-weight:bold; }
I’ve leaned toward the first on a gut feeling; .portal will only ever appear in #navigation in #header, so why not tell the browser where to look? But intuition is wrong in this case. Check out the graph (again, via jpsykes):

Giving more selector specificity causes performance hits across all the major browsers. What’s happening is that the browser actually starts at the right-hand side of the selector and searches backwards. So it finds all instances of .portal, then climbs up the DOM to make sure it’s in #navigation, then filters again for #header. (You’ll see that FF3 seems to perform best overall, but that’s a little misleading for reasons a commenter notes here. Check out the results with a better control.)

Interestingly, the opposite effect is true for JS frameworks. Their selector implementations — we use jQuery at White Whale — tend to process the selectors from left-to-right: first finding #header, then looking inside it for #navigation, and then inside that for any instances of .portal. So those work best when coded with some specificity.

It’s important to note here that we’re talking fractions of a second on a page with 20,000 test elements. So until we start serving 20,000 database records on a single page, our best practice will be whatever makes it easiest to keep the code straight in our own minds and for our clients — but I can’t help but think I’ll be subconsciously affected by the knowledge that every .newslist li .summary might shaving precious milliseconds off our load time.