Google PageSpeed提出了一项建议，要求网络开发人员Use efficient CSS selectors：
避免匹配大量的低效键选择器 元素可以加快页面渲染速度。
详情
当浏览器解析HTML时，它会构造一个内部文档树 表示要显示的所有元素。然后匹配 根据各种样式表中指定的样式的元素 标准CSS级联，继承和排序规则。在Mozilla的 对于每个元素，实现（以及可能还有其他的） CSS引擎搜索样式规则以查找匹配项。引擎 从最右边开始，从右到左评估每条规则 选择器（称为＆＃34;键＆＃34;）并移动每个选择器直到它 找到匹配项或丢弃规则。 （＆＃34;选择器＆＃34;是文档 规则应适用的元素。）
根据该系统，引擎必须评估的规则越少 更好。 [...]。之后，对于包含大量的页面 元素和/或大量CSS规则，优化定义 规则本身也可以提高性能。关键 优化规则在于定义特定的规则 可能并避免不必要的冗余，以允许风格 引擎快速查找匹配而无需花时间评估规则 那不适用。
此推荐已从当前Page Speed Insights rules中删除。现在我想知道为什么这个规则被删除了。在此期间，浏览器是否能够有效地匹配CSS规则？这个建议是否有效？
答案 0 :(得分：7)
这是thorough article（2014年初的日期）
我引用的是 Benjamin Poulain ，一位WebKit工程师，对CSS选择器性能测试有很多话要说：
在光栅化器中花费了大约10％的时间。大约21％的时间花在了上面 在第一个布局上。大约48％的时间花在解析器和DOM上 树的创造〜花费在风格分辨率上的8％〜花费了5％ 收集风格 - 这是我们应该测试和什么 应该占用大部分时间。 （剩下的时间分布在很多人身上 许多小功能）
他继续说道：
“我完全同意预先优化选择器是没用的，但是 出于完全不同的原因：
实际上不可能预测最终的性能影响 通过检查选择器来选择给定的选择器。在引擎中， 选择器被重新排序，拆分，收集和编译。要知道 给定选择器的最终性能，您必须知道 收集选择器的桶，如何编译，以及 最后DOM树是什么样的。
各种引擎之间的所有这些都是非常不同的 整个过程更难以预测。
我对Web开发人员优化选择器的第二个论点 是他们可能会让事情变得更糟。大量的 关于选择器的错误信息大于正确的跨浏览器 信息。有人做正确事情的机会很大 低。
在实践中，人们发现CSS的性能问题并开始 逐个删除规则，直到问题消失。我想是的 正确的方法，这很容易，并将导致正确 结果“。
有一些方法，例如BEM，它们将CSS建模为尽可能平坦，以最小化DOM层次结构依赖性并分离Web组件，以便它们可以在DOM中“移动”并且无论如何都可以工作。
答案 1 :(得分：6)
2011年2月，Webkit核心开发人员Antti Koivisto made several improvements在Webkit中进行CSS选择器性能。
Nicole Sullivan的Antti Koivisto教授CSS样式选择器跳过兄弟选择器和更快的排序，这带来了一些小的改进，之后他获得了两个更棒的补丁：一个可以为树构建启用祖先标识符过滤，将样式中的剩余时间减半匹配典型的页面加载，以及简单选择器的快速路径，在某些网站上加速匹配另外50％。
CSS Selector Performance has changed! (For the better)更详细地介绍了这些改进。总之 -
根据Antti的说法，直接和间接相邻组合器仍然可能很慢，但是，祖先过滤器和规则哈希可以降低影响，因为这些选择器很少会匹配。他还说，webkit仍有很大的空间来优化伪类和元素，但无论它们比使用JavaScript和DOM操作尝试做同样的事情要快得多。事实上，虽然仍有改进的余地，但他说：
“在审核中使用几乎从样式匹配的角度看，一切都会很好。”
虽然浏览器在匹配CSS选择器方面要快得多，但值得重申的是CSS选择器仍然应该进行优化（例如，保持尽可能平坦）以减少文件大小并避免特异性的问题。
答案 2 :(得分：0)
也许是因为为CMS或框架做CSS现在更常见，因此很难避免使用通用的CSS选择器。这样可以限制样式表的复杂性。
此外，现代浏览器在渲染CSS方面非常快。即使IE9上有大量的样式表，也不觉得渲染速度很慢。 （我必须承认我在一台好电脑上测试过。也许有基准测试。）
无论如何，我认为你必须编写非常低效的CSS来放慢Chrome或Firefox ......
的表现中有2年的帖子我喜欢他的一句话结论：在＃34;范围内的任何事情，是的，这个CSS有意义＆＃34;没关系。