I admit that I don't often think about this question... How efficient is the CSS we write, and how fast is the browser rendering?
This is what browser developers should be concerned about (pages load faster, and users will be happier). Mozilla has an article: about best practices . Of course Google is also very concerned about this issue, and they also have such an article: Optimize browser rendering .
Let’s take a look at what they mainly advocate, and then discuss their practicality.
right to left
An important principle of how browsers read your CSS selectors is that they read them from right to left. This means that for a selector like ul > li a[title="home"], a[title="home"] will be read first. This part is usually called the "key selector" (can it be called the "target selector" -_-!) The last part of the selector is also the selected label.
ID's are the most efficient, universals are the slowest
There are four target selectors: ID, class, tag and universal character. Let’s take a look at their respective efficiencies:
#main-navigation { } /* ID (fastest) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (slowest) */
#content [title='home'] /* Universal */ Then we combine the concepts of right-to-left and target selectors, and we can know that the following selector is not efficient:
#main-nav > li { } /* It looks fast but is actually very slow*/
Although this is a bit confusing... because ID's are the most efficient, browsers can quickly find li by ID's. But the fact is that the li tag is read first.
Don’t modify it with tags
Don't do this to your death:
ul#main-navigation { }
ID's are unique, so don't need to be decorated with tags, which just makes it less efficient.
Don't use it to modify classes if you can avoid it. class is not unique, so in theory you could use it in different tags. If you want, you can use tags to control different styles, so you may need tag modifications (eg: li.first), but few people do this, so don't.
There is absolutely nothing worse than using a descendant selector
David Hyatt:
The descendant selector is the most expensive selector in CSS, and it's prohibitively expensive - especially when placed after tags and universals.
Just like the following stuff, it is an absolute cancer of efficiency:
html body ul li a { }
It is more efficient for a selector to fail to render than for the selector to be rendered
I'm not sure if there's any better evidence for this, because if you have a lot of selectors that can't be found in a CSS stylesheet, it might seem bizarre, but it's important to note that right to left To paraphrase a selector, once it can't find it, it stops trying. However, if it is found, it will take more effort to explain.
Just think about why you write the selector like this
Think about this:
#main-navigation li a { font-family: Georgia, Serif; }
You probably don't need to start with a selector (if you just want to change the font). This might be more efficient:
#main-navigation { font-family: Georgia, Serif; }
Practicality
Also engraved the Mozilla article mentioned earlier? It's been ten years. The fact is: computers are slower than ten years ago (not that I misunderstood, or the author wants to say that the current WEB is becoming more and more complex). I feel like this stuff seemed to be taken more seriously back then. Ten years ago, I was a handsome 21-year-old boy. Of course, I didn’t think I would know anything about CSS there. So I can't tell you about the previous situation...but I think the reason why the issue of rendering efficiency was not taken seriously is because it has never been a big issue.
Here are some of my opinions: No matter what, the stuff mentioned above makes sense, and you can do it according to the above method, because it does not limit your CSS production. But you don’t have to be too dogmatic. If you are a perfectionist and have not considered that stuff before, it is time to re-look at some of the styles you have written before to see if there is room for improvement. If you don't find that your website is obviously rendering slowly, don't pay too much attention to it. Just pay more attention to it in future work.
Super fast and zero practicality
We know that ID's are the most efficient selectors. When you want to maximize rendering speed, you might configure an ID for each individual tag and then use these IDs to write styles. That would be super fast and super ridiculous. The result is extremely poor semantics and extremely difficult to maintain. You shouldn't see this done even at the core. I think this serves as a reminder not to give up semantics and maintainability for efficient CSS.
Thanks to Jason Beaudoin for emailing me about the idea. If anyone knows more about this stuff, or if you have additional tips that you use in this same vein, let's hear it!
By the way, because CSS selectors are used by many JavaScript libraries, the stuff mentioned above still applies, the ID selector is still the fastest, and the descendant selectors and similar stuff are slower.
PS : Let’s see who dares to use more than N descendant selectors. . . There are also people who object to my use of ID. . . Wow haha. . .