Efficient CSS writing

This article has been in the draft box for a long time. Let's take a look at it and release it. This is a translation article. The original Article here is Efficiently Rendering CSS.

How efficient is CSS we write? In other words, how fast will the browser render our CSS? I admit that I have not considered much about this issue.

This problem should have been taken into consideration by browser vendors-The faster their browsers are, the more users like to use their products. Mozilla has an article on this best practice, and Google, which has always insisted that the Web should be faster, also has an article.

Let's take a look at some of their main points of view and discuss the practical value of these principles.

From right to left

How does the browser read your CSS selector? The most important thing we need to understand is from right to left. For example, this Selectorul > li a[title="home"]First, the browser readsa[title="home"]. The first read part is called it.key selectorIt is the most important element in the browser.

The fastest ID and the slowest Universal ID

There are four typeskey selector, The resolution speed is from fast to slow: ID, class, tag, and universal

# Main-navigation {}/* ID (fastest )*/
Body. home # page-wrap {}/* ID */
. Main-navigation {}/* Class */
Ul li a. current {}/* Class *
Ul {}/* Tag */
Ul li a {}/* Tag */
* {}/* Universal (slow )*/
# Content [title = 'home']/* Universal */

If we combine this principle with the right-to-left mode, we will find that the selector below is not very fast.

# Main-nav> li {}/* is slower than it looks */

This is really against our instincts... Because the ID is fast, we intuitively think that the browser will quickly find#main-navAnd find its child.li. But in fact, the browser's first Parsing is relatively slow.li

Do not tag-qualify

Never do this

ul#main-navigation {  }

IDs are already unique and do not need tags for identification. This will make the selector slower.

If you can, try not to use it on the class. The class is not unique. You can use it to process many different elements. If you want elements of the same class to have different styles, you may need tag-qualify (for exampleli.first), But this is rare.

Worst descendant Selector

David Hyatt said so.

The
Descendant selector is the most expensive selector in CSS. It is
Dreadfully expensive-especially if the selector is in the Tag or
Universal Category.

In other words, the following selector is very inefficient.

html body ul li a {  }

Selector with failed matching is more efficient

I don't know what we can learn from it. It's not surprising to write a lot of useless things in my CSS file. But it should be noted that when a selector is parsed from the right to the left, if no matching result is found, the browser will stop the next action, so it is more efficient...

Why are you writing this?

Consider such a selector

#main-navigation li a { font-family: Georgia, Serif; }

font-familyIt can be cascaded, so you may not need such a special selector at all (if you just want to change the font ). This will be more efficient and more efficient.

#main-navigation { font-family: Georgia, Serif; }

Efficiency of CSS3

Some of David Hyatt's ideas:

The sad truth about CSS3 selectors is that they really shouldn't be used at all if you care about page performance.

CSS3 selector (for example, nth-child) can effectively locate the elements we want and ensure that our CSS is neat and easy to read. However, these magic selectors will waste a lot of browser resources.

What should we do? Shouldn't we use them? Let's consider some practical things.

Practicality

Note
Do I have to go through the Mozilla article I listed above? It takes 10 years. In fact, the computer was very slow 10 years ago. I think these are important things in the past. I was 21 years old 10 years ago, I
I don't even know what CSS is or how to translate CSS... I think we seldom talk about the efficiency of CSS rendering, maybe because it is no longer a big problem.

I think so: in any case, the best practices we mentioned above are useful. You can follow these rules because they do not limit your CSS capabilities. But they do not have to be executed as dogmas.

If your website is very slow and you haven't considered these CSS best practices before, you may need to check your CSS. If your website does not show any signs of slowness, you can ignore it and pay attention to it later when writing CSS.

Fast but not practical

Me
We know that ID is the most efficient selector. If you want to render the fastest web page, you can give each element a unique ID on the page, and then style every ID. This will be super fast, but it will also
Extremely funny. This may make it difficult to read and maintain your CSS files. This method is hard to see on hard-coded websites with high performance requirements. We should not sacrifice readability and maintainability for efficiency
Protection.

Jason Beaudoin tells me these ideas. If someone knows more about things or you need to add something, let us know.

To put it simply, many JavaScript libraries use CSS selectors, and the above principles still apply. ID is the fastest, and the complex descendant selector is slow.