Sal*_*n A 8 html css performance css-selectors pagespeed
Google PageSpeed提出了一项建议,要求网络开发人员使用高效的CSS选择器:
避免匹配大量元素的低效键选择器可以加快页面呈现速度.
细节
当浏览器解析HTML时,它构造一个内部文档树,表示要显示的所有元素.然后根据标准的CSS级联,继承和排序规则,将元素与各种样式表中指定的样式进行匹配.在Mozilla的实现中(也可能是其他元素),对于每个元素,CSS引擎都会搜索样式规则以查找匹配项.引擎从右到左评估每个规则,从最右边的选择器(称为"密钥")开始并移动每个选择器直到找到匹配或丢弃规则.("selector"是规则应适用的文档元素.)
根据该系统,发动机评估的规则越少越好.[...].之后,对于包含大量元素和/或大量CSS规则的页面,优化规则本身的定义也可以提高性能.优化规则的关键在于定义尽可能具体的规则并避免不必要的冗余,以允许样式引擎快速查找匹配,而无需花时间评估不适用的规则.
此推荐已从当前的网页速度见解规则中删除.现在我想知道为什么这个规则被删除了.在此期间,浏览器是否能够有效地匹配CSS规则？这个建议是否有效？
这是一篇详尽的文章(2014年初的日期)
我引用了WebKit工程师Benjamin Poulain,他对CSS选择器性能测试有很多话要说:
大约10%的时间花在光栅化器上.大约21%的时间花在第一个布局上.大约48%的时间花在解析器和DOM树创建上~8%用于样式解析~5%用于收集样式 - 这是我们应该测试的内容以及大部分时间应该占用的内容.(剩余时间分布在许多小功能上)
他继续说道:
"我完全同意预先优化选择器是没用的,但原因完全不同:
通过检查选择器,几乎不可能预测给定选择器的最终性能影响.在引擎中,选择器被重新排序,拆分,收集和编译.要知道给定选择器的最终性能,您必须知道选择器收集在哪个桶中,如何编译它,以及最终DOM树是什么样的.
所有这些在各种引擎之间是非常不同的,使得整个过程更不可预测.
我反对Web开发人员优化选择器的第二个论点是它们可能会使事情变得更糟.关于选择器的错误信息量大于正确的跨浏览器信息.某人做正确事情的机会很低.
在实践中,人们发现CSS的性能问题并开始逐个删除规则,直到问题消失.我认为这是解决这个问题的正确方法,这很容易,并且会产生正确的结果."
有一些方法,例如BEM,它们将CSS建模为尽可能平坦,以最小化DOM层次结构依赖性并分离Web组件,以便它们可以在DOM中"移动"并且无论如何都可以工作.
小智 6
2011年2月,Webkit核心开发人员Antti Koivisto 对 Webkit中的CSS选择器性能进行了一些改进.
Antti Koivisto教授CSS样式选择器跳过兄弟选择器和更快的排序,这带来了一些小的改进,之后他又获得了两个非常棒的补丁:一个能够为树构建进行祖先标识符过滤,将样式匹配的剩余时间减半.典型的页面加载,以及简单选择器的快速路径,在某些网站上加速匹配另外50%.
CSS Selector性能已发生变化!(为了更好) Nicole Sullivan更详细地完成了这些改进.综上所述 -
根据Antti的说法,直接和间接相邻组合器仍然可能很慢,但是,祖先过滤器和规则哈希可以降低影响,因为这些选择器很少会匹配.他还说,webkit仍有很大的空间来优化伪类和元素,但无论它们比使用JavaScript和DOM操作尝试做同样的事情要快得多.事实上,虽然仍有改进的余地,但他说:
"在适度使用中,从样式匹配的角度看,一切都会表现得很好."
虽然浏览器在匹配CSS选择器方面要快得多,但值得重申的是CSS选择器仍应进行优化(例如尽可能保持"平坦")以减小文件大小并避免特殊性问题.