Performance of CSS Selectors Is Still Irrelevant

Published on November 29, 2017 (↻ July 14, 2023), filed under (RSS feed).

For a teaser, a snippet from my upcoming book on CSS optimization [now available].

Selector performance is not something to optimize for. Selector performance is irrelevant. The price we pay for optimizing for selector performance is terrible: We micro-manage our work for gains that aren’t noticeable.

In 2009, Steve Souders contributed perhaps the first important results to the topic, and one of his main articles on the subject should have made more of us think. First, in his tests, even style sheets with 18,000 rules (!) were rendered within 600 ms (!). Then, Steve explained in quite clear terms, his hypothesis: “For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs.”

Perhaps people misunderstood when Steve went on to write, “There are some types of CSS rules and interactions with JavaScript that can make a page noticeably slower. This is where the focus should be.”—What we saw, namely, was an undue focus on selector performance and an outright childish ban of selectors, notably the universal selector.

(Years later, in additional investigations, we even find problems with the methodology, leading to important observations like this, by Ben Frain: “It is practically impossible to predict the final performance impact of a given selector by just examining the selectors.”)

The first problem with optimizing for selectors is that the gains are negligible. Yes, some selectors are slower than others, and from the way they work this is probably going to be the case until the world ends. Alas, nothing practically relevant follows from this observation: The effects are not felt by us nor by our end users. We do not ship websites that use 25,000 rules of the type of :after (and that’s it) to bring pages to a crawl; a) they don’t come to a crawl, b) who writes code like that has others issues.

The second problem with optimizing for selectors is that we over-optimize and micro-manage, and actually slow down our workflow and write worse CSS. Putting up rules in place for how selectors should look like is adding a cognitive restriction that only hinders a team of developers, and the outcome is not any more elegant code in terms of minimalism (though those of us who connect verbosity with understandability may have a point).

Where we are right now, selector performance is still a box better left closed.

Toot about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (where applicable) or a message.