Performance CSS (CSSOM and selectors)

Asked

Viewed 137 times

4

Considering the assembly of CSSOM by the browser and parser (read) given right to left. I would like to play a question, because I was writing a css in a project and always have with me for performance not use Type Selectors and I try to use the methodology of modules WELL.
Doubt: If I write a descending selector like this: .media__bd--gretting h1{} or selector with pseudo-class .media__bd--gretting h1:nth-child(1).
Without considering the specifics and disregard type selector (H1) in the declaration, which performs best?

Note: I put it this way because I was making one module . css (tipography) I didn’t want to inject a class in the html in which the Block (module) "media__bd".

css css3 performance selectors
  • 1

    I can be honest, I can’t give the answer, but I think there is a lot of exaggeration about the performance of css selectors, which will define the performance better (I believe) is how many nodes you have on the page. It is likely that with nth-child(1) is slower, but is likely to also take the same time for microsecond perception, the without pseudo can take 1.5ms already the with pseudo can take 2.2ms for example, is so imperceptible that it is a type of optimization that does not compensate. Then I’ll give you +1 on the question because it’s still something interesting.

1 answer

3


TL;DR: The selector .media__bd--gretting h1{} is faster.

I say it’s faster based on a series of articles that I’m going to quote here, but it’s worth starting my answer by saying how complicated your question is, and how hard it is to get the jump right when building that answer. In the words of David Hyatt, architect of Safari and Webkit:

The Sad Truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page 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.

Which basically means that CSS3 selectors (which encompass your case of the :nth-child() should not be used if your focus is performance. This quote has been removed of this article, whereas 2009. If you read the article, you will see that the conclusion was that this type of optimization, when performed, results in little gain in speed, and that the cost-benefit ratio is practically zero. If, in 2009, the gain was little, imagine now, in 2015, with technology as a much more efficient whole.

I argued, in that reply, on good CSS practice. One of the points was about the bloating. I have already maintained in code where each element, however repetitive, had its own (and unique), 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 that was repeated by, believe it or not, 12 blocks, all with the same style rules. The end result is a huge and therefore inefficient code bloating. In this case, specifically, it was possible to reduce the CSS for:

.bloco1, .bloco2{
    .
    .
    .
}

which would already help to decrease the file size and the excess repetitivity 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 Cdisgust STyle SHeet, and you get a STyle SHeet, completely ignoring one of the most powerful Features when it comes to stylization.

This example illustrates that the greatest of the performance problems are not in the depth of specificity of the selector, but rather in a general scope of how great its entire application is, and the time it takes to render. This includes the optimization of everything, HTML, CSS and JS.

That publication (2014), brings with it a series of tests that were done on top of CSS, and what are the best (and worst) practices. An interesting reading, which leads to a number of nice conclusions, two of them being:

sweating over the selectors used in Modern browsers is futile; Most Selection methods are now so fast it’s really not worth spending Much time over. Furthermore, 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 faster dials than others? Yes. Sleepless nights are worth it because of it? No. The battle of speed will be won through the intelligence used to build your CSS (and its application as a whole) and the properties used, not in the milliseconds won if you use a pseudo-selector.

  • 1

    Very well clarified, because I played this question hypothetically thinking of an (DOM) extensive with the same element that would use a selector or other to style it. And without a doubt, putting together rules with a very large depth of specificity is out of the question thinking about a modular and reusable css and it demonstrates a certain discomfort with css not to say lack of experience or knowledge of the language that they say is so simple.

Browser other questions tagged css css3 performance selectors

You are not signed in. Login or sign up in order to post.