高性能CSS(三)
2013-11-12 15:03
337 查看
CSS选择器对性能的影响源于浏览器匹配选择器和文档元素时所消耗的时间,所以优化选择器的原则是应尽量避免需要消耗更多匹配时间的选择器。而在这之前我们需要了解CSS选择器匹配的机制,如例子的子选择器规则:
我们中的大多数人都是从左到右的阅读习惯,可能也会习惯性的设定浏览器也是从左到右的方式进行匹配规则,因为会推测这条规则的开销并不高。我们这样假象浏览器会像这样的方式工作:找到唯一的id为header为的元素,然后把这个样式规则应用到直系子元素中的a元素上。我们知道文档中只有一个id为header的元素,并且它只有几个a类型的子节点,所以这个CSS选择器应该相当高效。
事实上,却恰好相反,CSS选择器是从右到左进行规则匹配。了解这个机制后,例子中看似高效的选择器在实际中的匹配开销是很高的,浏览器必须遍历页面中所有的a元素并且确定其父元素的id是否为header。
如果把例子的子选择器改为后代选择器则会开销更多,在遍历页面中所有a元素后还需向其上级遍历直到根节点。
理解了CSS选择器从右到左匹配的机制后,可以理解选择器中最右边的规则往往决定了浏览器继续左移匹配的工作量,我们把最右边选择规则称之为关键选择器。
通配选择器使用 * 符合表示,可匹配文档中的每一个元素。如下例规则将所有元素的字体大小设置为20px:
通配选择器作用于所有的元素,如规则最右边为通配符:
浏览器匹配文档中所有的元素后分别向上逐级匹配class为selected的元素,直到文档的根节点,因此其匹配开销是非常大的,通常比开销最小的ID选择器高出1~3个数量级,所以应避免使用关键选择器是通配选择器的规则。
#header > a {font-weight:blod;}
我们中的大多数人都是从左到右的阅读习惯,可能也会习惯性的设定浏览器也是从左到右的方式进行匹配规则,因为会推测这条规则的开销并不高。我们这样假象浏览器会像这样的方式工作:找到唯一的id为header为的元素,然后把这个样式规则应用到直系子元素中的a元素上。我们知道文档中只有一个id为header的元素,并且它只有几个a类型的子节点,所以这个CSS选择器应该相当高效。
事实上,却恰好相反,CSS选择器是从右到左进行规则匹配。了解这个机制后,例子中看似高效的选择器在实际中的匹配开销是很高的,浏览器必须遍历页面中所有的a元素并且确定其父元素的id是否为header。
如果把例子的子选择器改为后代选择器则会开销更多,在遍历页面中所有a元素后还需向其上级遍历直到根节点。
#header a {font-weight:blod;}
理解了CSS选择器从右到左匹配的机制后,可以理解选择器中最右边的规则往往决定了浏览器继续左移匹配的工作量,我们把最右边选择规则称之为关键选择器。
通配选择器使用 * 符合表示,可匹配文档中的每一个元素。如下例规则将所有元素的字体大小设置为20px:
* { font-size:20px;}
通配选择器作用于所有的元素,如规则最右边为通配符:
.selected * {color: red;}
浏览器匹配文档中所有的元素后分别向上逐级匹配class为selected的元素,直到文档的根节点,因此其匹配开销是非常大的,通常比开销最小的ID选择器高出1~3个数量级,所以应避免使用关键选择器是通配选择器的规则。
相关文章推荐
- 高性能表现的div+css网站
- 高性能WEB开发(7) - JS、CSS的合并、压缩、缓存管理
- 高性能WEB开发 - JS、CSS的合并、压缩、缓存管理
- 高性能WEB开发 - JS、CSS的合并、压缩、缓存管理
- 高性能CSS(四)
- 高性能CSS
- 高性能CSS(一)
- 高性能CSS(二)
- 高性能CSS(四)
- 利用浏览器CSS渲染原理写出高性能的CSS代码
- 高性能CSS(二)
- 如何编写高性能CSS
- 关于移动Web应用程序开发 HTML5、高性能JavaScript篇、Css的几篇较好博客
- 高性能ASP.NET开发:自动压缩CSS、JS
- 书写高性能的css
- 高性能CSS
- 《web前端最佳实践》—高性能css
- 高性能WEB开发 JS、CSS的合并、压缩、缓存管理
- 高性能WEB开发- JS、CSS的合并、压缩、缓存管理
- 高性能WEB开发 - 了解CSS的查找匹配原理,让CSS更简洁、高效