首先，CSS 的读取顺序是 从右向左
举个例子
它的读取顺序是：
那么，为什么读取顺序是从右向左呢？
举个例子：
假如 DOM 结构如上图，
假设匹配规则是 .mod-nav h3 span
如果从左向右匹配，过程是：
如果从右向左匹配：
总结：这是一个树形结构，很明显，从 child 开始找 parent 比从 parent 找 child 要高效
CSS 的后代选择器本身就是一种在标准里面不那么推荐的方式。首先，对浏览器来说，ID 选择器 #xx 是最快的，其次是 class 选择器、html 元素选择器等。
假如 DOM 的结构如上图，匹配规则是 .mod-nav h3 span。
若从左向右的匹配，过程是：从 .mod-nav 开始，遍历子节点 header 和子节点 div，然后各自向子节点遍历。在右侧 div 的分支中，最后遍历到叶子节点 a ，发现不符合规则，需要回溯到 ul 节点，再遍历下一个 li-a，假如有 1000 个 li，则这 1000 次的遍历与回溯会损失很多性能。
再看看从右至左的匹配：先找到所有的最右节点 span，对于每一个 span，向上寻找节点 h3，由 h3再向上寻找 class=mod-nav 的节点，最后找到根元素 html 则结束这个分支的遍历。
很明显，两种匹配规则的性能差别很大。之所以会差别很大，是因为从右向左的匹配在第一步就筛选掉了大量的不符合条件的最右节点（叶子节点）；而从左向右的匹配规则的性能都浪费在了失败的查找上面。
当然这是比较明显情况，如果在叶子上存在多个不符合条件的 span，从右向左的规则也会走一些弯路（这时就需要优化 CSS 选择器了）。但平均来说它还是更高效，因为大多时候，一个 DOM 树中，符合匹配条件的节点（如 .mod-nav h3 span）远少于不符合条件的节点。
首先我们要看一下选择器的「解析」是在何时进行的。
主要参考这篇「 How browsers work」（http://taligarsiel.com/Projects/howbrowserswork1.htm）来看，浏览器渲染的过程以 WebKit 为例大致如下：
HTML 经过解析生成 DOM Tree；而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree，最终用来进行绘图。Render Tree 中的元素（WebKit 中称为「renderers」，Firefox 下为「frames」）与 DOM 元素相对应，但非一一对应：一个 DOM 元素可能会对应多个 renderer，如文本折行后，不同的「行」会成为 render tree 种不同的 renderer。也有的 DOM 元素被 Render Tree 完全无视，比如 display:none 的元素。
在建立 Render Tree 时（WebKit 中的「Attachment」过程），浏览器就要为每个 DOM Tree 中的元素根据 CSS 的解析结果（Style Rules）来确定生成怎样的 renderer。对于每个 DOM 元素，必须在所有 Style Rules 中找到符合的 selector 并将对应的规则进行合并。选择器的「解析」实际是在这里执行的，在遍历 DOM Tree 时，从 Style Rules 中去寻找对应的 selector。
因为所有样式规则可能数量很大，而且绝大多数不会匹配到当前的 DOM 元素（因为数量很大所以一般会建立规则索引树），所以有一个快速的方法来判断「这个 selector 不匹配当前元素」就是极其重要的。
如果正向解析，例如「div div p em」，首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。
逆向匹配则不同，如果当前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配时，才会不断向上找父节点进行验证。
但因为匹配的情况远远低于不匹配的情况，所以逆向匹配带来的优势是巨大的。同时 也能够看出，在选择器结尾加上「*」就大大降低了这种优势，这也就是很多优化原则提到的尽量避免在选择器末尾添加通配符的原因。
