请记住，当浏览器进行选择器匹配时，它具有一个元素（它正在尝试确定其样式的元素）以及所有规则及其选择器，并且它需要查找与该元素匹配的规则。这与通常的jQuery不同，例如，您只有一个选择器，并且需要查找与该选择器匹配的所有元素。

如果您只有一个选择器，并且只有一个要与该选择器进行比较的元素，那么从左到右在某些情况下更有意义。但这绝对 不是
浏览器的情况。该浏览器正在尝试呈现Gmail或其他内容，并且<span>正在尝试设置其样式，并且Gmail在其样式表中添加了10,000多个规则（我没有增加这个数字）。

特别是在这种情况下，浏览器正在查看考虑的大多数选择器，它们与所讨论的元素 不
匹配。因此，问题就成为了决定选择器与匹配项的匹配程度是否尽可能快的问题之一。如果在不匹配的案例中需要做一些额外的工作，则由于在不匹配的案例中保存的所有工作，您仍然会获胜。

如果您仅通过将选择器的最右边部分与您的元素进行匹配而开始，那么它可能会不匹配并且您已经完成了。如果匹配，则您需要做更多的工作，但只与树的深度成比例，在大多数情况下，树的深度并不大。

另一方面，如果您从匹配选择器的最左边开始，您将与之匹配什么呢？您必须开始遍历DOM，寻找可能与之匹配的节点。只是发现最左边部分没有匹配项可能需要一段时间。

因此，浏览器从右边匹配；它提供了一个明显的起点，使您可以很快地摆脱大多数候选选择器。您可以在http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665上看到一些数据（尽管表示法令人困惑），但结果是特别针对Gmail两年前，对于70％的（规则，元素）对，您只需检查规则最右边选择器的标记/类/标识部分，就可以确定该规则不匹配。Mozilla的页面加载性能测试套件的相应数字为72％。因此，真的有必要尝试尽快消除所有规则的2/3，然后再担心匹配其余1/3。

还要注意，浏览器已经做了其他优化，甚至可以避免匹配绝对不匹配的规则。例如，如果最右边的选择器具有一个ID，并且该ID与元素的ID不匹配，则在壁虎中根本不会尝试将该选择器与该元素进行匹配：尝试的“具有ID的选择器”集合来自对元素ID的哈希表查找。因此，仅考虑最右边选择器的标记/类/
ID，这就是70％的规则很有可能匹配， 但仍然 不匹配。