Performance improvement by writing efficient CSS selector

The web is moving from desktop to mobile and performance has become the key focus area in web development. All the UI Developers try to write maintainable, semantics and efficient CSS. But when UI developer becomes dogmatic about the standards, it cost the performance. I don’t mean here that; following the standards degrades the performance. But, along with following the standards and understanding how the browsers render it; can improve the performance.

Standard CSS specification does not specify how browser should render it, It only say what must to do.

Cool document tree selectors

There are many good document tree selectors in CSS that making UI, developer’s life easy and helping style the elements while keeping code clean and semantic. It help a lot in a CMS site and to change the legacy code of a site or application.

Child selector – div > p

Descendant selector – div p

Sibling selector – div + p, div ~ p

Attribute selector – input[type=”text”], h1[rel=”external”]

Pseudo selector – p:first-child

But every good thing comes at a cost. And here, the cost is performance. These selectors take more browser resources to use. Developing a site where single microsecond delay is counted as a performance hit. In such sites these fancy selector should be used very carefully.

These selectors are very handy and incredibly awesome for clean and semantic code. And it cannot be avoided altogether. But performance can be improved by understanding, how the browser read these selectors and how it renders.

CSS Selectors and rendering efficiency

All the selectors have its own inherent efficiency. Here is the order of more to less efficient CSS selector.

ID – #header

Class – .header

Tag – div

Sibling – div + p, div ~ p

Child – div > p

Descendant – div p

Universal – div *

Attribute – input[type=”text”]

Pseudo – p:first-child

ID is considered the most efficient selector but ID and class have very little difference in reflow speed. And using a tag selector makes a big difference in performance and so forth go on, if you go more down to make a selector choice.

How selector hit the performance and browsers rendering

While writing a selector we write and read it from left to right, but browser engine read selectors from right to left. Browser first, looks for the children and then checks for the parents.

1

2

3

4

#header a

{

...

}

Rightmost selector is called the key selector which is read by the browser first. Browser will read all the thousands of anchor before reading 4-5 links within #header.

Overqualified selector kills

Browser engine start reading from key selector then it go to the left. This information can be used to optimize the selector further. An overqualified selector may be like “div.portfolio“, same selector can be chosen by just using “.portfolio“. Another example of overqualified selector might be

1

2

3

4

html body ul.nav lia

{

...

}

Same selector choice can be down to

1

2

3

4

5

6

7

8

9

.nava

{

...

}

/*or*/

.nava.someclass

{

...

}

Using this selector browser need not to read the extra selector html, body and ul.

Conclusion

Choosing the right selector in css can improve the performance, however this is micro optimization. But it can be a performance hit if there are massive amount of selectors. It’s not going to make much difference if you are making your portfolio site, but it of course makes difference, if you are going to create next Amazon site where a microsecond delay can make a difference.

I’m not sure if the payoff for efficient CSS is more than a few microseconds (as your article notes). However, having the CSS be well-organized can pay big dividends for the developer in terms of future maintenance effort. Time spent on optimizing might be better spent on the JavaScript.

I only use “ID” when required. It simply has too much weight relative to other selectors to be used casually. I can get by using classes and tag selectors almost exclusively.

I am absolutely agreed with your point “having the CSS be well-organized can pay big dividends for the developer in terms of future maintenance effort.” But along with well-organized CSS, if a CSS developer can take care of those micro seconds delay; can pay bigger dividends by avoiding overqualified selector, universal selector, Descendant selectors and more.

I understand these selectors help to write a well-organized CSS but in many scenarios it can be avoided while maintaining the well-organized CSS. Thanks, for your inputs and corrections.

Let me ask you this: in a global CSS file, do you think using selectors like “body.page1 li.something,” “body.page2 li.anotherthing” are more or less efficient than just skipping the body/class selector?

If as per the structure, it is really required to maintain the well-organized CSS. I would go with the selector, you have mentioned. But if “.page1 .something” is doing the same work, I don’t think it make sense to impose “body” and “li” in the selector.

Good point, except (IMO) the use of the ID as a selector. IDs have 10 times the weight in CSS as classes do and can be a real pain. I stopped using them unless they’re needed for a named anchor or something else not related to CSS (not sure what else).

I was trying to get your opinion on targeting particular pages for a selector (or excluding others, conversely). Would that be more efficient in terms of the CPU cycles? Once again, it seems like gains in this area would be nano-gains.

You can find a few other article on speed-enhancing your CSS using Google. I can’t recall reading about speed-enhancing CSS in any of the books that I’ve read. The implication that I got is that you can be fairly profligate with regard to CSS speed. I’ve always been impressed by the speed with which all browsers interpret CSS.

On the other hand, older versions of MSIE are hideous at processing JavaScript. And we all know why not to use tables unless the situation explicitly calls for them. Those are some obvious speed problems.