Contents
  1. 1. CSS后代选择器与子选择器的性能对比

CSS后代选择器与子选择器的性能对比

@(博客)[CSS]
昨天在做CSS的时候,要选择一个id为xxx的div里面的img。当时我不知道要用子类选择器好呢,还是用后代选择器好?我感觉子类选择器的效率会高一点。因为我觉得子类选择器的范围小一点。哈哈!但是事实是不是这样呢?
我们来看看以下文章:
高性能CSS,里面写到:避免通配选择器, 我们来看看。
CSS选择器对性能的影响源于浏览器匹配选择器和文档元素时所消耗的时间,所以优化选择器的原则是应尽量避免需要消耗更多匹配时间的选择器。而在这之前我们需要了解CSS选择器匹配的机制,如例子的子选择器规则:

1
2
3
#header > a {
font-weight: bold;
}

我们中的大多数人都是从左到右的阅读习惯,可能也会习惯性的设定浏览器也是从左到右的方式进行匹配规则,因为会推测这条规则的开销并不高。

我们这样假象浏览器会像这样的方式工作:找到唯一的id为header为的元素,然后把这个样式规则应用到直系子元素中的a元素上。我们知道文档中只有一个id为header的元素,并且它只有几个a类型的子节点,所以这个CSS选择器应该相当高效。

我开始就是以为是这样的。然而…

事实上,却恰好相反,CSS选择器是从右到左进行规则匹配。了解这个机制后,例子中看似高效的选择器在实际中的匹配开销是很高的,浏览器必须遍历页面中所有的a元素并且确定其父元素的id是否为header。
如果把例子的子选择器改为后代选择器则会开销更多,在遍历页面中所有a元素后还需向其上级遍历直到根节点。

1
2
3
#header a {
font-weight: bold;
}

  • 理解了CSS选择器从右到左匹配的机制后,可以理解选择器中最右边的规则往往决定了浏览器继续左移匹配的工作量,我们把最右边选择规则称之为关键选择器。

上面这点非常重要:CSS选择器从右到左匹配的机制!!!

知道这一点之后,我们就比较容易知道怎样去优化CSS性能了。一些常见的可以去看看高性能CSS

好了,总结一下。

看来我觉得子选择器的性能好一点是对的!不过,理解出了问题!现在知道CSS的选择器从右到左匹配的机制之后就更加清晰了。

既然了解了这种机制,所以我们写CSS的时候,就不要写太多级了,特别是最右为通配选择器的时候:

1
2
3
.mainDiv span a {
font-size: 20px;
}

这个时候就要先在遍历页面中所有a元素后还需向其上级遍历直到根节点,太累了!

参考AlloyTeam:http://www.alloyteam.com/2012/10/high-performance-css/

Contents
  1. 1. CSS后代选择器与子选择器的性能对比