Note that this article is from 2011.<p>Trying his tests on firefox 20 beta, shows no difference between id and class selectors (the article says there was minimal difference in ff6), also no difference between between the type and "heavily overqualified descendant" selectors (article reports a large difference) and the latter pair are approximately twice faster than the former (the article seems to report they were up to 40 times slower).<p>So beware that browser technology has progressed since the time of this writing. Of course once again you should be checking the behavior of your site with the browsers your users are actually using.<p>[Edit: originally confused the two pairs of tests in my browser tabs, the slow tests in ff6 are actually the faster tests in ff20]
A lot of great information here. I always knew that overqualifying selectors was bad, but it was always from a "clean code" point of view and not so much from a performance standpoint. Even more reason to avoid them now.<p>Although this is very interesting information, anyone reading this article should pay careful attention to the ending headline, "Is all this really necessary?" Odds are, unless you've produced some kind of CSS monstrosity, your CSS isn't the bottleneck in your website performance. Min and concat your Javascript, use appcache, local storage, etc. before prioritizing CSS performance.
The most important piece of this is somewhat between the lines here though I think he kind of comes out and says it at some points (I'd recommend you check out his SpeakerDeck presentation[1] which mentions this too).<p>CSS efficiency is a balancing act between best practices, speed, and maintainability. CSS rendering is really cheap compared to JavaScript or most other things, HTML excluded. So yeah, be aware of efficiency but don't let it come at the expense of maintainability. If you add a "non-semantic" class here or there so another developer can immediately understand what you're doing it's not going to be the end of the world and in fact is probably the right thing to do, efficiency be damned.<p>What I always try to do is identify patterns and use IDs and classes accordingly. So, for example, I've got an app that displays success and error messages based on input. I originally (and stupidly) gave each one its own class (i.e. '.user-signup-error' or '.save-file-error'). That wasn't going to scale. So I went back in and gave each type of design element it's own generic class. So now there are things like ".notification-box" and ".error-msg". All elements of that type will be notification-box'es and be given a default style then I'll have another class added to the same element indicating the type of message. IDs are real useful for giving JS something to hook onto but otherwise HTML5 has allowed us to now get rid of a lot of those #nav, #header, #sidebar IDs and instead just use the appropriate element name (nav, header, aside, footer, etc.) which is pretty cool.<p>All in all though, this is something to be aware of but not to worry too much about. Being too strict about efficiency can be just as bad as being overly inefficient.<p>[1]<a href="https://speakerdeck.com/csswizardry/breaking-good-habits-1" rel="nofollow">https://speakerdeck.com/csswizardry/breaking-good-habits-1</a>
These are always interesting articles, but rarely of practical value. Performance is only one concern of a website project. I've found that a greater risk by <i>far</i> is predictable modularization, a topic with much less "engineering" attention. Any decent-sized project is going to have to decompose their presentation declarations info manageable artifacts, which has the unwanted side-effect of spreading out existing selectors across multiple files. Add to this a tight project timeframe, several engineers that treat CSS as a second-rate language (as almost all that I've encountered do, worsening the more senior they are), and CSS' lack of selector-spacing (in the namespace sense), and you have a recipe for thermonuclear battles over selector specificity.<p>Selector and naming conventions can basically eliminate this problem. Module root elements have a class name that starts with a letter; module nested elements have a class name that starts with a dash. These are combined with the child selector to constrain their applicability.<p>What was once super-ambiguous, e.g.<p><pre><code> body { color: black; }
.menu .item { color: orange; }
.menu .item .menu { color: black; }
.menu .item .menu .item { color: orange; }
/* and on */
</code></pre>
is now very precise:<p><pre><code> body { color: black; }
.menu > .-item { color: orange; }
</code></pre>
Is it the most efficiently interpreted ruleset? No, and I don't care. It's the most efficiently manageable ruleset. (Web Components will probably obviate this.)
Do really selectors work that way?<p>I always though that if I had:<p>#social a<p>The browser first get the social, then the "a" tag and analyze and store it in some DOM tree style information.
I think it's also good practice to check if you can reduce your DOM.<p><pre><code> <ul id="social">
<li><a href="#" class="social-link twitter">Twitter</a></li>
<li><a href="#" class="social-link facebook">Facebook</a></li>
<li><a href="#" class="social-link dribble">Dribbble</a></li>
<li><a href="#" class="social-link gplus">Google+</a></li>
</ul>
</code></pre>
could be written as:<p><pre><code> <a href="#" class="social-link twitter">Twitter</a>
<a href="#" class="social-link facebook">Facebook</a>
<a href="#" class="social-link dribble">Dribbble</a>
<a href="#" class="social-link gplus">Google+</a>
</code></pre>
since you already have the social-link classes attached to it.<p>Another example. This:<p><pre><code> <div id="header"><h1>header</h1></div>
</code></pre>
could be written as:<p><pre><code> <h1>header</h1>
</code></pre>
since you should have only one H1 on your page.
It's worth noting that this is from 2011. Here's some more discussion on the topic:<p><a href="https://developers.google.com/speed/docs/best-practices/rendering" rel="nofollow">https://developers.google.com/speed/docs/best-practices/rend...</a>
<a href="https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS" rel="nofollow">https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficie...</a>
For more resources about CSS optimization,<p>Google
<a href="https://developers.google.com/speed/docs/best-practices/rendering" rel="nofollow">https://developers.google.com/speed/docs/best-practices/rend...</a><p>Github
<a href="http://news.ycombinator.com/item?id=4890384" rel="nofollow">http://news.ycombinator.com/item?id=4890384</a>
I've created dozens of sites and never really noticed any CSS performance issues.<p>I have got orders of magnitude faster sites by combining CSS or js files, gzipping content, adding cache control headers, serving via a cdn and not serving code that's not used.<p>I've also really benefitted from using logical markup and CSS selectors, not those designed for "efficiency" of the computer rendering them.