I admit that I don't often think about this problem ... What is the efficiency of the CSS we write, and what is the speed of the browser rendering?
This should be the concern of the browser developer (the page loads faster and the user will be happier). Mozilla has an article: about best practices. Google is also very concerned about this issue, they also have an article: Optimize browser rendering.
Let's take a look at their main advocacy and then discuss their usefulness.
From right to left
The important principle of how browsers read your CSS selectors is that they read from right to left. This means this like UL > Li a[title= "Home"] such selectors, a[title= "Home" will be the first to be read. This section is often referred to as the last part of the "key selector" (which can be called the "target selector"-_-!) selector, as well as the selected label.
ID ' s is the most efficient, the common character is the slowest
There are four target selectors: ID, class, tag, and universal character. Look at how effective they are:
#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 * * And then we combine the concepts of right-to-left and target selectors, we can see that the following selector is not efficient:
#main-nav > Li {} * * looks very fast but actually very slow.
Although this is a bit confusing ... Because ID ' s is the most efficient, the browser can quickly find Li by ID. But the fact is, the LI tag is read first.
Do not use tags to decorate
Do not die as follows:
The following are the referenced contents: Ul#main-navigation {} |
ID ' s is unique, so it doesn't need to be decorated with tags, which only makes it less efficient.
If you can avoid it, do not use it to modify class. Class is not unique, so theoretically you can use it in a different label. If you want, you can use tags to control different styles, so you may need to label them (e.g. Li.first), but there are few people to do so, so, don ' t.
There's absolutely nothing worse than using a descendant selector.
David Hyatt:
The descendant selector is the most expensive selector in CSS and is prohibitively expensive-especially if it is behind a label and a generic character.
As the following this dongdong, absolute efficiency cancer:
The following are the referenced contents: HTML Body ul li a {} |
A selector render failure is more efficient than this selector is rendered
I'm not quite sure if there's any better evidence to prove it, because if you have a large number of selectors that can't be found in the CSS stylesheet, it seems bizarre, but it's important to note that the right to left explanation for a selector is that once it's not found, it stops trying. If it finds it, however, it will need to devote more effort to explaining it.
Just imagine why you wrote the selector.
Think of this stuff:
The following are the referenced contents: #main-navigation Li a {font-family:georgia, Serif;} |
You may not need to start with a selector (if you just want to change the font). This may be more efficient:
The following are the referenced contents: #main-navigation {font-family:georgia, Serif;} |
Practicability
Also engraved on the previous one of Mozilla's article? It's been 10 years. The fact is: the computer is slower than it was 10 years ago (either I misunderstood it or the author wants to say that the web is getting more and more complicated now). I feel that this stuff seems to have been more valued. Ten years ago I was a 21-year-old handsome, of course, I do not think there I will know the CSS this stuff. So I can't tell you what happened before ... But I think the problem of rendering efficiency is not taken seriously because it's never been a big problem.
Here are some of my ideas: Whatever the above mentioned is meaningful, you can follow the above method, because it does not limit your CSS production. But you don't need to be too dogmatic. If you're a perfectionist and haven't thought about that stuff before, it's time to take a look at some of the styles you've written earlier that have improved. If you do not find your site obvious rendering slow, that can not be too concerned about, in the future work more attention on the line.
Super fast, 0 practicality
We know that ID ' s is the most efficient selector. When you want to make the rendering speed the most efficient, you may configure each individual label with an ID and write the style with those IDs. That would be super fast and super absurd. The result is that the semantics are extremely poor and the maintenance is hard to reach. Even in the core you should not have seen it done. I think this will remind us not to give up semantics and maintainability for efficient CSS.
"Jason Beaudoin for emailing me about the" idea. If anyone knows more about this stuff, or if your have additional tips that for you with this same vein, let ' s hear it!
By the way, because CSS selectors are used by a lot of JavaScript libraries, the stuff mentioned above still works, the ID selector is the fastest, and the descendant selector and the similar stuff are slow.
PS: See who dares to use n many descendants selector, as well as against me with ID!