>元素的样式是单独应用的,这意味着N与整体复杂性之间存在直接关系.值得注意的是,这可以通过浏览器逻辑(例如参考缓存和来自相同元素的回收样式)进行一定程度的抵消.例如,以下列表项将应用相同的CSS属性(假设不应用伪类,例如：nth-​​child)：

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

>选择器从右到左匹配单个规则资格 – 即如果最右边的键与特定元素不匹配,则不需要进一步处理选择器并将其丢弃.这意味着最右边的键应该尽可能少的元素匹配.下面,p描述符将匹配更多元素,包括目标容器之外的段落(当然,这将不适用规则,但仍会导致更多的特定选择器的资格检查迭代)：

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

>关系选择器：后代选择器需要迭代最多D个元素.例如,如果元素处于父子关系中,成功匹配.container .content可能只需要一步,但是在确认元素不匹配之前,需要遍历到DOM树一直到html.规则安全丢弃.这也适用于链式后代选择器,有一些余量.

另一方面,a>子选择器,相邻的选择器或：first-child仍然需要一个额外的元素进行评估,但只有一个暗示的深度,并且永远不需要进一步的树遍历.
> behavior definition个伪元素如：before和：after意味着它们不是RTL范例的一部分.该假设的逻辑是,在规则指示在元素的内容之前或之后插入它之前,本身不存在伪元素(这反过来需要额外的DOM操作,但是不需要额外的计算来匹配选择器本身).
>我找不到关于伪类的任何信息,例如：nth-​​child()或：disabled.验证元素状态需要额外的计算,但从规则解析的角度来看,只有从RTL处理中排除它们才有意义.

给定这些关系,主要通过最小化CSS选择器的深度和上面的点2来降低计算复杂度O(N * D * S).与最小化CSS规则或HTML元素的数量相比,这将导致可量化的更强的改进^

浅,优选一级特定选择器处理更快.谷歌(以编程方式,而不是手动)将其提升到一个全新的水平！例如,很少有三键选择器,搜索结果中的大多数规则看起来像

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

^ – 虽然从渲染引擎性能的角度来看这是真的,但总会有其他因素,例如流量开销和DOM解析等.

资料来源：1 2 3 4 5