TL; DR: The .media__bd--gretting h1{} selector is faster.
I say it's faster based on a series of articles I'm going to quote here, but it's worth starting my answer by saying how complicated your question is, and how difficult it is to jump-start the answer. In the words of David Hyatt, architect of Safari and Webkit:
The sad truth about CSS3 selectors is that they really should not be used at all if you care about performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.
What basically means that CSS3 selectors (which encompass your :nth-child() case should not be used, if your focus is performance.) This quote has been removed this article , which dates back to 2009. If you read the article, you will see that the conclusion was that this type of optimization, when done, results in little gain in speed, and that the cost-benefit ratio is practically zero. If in 2009 the gain was low, imagine now in 2015 with the technology as a whole much more efficient.
I discussed, in this answer , about good CSS practices. One of the points was about bloating . I've maintained code where each element, however repetitive, had its own (and only) statement. A real example of this is
.bloco1 {
float: left;
width: 33%;
line-height: 1.5;
}
.bloco2 {
float: left;
width: 33%;
line-height: 1.5;
}
and this was repeated for, believe me, 12 blocks, all with the same style rules. The end result is a huge code bloating and therefore inefficient. In this case, specifically, it was possible to reduce CSS to:
.bloco1, .bloco2{
.
.
.
}
which would already help to reduce file size and over-repeatability in the code. In an ideal world, there would be a class called .bloco , and markup would be created accordingly (which was not the case). In this type of situation, you no longer have a C S S heet, and you have S > ty S heet, completely ignoring one of the most powerful features when it comes to styling.
This example illustrates that the greatest performance problem lies not in the depth of the selector's specificity but rather in a general scope of how large its entire application is, and time it takes. This includes optimizing everything, HTML , CSS and JS .
This publication (latest, 2014), brings you a series of tests that were done on CSS performance, and what are the best (and worst) practices. An interesting reading, which leads to a series of nice conclusions, two of them being:
sweating over the selectors used in modern browsers is futile; Most of the time, it is not really worth spending much time over. Moreover, there is disparity across browsers of what the slowest selectors are anyway. ...
and
the battle for high performing CSS will not be won in the selectors used, it will be won with the judicious use of property and values
What, basically, means: Are there selectors that are faster than others? Yes. Nasty nights worth it? No. The speed battle will be won through the intelligence used to construct your CSS (and your application as a whole) and the properties used, not the milliseconds you gain if you use a pseudo-selector. / p>
