Monday, May 12th, 2008

CSS Child Selector Performance

Category: Browsers, CSS, Performance

<p>Are child selectors slower than more simple brethren? This is a question that Jon Sykes sought out data for after he read the work of Jim Barraud.

His conclusion?

The skinny is that child selectors are a major performance issue.

This seemed to make sense, but to me I needed some sort of proof rather than just being told it’s that way by someone, so over the last two days I’ve tried two approaches to see if I can replicate the issue.

The first one was rather a half-assed idea that afterwards seems fundamentally flawed as a benchmark.

So I took a new approach which does seem to return some valid and rather interesting findings, particularly regarding Safari and Firefox 3 and how they react to child selectors and performance.

The tests show that there is slow down using child selectors over direct class name declarations in IE6, IE7 and Safari 3. Safari 3 being the most impacted by child selectors. Firefox 2 has some impact, and Firefox 3 doesn’t seem to be impacted at all.

That said, this is a very extreme test, it is not often you’d have 20,000 class definitions in a single page or that all of them would use 4 levels of child selector.

CSS Child Selector Performance

Related Content:

Posted by Dion Almaer at 10:44 am

4.4 rating from 30 votes


Comments feed TrackBack URI

.className may not render correctly compared to table tr td.className if you have 2 different rule sets. Since the second is more specific, it will take precedence.

Comment by JonT — May 12, 2008

That’s right JonT. But I think the point was that “If that dependency is NOT your case…” then simplifying your selector use could be *slightly* beneficial. I have to wonder if the actual page rendering engine of a browser goes through the same issues. If so I have to wonder if simplifying CSS selector use in static HTML pages might help rendering speed. A little. Maybe.

Comment by Jeffrey — May 12, 2008

I agree with JonT. “.className” isn’t specific enough and could increase developer ramp-up time if you were to throw a developer on a project he’s never been on before. I’ve seen a lot of stylesheets have 4-6 levels because of shadows + rounded corner modules…Yeah, it can get ugly, but sometimes the client needs crazy rounded corners, gradients, and shadows–and they’re willing to pay for it!

In his test for 20,000 dom nodes he says that it is very extreme–That’s great! I always ask myself, “How far can we push a web application to its limits in terms of user experience, functionality, and performance?”

Kudos to Jon for a good find.

Comment by MezZzeR — May 12, 2008

hmm I use the left “style” all day to correctly identify the element I meant. Hmm the opposit would be to create millions of classnames instead. :-/

Comment by Aimos — May 12, 2008

Great information! Thanks for sharing it.

I always felt that the more specific the selector rule, the worse the performance. It’s usually better to have a generic selector rule rather than a specific one.

Of course, that’s all anecdotal.

Comment by skypoet — May 12, 2008

Do note that this if for CSS rendering speeds only. When using CSS Selectors inside a javascript library, something like td.className is far faster than .className.

Comment by PaulIrish — May 12, 2008

I’m a little flabbergasted.
I’ve always thought that over specifying meant that you CSS node parser did not waste time on nodes that could not fill the criteria and therefor would be faster…

I’d love to see techniques for speeding up stylesheets on large and complicated CSS structures.
It seems to me the only thing CSS optimisers know how to do is get rid of the added specifications… which to me was just aimed at minimizing file weight… but getting rid of something much more precious which was actual knowledge of where the style are to be applied (and where we do not need to look for them.)

Looks like a whole lot of wrong assumptions

Comment by JeromeLapointe — May 12, 2008

I guess my preconceptions would only work if you have direct descendant selectors…

Comment by JeromeLapointe — May 12, 2008

Jerome, I respectfully disagree with your logic. I would posit that in the case of .className the browser doesn’t waste time on anything without that class name. In the case of the specific “table tr td.className” selector the browser would find all the tables, then all the rows within the tables, then the cells and then go through all the elements in the cells to find .className

Of course I could be wrong :)

Comment by darkoz — May 12, 2008

These numbers are already showing me I’m wrong. :)
I’m realizing now that simple child selectors are not precise at all…

My intention was really to tell the parser… “you don’t need to go look at this section of the page, these are not the nodes you’re looking for” ;) … but I was fooling my self… it doesn’t do that at all, nor could it… this would only have a chance of working if you used the “child” selector and not the “descendant” selector… so I wonder what “table>tr>td.classname” as opposed to “table tr td.classname” would do (and then maybe “body>table>tr>td.classname”)… especially in a large document where there’s only 1 table. Only IE 5.5 and 6 does not support “child selectors”…

(The article is misleading as it seems to use the term “child selectors” where it should use “descendant selectors”)

Comment by JeromeLapointe — May 12, 2008

Sorry I meant to say”I’m realizing now that simple DESCENDANT selectors are not precise at all…”

Comment by JeromeLapointe — May 12, 2008

In my case it is mostly more like this:

“ tr td” and the other way would be “”, because so I can style more tables independent.

Comment by Aimos — May 13, 2008

No IE8?

Comment by seancallan — May 13, 2008

Thanks. Good article

Comment by Aphrodisiac — August 11, 2008

Great comparison. Very useful. I wonder how well Opera does with child selectors.

Comment by sujith84 — February 20, 2009

Leave a comment

You must be logged in to post a comment.