1 浏览器如何识别你的选择器
首先我们需要清楚，浏览器是如何读取选择器，以识别样式，并将相应的样式附于对应的HTML元素，达到美化页面的效果。Chris Coyier曾在《Efficiently Rendering CSS》一文中说过“浏览器读取你的选择器，遵循的原则是从选择器的右边到左边读取。换句话说，浏览器读取选择器的顺序是由右到左进行”。比如说：
div.nav < ul li a[title]
上面的实例来说，浏览器首先会尝试在你的HTML标签中寻找“a[title]”元素，接着在匹配“li和ul”，最后在去匹配“div.nav”。这就是前成所主的“选择器从右到左的原则”。
选择器的最后一部分，也就是选择器的最右边（在这个例子中就是a[title]部分）部分被称为“关键选择器”，它将决定你的选择器的效率如何？是高还是低。
那么如何让关键选择器更有效，性能化更高呢？其实很简单，主要把握一点“越具体的关键选择器，其性能越高”。
2 CSS选择器的效率
如 果你阅读了本站的有关于选择器类型的介绍的话，你对选择器并不会感到陌生。就算你没读过，我想CSS选择器不会让我们觉得是新东西，比如我们常用的基本选 择器“元素标签选择器div”、“id选择器#header”、“类选择器.class”，或者说我们很少见的伪类选择器“:focus”以及更复杂的 css3选择器“:nth-child”等等。
选择器有一个固有的效率，我们来看Steve Souders给排的一个顺序：
id选择器（#myid）
类选择器（.myclassname）
标签选择器（div,h1,p）
相邻选择器（h1+p）
子选择器（ul > li）
后代选择器（li a）
通配符选择器（*）
属性选择器（a[rel="external"]）
伪类选择器（a:hover,li:nth-child）
上面九种选择器的效率是从高到低排下来的，基中ID选择器的效率是最高，而伪类选择器的效率则是最低。
我们不得不提的是，纵使ID选择器很快、高效，但是它也仅仅如此。从Steve Souders的CSS Test我们可以看出ID选择器和类选择器在速度上的差异很小很小。
我们知道ID’s 是最高效的选择器。当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那会超级快，也超级荒唐。这样的结果是语义 极差，维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性。
3 书写规范
A 不要用标签修饰ID
死也不要像下 面这样干：
ul#main-navigation { }
ID’s 是唯一的，所以不需要用标签修饰，这只会让它更低效。
如果你可以避免的话，也不要用它修饰 class 。class 不是唯一的，所以理论上你可以把它用在不同的标签。如果你愿意的话，你可以用标签控制不同的样式，这样你可能需要标签修饰（比如：li.first），但 这样做的人很少，所以，don’t .
B 绝对没有比用后代选择器更糟糕的做法了
David Hyatt:
后代选择器是CSS里最昂贵的选择器，昂贵得可怕——特别是当它放在标签和通用符后面时。
就如下面这个东东一样，绝对的效 率毒瘤：
html body ul li a { }
C 一个选择器渲染失败比这个选择器被渲染更高效
我不是很确定是否有更好的证据去证明这一点，因为如果你有大量的选择 器在CSS样式表里无法找到，这样的事情貌似很离奇，但一点必需注意的是，从右到左的解释一个选择器来说，一旦它找不到，那它就会停止尝试。然而如果它找 到了，那它就需要花更多精力去解释了。
D 试想一下为何你这样写选择器
思考 下这东东：
#main-navigation li a { font-family: Georgia, Serif; }
你可能不需要从 a 选择器开始（如果你只是想换个字体）。下面这个可能更高效些：
#main-navigation { font-family: Georgia, Serif; }
E 不要过度限制选择器
拥有一个明确的关键选择器最大的好处就是你可以避免使用过度限制选择器。一个过度限制选择器可能像：
html body .wrapper #content a {}
这里的写的太多了，至少3个选择器是完全不需要的。它可以最多像这个样子：
#content a {}
一些更现实的例子：#nav li a{}变成这个：#nav a {}
我们知道如果a在li里面，它也必定在#nav里面，所有我们可以马上把li从选择器组中拿掉。然后，既然我们知道在页面中只有一个ID为nav的元素，那么它依附的元素就是完全没有关系得了，我们也可以拿掉ul
过度限制选择器使浏览器工作比它实际需要的更繁重，花费的时间更多。我们可以删掉不必需的限制，来使我们的选择器更简单和高效。
4 案例详解：
假设你有一个复杂的页面，它相当巨大并且在你的一个很大很大的站点上。在那个页面上有成百上千甚至上万的 a 标签。它还有一个小的社交链接区域放在一个ID为#social的Ul里面。我们假设它们是Twitter，Facebook，Dribbble还有 Google+的链接吧。在这个页面上我们有四个社交链接和成百上千的其他链接。 下面的这个选择器就自然的不是那么高效和合理了：#social a {…}
这里发生的情况是浏览器会在定位到#social区域下的四个链接之前得到页面上所有成千上万的链接。我们的关键选择器匹配了太多我们不感兴趣的其他元素。
为了补救我们可以给每个在社交链接区域的 a 增加一个更特殊、明确的选择器 .social-link , 但是这好像有点违背我们的认知：当我们能用组合选择器的时候就不要放不必要的类标示在元素上。
这就是为什么我对选择器的性能如此感兴趣的原因了：必须在web 标准最佳实践和速度之间的保持平衡。
<ul id="social"> <li><a href="#" class="twitter">Twitter</a></li> <li><a href="#" class="facebook">Facebook</a></li> <li><a href="#" class="dribble">Dribbble</a></li> <li><a href="#" class="gplus">Google+</a></li></ul>CSS:#social a {}
改变后：
<ul id="social"> <li><a href="#" class="social-link twitter">Twitter</a></li> <li><a href="#" class="social-link facebook">Facebook</a></li> <li><a href="#" class="social-link dribble">Dribbble</a></li> <li><a href="#" class="social-link gplus">Google+</a></li></ul>CSS:#social .social-link {}
这个新的关键选择器将会匹配更少的元素，这意味着浏览器能够很快的找到它们并渲染特定的样式，然后专注于下一件事。
另外，事实上我们可以用.social-link{}更清晰的选择，而不是过分限制它。