养成使用jQuery Sizzle选择器的良好习惯
jquery 1.3将选择器引擎独立，定名为Sizzle，这也是jQuery第一个独立的模块。在Sizzle的介绍里，关于它的首要目的就是
在"最常用的选择器使用"比之前版本的引擎更快。(什么是"最常用的选择器使用"，请参见 http://ejohn.org/blog/selectors-that-people-actually-use )
实际上，选择器引擎的运用对于页面性能起了至关重要的作用。使用合适的选择器表达式可以轻易的提高性能、增强语义并简化逻辑，而你所需要做的，不过是培养几个习惯而已。
==旧习惯==
我 们最常用的简单选择器包括"id选择器"、"类选择器"、"标签选择器"，毫无疑问的是id选择器有着最好的速度。这取决于dom内置的函数 getElementById,其次是标签选择器，使用的是dom内置的函数getElementsByTag，最差的是类选择器，其需要通过正则解析 html，并且需要在浏览器内核外递归，这种递归遍历是无法被优化的。
就需求来说，css中选择器是为了通过语义来渲染样式，而jQuery中大 部分情况只是为了选出一类DOMElement，加以同一逻辑的操作。而在"最常用的选择器使用"中，类选择器以13.082%的使用率排在第二位。也就 是说在13.082%的情况下，整个document的html被解析了一遍，并递归到DOM树的叶子节点。这部分无意义的性能损耗令人发指。
==最常用的选择器使用==
选择器
==最重要的四个建议习惯==
===以#id开始===
任何情况下，请从id选择器开始，哪怕不存在这个id，也请为选择器操作添加一个id。因为这样选择器会从一个相对末端的DOMNode开始。
===使用tag.class代替.class===
关于选择器性能，jQuery官方文档有这么一段描述：
For example, ".class" is far more popular than "tag.class" even though the second one is much more performant. What's especially important about this is that the degree of performance hit isn't that much of an issue. For example, the difference between 4ms and 30ms is virtually imperceptible.
标签是有限的，而类则可以看作是拓展标签的语义的一种方法，那么大部分情况下，使用同一个类的标签也是相同的。
===尽可能使用parent>child而非parent child===
">"是child选择器，只从子节点里匹配，不递归。而" "是后代选择器，递归匹配所有子节点及子节点的子节点(后代节点)。
==缓存选出的jQuery对象==
如果选出结果不发生变化的话，不妨缓存选出的jQuery对象，哪怕只有一会儿。比如下面的代码里，这种性能差异就被循环放大了，养成缓存jQuery对象的习惯可以让你在不经意间就完成主要的性能优化。
Code
如果养成以上四个习惯，我想我们的选择器性能已经优化了七成了。
下面介绍一些其他的选择器表达式建议。
==其他建议习惯==
===摒除表达式中的冗余部分===
类似于#id2 #id1 或者 tag#id1 的表达式中，都存在冗余部分，实际上只要#id1即可。
===选择特定的表单元素使用[name=x]===
虽 然name选择器写法上属于属性选择器，但是实际上普通的属性选择器使用的是递归遍历子节点来匹配，而name选择器解析优先级更高，并调用DOM内置函 数getElementsByName。虽然在IE和Opera里，指定了name但未指定id的DOMElement也会可以使用 getElementById得到，但是在jQuery里，为了保证跨浏览器，$("#id")会多做一次判断，把这些不一致的结果给过滤掉。所以 name选择器成了jQuery下的唯一选择。
===选择同一type的input元素使用[:type]===
这是唯一符合需要的简单写法。
===有条件的使用反向选择器===
反 向选择器是指类似于":not(exp)"的表达式。反向选择器实际上性能并不比同逻辑的正向选择器差很多。而在一些情况下，为了达到反向选择器的效果， 我们或许要写出很复杂的表达式，或需要添加额外的类，或需要选出结果后再筛选一遍。这都不如使用反响选择器，无论是在性能上还是在保持逻辑的简单上。而 jQuery 1.3里，反向选择器得到了增强，之前只可以接受简单的反向表达式。关于jQuery 1.3的变化，大家也可以参考( jQuery 1.3 发布 )
===有条件的使用prev + next===
在语义化的DOM里，我们常常使用结构来为两个DOMElement建立关系，以表达它们对应的实体的意义。
请参考下面的html片段
<div id="entities"><div id="entityid" class="entity"><div class="namelabel">name</div><div class="name">entityname</div></div></div>
当我们需要对所有.entity的.namelabel进行操作的的时候，我们可以用$("#entities>div.entity>div.namelabel")来选择。这里的关系就是通过.entity和.namelabel父子节点的结构来建立的。
不过有的时候我们无法选出一个合适的父节点来，例如<dt></dt><dd></dd>，或是<label></label><input/>。
其实相邻节点也是我们惯用的表达关系的结构，而且这种关系用jQuery选择器效率比父子选择器更好。
prev + next用来表示1对1的关系，在1对多的情况下，可以考虑使用prev ~ siblings
==结论==
在"最常用的选择器使用"比之前版本的引擎更快。(什么是"最常用的选择器使用"，请参见 http://ejohn.org/blog/selectors-that-people-actually-use )
实际上，选择器引擎的运用对于页面性能起了至关重要的作用。使用合适的选择器表达式可以轻易的提高性能、增强语义并简化逻辑，而你所需要做的，不过是培养几个习惯而已。
==旧习惯==
我 们最常用的简单选择器包括"id选择器"、"类选择器"、"标签选择器"，毫无疑问的是id选择器有着最好的速度。这取决于dom内置的函数 getElementById,其次是标签选择器，使用的是dom内置的函数getElementsByTag，最差的是类选择器，其需要通过正则解析 html，并且需要在浏览器内核外递归，这种递归遍历是无法被优化的。
就需求来说，css中选择器是为了通过语义来渲染样式，而jQuery中大 部分情况只是为了选出一类DOMElement，加以同一逻辑的操作。而在"最常用的选择器使用"中，类选择器以13.082%的使用率排在第二位。也就 是说在13.082%的情况下，整个document的html被解析了一遍，并递归到DOM树的叶子节点。这部分无意义的性能损耗令人发指。
==最常用的选择器使用==
选择器
| 使用率 | 统计数 | |
| #id | 51.290% | 1431 |
| .class | 13.082% | 365 |
| tag | 6.416% | 179 |
| tag.class | 3.978% | 111 |
| #id tag | 2.151% | 60 |
| tag#id | 1.935% | 54 |
| #id:visible | 1.577% | 44 |
| #id .class | 1.434% | 40 |
| .class .class | 1.183% | 33 |
| * | 0.968% | 27 |
| #id tag.class | 0.932% | 26 |
| #id:hidden | 0.789% | 22 |
| tag[name=value] | 0.645% | 18 |
| .class tag | 0.573% | 16 |
| [name=value] | 0.538% | 15 |
| tag tag | 0.502% | 14 |
| #id #id | 0.430% | 12 |
| #id tag tag | 0.358% | 10 |
==最重要的四个建议习惯==
===以#id开始===
任何情况下，请从id选择器开始，哪怕不存在这个id，也请为选择器操作添加一个id。因为这样选择器会从一个相对末端的DOMNode开始。
===使用tag.class代替.class===
关于选择器性能，jQuery官方文档有这么一段描述：
For example, ".class" is far more popular than "tag.class" even though the second one is much more performant. What's especially important about this is that the degree of performance hit isn't that much of an issue. For example, the difference between 4ms and 30ms is virtually imperceptible.
标签是有限的，而类则可以看作是拓展标签的语义的一种方法，那么大部分情况下，使用同一个类的标签也是相同的。
===尽可能使用parent>child而非parent child===
">"是child选择器，只从子节点里匹配，不递归。而" "是后代选择器，递归匹配所有子节点及子节点的子节点(后代节点)。
==缓存选出的jQuery对象==
如果选出结果不发生变化的话，不妨缓存选出的jQuery对象，哪怕只有一会儿。比如下面的代码里，这种性能差异就被循环放大了，养成缓存jQuery对象的习惯可以让你在不经意间就完成主要的性能优化。
Code
如果养成以上四个习惯，我想我们的选择器性能已经优化了七成了。
下面介绍一些其他的选择器表达式建议。
==其他建议习惯==
===摒除表达式中的冗余部分===
类似于#id2 #id1 或者 tag#id1 的表达式中，都存在冗余部分，实际上只要#id1即可。
===选择特定的表单元素使用[name=x]===
虽 然name选择器写法上属于属性选择器，但是实际上普通的属性选择器使用的是递归遍历子节点来匹配，而name选择器解析优先级更高，并调用DOM内置函 数getElementsByName。虽然在IE和Opera里，指定了name但未指定id的DOMElement也会可以使用 getElementById得到，但是在jQuery里，为了保证跨浏览器，$("#id")会多做一次判断，把这些不一致的结果给过滤掉。所以 name选择器成了jQuery下的唯一选择。
===选择同一type的input元素使用[:type]===
这是唯一符合需要的简单写法。
===有条件的使用反向选择器===
反 向选择器是指类似于":not(exp)"的表达式。反向选择器实际上性能并不比同逻辑的正向选择器差很多。而在一些情况下，为了达到反向选择器的效果， 我们或许要写出很复杂的表达式，或需要添加额外的类，或需要选出结果后再筛选一遍。这都不如使用反响选择器，无论是在性能上还是在保持逻辑的简单上。而 jQuery 1.3里，反向选择器得到了增强，之前只可以接受简单的反向表达式。关于jQuery 1.3的变化，大家也可以参考( jQuery 1.3 发布 )
===有条件的使用prev + next===
在语义化的DOM里，我们常常使用结构来为两个DOMElement建立关系，以表达它们对应的实体的意义。
请参考下面的html片段
<div id="entities"><div id="entityid" class="entity"><div class="namelabel">name</div><div class="name">entityname</div></div></div>
当我们需要对所有.entity的.namelabel进行操作的的时候，我们可以用$("#entities>div.entity>div.namelabel")来选择。这里的关系就是通过.entity和.namelabel父子节点的结构来建立的。
不过有的时候我们无法选出一个合适的父节点来，例如<dt></dt><dd></dd>，或是<label></label><input/>。
其实相邻节点也是我们惯用的表达关系的结构，而且这种关系用jQuery选择器效率比父子选择器更好。
prev + next用来表示1对1的关系，在1对多的情况下，可以考虑使用prev ~ siblings
==结论==
jQuery的选择器引擎非常强大，正因为如此，我们才更应该谨慎的并充分的使用它。
本文转载自：jQuery 1.3 最佳实践 (1) : 选择器
