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.
#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
html body ul.nav li a
{
...
}
Same selector choice can be down to
.nav a
{
...
}
/*or*/
.nav a.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.
Leave a Reply