根据计算复杂性选择有效的选择(Choosing efficient selectors based

由于CSS处理细节，最值得注意的是RTL匹配和选择的效率 ，应该如何选择从渲染引擎性能的角度纯粹写的吗？

这应包括一般方面和包括使用或避免伪类，伪元素和关系选择器。

Answer 1:

在运行时在HTML文档被解析成含有DOM树N平均深度元件D 。 还有一个总的S中应用的样式表CSS规则。

1. 元素的样式应用于单独意思是有直接的关系N和整体复杂性 。 值得注意的，这可以通过浏览器逻辑来一定程度上抵消如引用缓存和再循环从样式相同的元件。 例如，下面的列表项将应用相同的CSS属性（假设无伪类如:nth-child被应用）：

    <ul class="sample"> <li>one</li> <li>two</li> <li>three</li> </ul> 

2. 选择匹配从右到左为单独的规则资格 - 即如果最右边的键不匹配的特定元素，就没有必要进一步处理选择，它被丢弃。 这意味着 ， 最右边的键应该与尽可能少的元素可能 。 下面， p描述符将匹配更多的元素，包括目标容器（其中，当然，不会有应用该规则，但仍然会导致有资格获得该特定选择器判断的更多的迭代） 以外的段落：

    .custom-container p {} .container .custom-paragraph {} 

3. 关系选择器： 后代选择需要支持多达D元素被遍历 。 例如，匹配成功.container .content可能只需要一个步骤应该元素是父子关系，但DOM树将需要遍历所有的方式，以html前一个元素可以被证实的不匹配和排除安全地丢弃。 这适用于链式后代选择为好，一些津贴。

   在另一方面，一>子选择，一个+相邻选择或:first-child仍然需要额外的元件进行评价，但只有一个的一个隐含的深度，绝不会需要进一步的树遍历。

4. 该行为定义伪元素如:before和:after意味着他们不是RTL模式的一部分。 逻辑的假设是，有本身无伪元素，直到一个规则指示为它之前或元素的含量（这又需要额外的DOM操作，但没有对选择本身相匹配，不需要额外的计算）后插入。

5. 我找不到对伪类，如任何信息:nth-child()或:disabled 。 验证元素的状态将需要额外的计算，但是从规则解析角度来看，这只会有意义他们从RTL处理中排除。

给定这些关系，计算复杂度O(N*D*S)应该主要通过最小化CSS选择的深度和解决上述第2点降低。 这将导致在可量化更强的改善相比，减少单独的CSS规则或HTML元素的数量^

浅，优选一个层次，具体选择器被处理得更快。 这是由谷歌（编程，不要用手！），比如很少有一个三键选择，大部分在搜索结果中的规则看起来像带到了一个全新的水平

#gb {}
#gbz, #gbg {}
#gbz {}
#gbg {}
#gbs {}
.gbto #gbs {}
#gbx3, #gbx4 {}
#gbx3 {}
#gbx4 {}
/*...*/

^ -而这是从渲染引擎性能的角度来看真正的，总有一些额外的因素，如交通的开销和DOM解析等。

来源： 1 2 3 4 5

文章来源: Choosing efficient selectors based on computational complexity