If you’re a web developer, you may have already heard that some CSS selectors are faster than others. And you’re probably hoping to find a list of the better selectors to use in this article.
Well, not quite. But bear with me, I promise that by the end, you’ll have learnt something new about CSS selector performance.
A quick look behind the scenes
The way you write CSS selectors does play a role in how browsers render your web pages.
Whenever a part of your page changes, the browser engine that’s running it needs to take a look at the new DOM tree, and figure how to style it based on the available CSS stylesheets. This operation of matching styles to DOM nodes is called a style recalculation.
Without getting into a lot of details, the browser engine needs to look at all your rules and make decisions as to which ones apply to a given element. To do this, the engine needs to look at the rule selector, and this happens from right to left.
For example, when the engine sees a selector like`.wrapper .section .title .link`it will try to match the`link`class with the element first, and if that matches, then go up the chain from right to left to find an ancestor element with class`title`, then one with class`section`, and finally one with class`wrapper`.
This example illustrates that it’s likely faster for the browser engine to match just`.link`than it is to match this longer`.wrapper .section .title .link`selector. There are just fewer things to check.
Classes aren’t the only type of identifiers you can use in your CSS selectors of course. One interesting example is using attribute selectors and do substring matching like`[class*="icon-"]`.
This type of selector requires the browser engine to not only check if the element has a class attribute but also whether the value of this attribute contains the substring`icon-`. That’s another example of how different ways of writing selectors may require more or less work for the engine to apply CSS rules.
In practice, does it matter?
Maybe. This heavily depends on the web page, the size of the DOM tree, the amount of CSS rules, and whether the DOM changes often. There’s unfortunately no rule around this.
In fact, talking about rules, as an industry, we like inventing rules for what’s good and what’s bad. Rules help us make quick decisions and guide us when writing code and designing software. But they can also blind us from what’s really happening in our specific case.
When it comes to writing CSS selectors, strictly applying rules, or using a linter to do it automatically, may actually be counter-productive in some cases.
Overly complex CSS selectors, coupled with a huge DOM tree that changes a lot could very well lead to bad performance. But there’s a balance. Over-indexing on theoretical rules and changing selectors just to please your linter and hope for better performance may just be making your CSS harder to read and maintain, for not much actual gains.
So, write the code in a way that makes sense for your app, and is easy to read and maintain, and then measure the actual performance of your important user scenarios.
Read more
The truth about CSS selector performance
If you're a web developer, you may have already heard that some CSS selectors are faster than others. And you're probably hoping to find a list of the better selectors to use in this article. Well, not quite. But bear with me, I promise that by the
blogs.windows.com
