Performance gain from specifying element.class { ... } vs just .class { ... }?

Question

If I know a particular class will only be used on div's or p's, is there even the slightest effect on performance by specifying div.class or p.class instead of just .class?

That would depend on the CSS engine implementation. What makes you think all browsers implement it the same way? — Matt Ball, Aug 30 '12 at 16:37
Why downvote this? This is a reasonable question. CSS performance is an important issue for large sites. — usr, Aug 30 '12 at 16:39
@usr No, it really isn't. Your CSS should be optimized for maintainability, not performance. — user229044, Aug 30 '12 at 17:17
https://developers.google.com/speed/docs/best-practices/rendering Check this Good Article BY Google — Arpit Srivastava, Aug 30 '12 at 16:44
from this: Rules with overly qualified selectors For example: ul#top_blue_nav {...} form#UserLogin {...} ID selectors are unique by definition. Including tag or class qualifiers just adds redundant information that needs to be evaluated needlessly. — chrickso, Aug 30 '12 at 16:49
@BenitoCiaro Your attitude demonstrates a *deep* ignorance of how quality software is developed, and specifically how software is developed for the web. We are talking about **CSS**. Nothing you've said is in any way applicable. Further, what I'm suggesting is the accepted best practice across the industry in virtually all kinds of development, not the "Java philosophy". Performance does not constrain the vast majority of software; time and budget does. — user229044, Sep 06 '12 at 03:59
"Thousands" of complex CSS rules is not a lot. I would be far more concerned with writing maintainable CSS. This is why technologies like SCSS are so successful. You should take ever second you're thinking of investing in writing "performant" CSS and instead invest it in producing clean code. — user229044, Sep 07 '12 at 05:46
possible duplicate of [Why do browsers match CSS selectors from right to left?](http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left) — Peter O., Nov 24 '12 at 04:50

score 9 · Answer 1 · answered Aug 30 '12 at 17:00

If you're interested in testing this yourself, Steve Souders has a "CSS Test Creator" which lets you test the speed of different CSS selectors:

http://stevesouders.com/efws/css-selectors/csscreate.php

I tested both .class and a.class using 10,000 rules and 10,000 anchors. Running each test 5 times, I got the following results:

+----------+-----------+----------+
|  Test #  |  a.class  |  .class  |
+----------+-----------+----------+
|    1     |  2915 ms  |  2699 ms |
|    2     |  3021 ms  |  2869 ms |
|    3     |  2887 ms  |  3033 ms |
|    4     |  2990 ms  |  3035 ms |
|    5     |  2987 ms  |  2980 ms |
+----------+-----------+----------+
|  AVERAGE |  2960 ms  |  2923 ms |
+----------+-----------+----------+

As you can see, .class is slightly faster, but insignificantly so (37ms over 10,000 elements). However, there is a reason to use .class over tag.class, and that is flexibility. If you have a bunch of <div class="content"> elements that you later change to <section class="content"> elements, you'll have to modify your CSS if you used div.content rules. If you used .content, then no CSS updates are needed.

In general, I would only use tag.class style selectors if you have multiple tag types that use the same class, and you only want to target a specific tag type.

score 0 · Answer 2 · answered Aug 30 '12 at 16:37

0

Yes, .class is slightly faster than element.class. That's because CSS is read left to right, so .class means ("Match all the elements who have class name of .class") while element.class means ("Match all the elements who have a class name of .class who are also an element").

However, element.class will have a higher specificity value than .class.

answered Aug 30 '12 at 16:37

Madara's Ghost

172,118
50
264
308

9

`[citation-needed]`. Where's the proof? – Matt Ball Aug 30 '12 at 16:38
There's no need to prove it. Simply stating the difference in specificity is enough to blow out any performance concern whatsoever. And the system needs to make duplicates easier to find *-grumble-* – BoltClock Aug 30 '12 at 16:38
CSS engines don't necessarily match left-to-right. They are probably optimized for common use-cases. – usr Aug 30 '12 at 16:50
Whether it's LTR or RTL, I have to point to this answer again: http://stackoverflow.com/questions/10106345/css-selector-engine-clarification/10108700#10108700 It's very well known that [browsers do RTL matching across combinators](http://stackoverflow.com/questions/5797014/why-do-browsers-match-css-selectors-from-right-to-left) but in this case *there aren't any combinators involved*. It wouldn't make any sense to do RTL matching on this level. Still, much ado about nothing. – BoltClock Aug 30 '12 at 17:13

score 0 · Answer 3 · answered Mar 11 '14 at 18:52

I know this was not the question, but it affects specificity, so in the example below, the innerClassFails doesn't override the contained tds, while the table.innerClass does override it.

<style>
table.outerClass td {
    color: red;
}

table.innerClass td {
    color: green;
}

.innerClassFails td {
    color: green;
}
</style>
<table class='outerClass'><tr><td><table class='innerClass'><tr><td>Hello!</td></tr></table></td></tr></table>

<table class='outerClass'><tr><td><table class='innerClassFails'><tr><td>Hello!</td></tr></table></td></tr></table>

`table.outerClass td` = 0012, `table.innerClass td` = 0012, `.innerClassFails td` = 0011...The calculated specificity tells it all. — War10ck, Mar 11 '14 at 19:02

Performance gain from specifying element.class { ... } vs just .class { ... }?

3 Answers3