jQuery运行程序性能目的和调优

jQuery无疑是一个杰出的JavaScript库，但它的性能如何？在其易用性和优秀Web页面性能之间启动折衷能否值得？它的性能是不是真的很优秀？本文将回答关于jQuery性能的疑问，并提供一些可以改良运行程序性能的技巧。

介绍专题：

度量JavaScript性能要思考的最关键疑问是执行JavaScript的环境。由于代码是运转在客户端上的，所以它的执行依赖于客户端计算机，这使得客户端机器成为影响性能的最关键要素。很清楚，运转4核CPU的新主机执行代码的速度必要求比MHz老式处置器快。这是毫无不懂的。不过，由于您不能控制Web运行程序用户用于访问您的站点的机器，所以在度量性能时要思考关于配件的许多要素。

JavaScript性能的另一个关键方面是用于运转JavaScript的阅读器，JavaScript新手或许不容易觉察这个影响要素。每个阅读器外部都蕴含一个JavaScript引擎，即用于解析和执行JavaScript代码并处置Web运行程序页面的本机代码。因此，JavaScript的性能严重依赖于客户端经常使用的阅读器，并且在某些状况下，您可以控制用户经常使用的阅读器。本文提供一些关于JavaScript性能的指点准则，并解释不同阅读器对性能的影响。

创立性能测试

关于性能测试的***步是创立一个适宜的性能测试。jQuery以及其余JavaScript库在代码中表演的最关键角色就是经常使用选用查找特定页面元素。我在最后的性能测试中就以这方面为重点。一个良好的性能测试应该真正地施展JavaScript库的所有力气，用蕴含数千个页面元素的页面测试它。应该运转一切选用方法，让我看到哪个选用方法最快，哪个最慢。测试应该事前知道正确的答案，从而确定JavaScript库能否正确地执行选用方法。***，应该显示一切结果，并附带所用的运转期间，让我能够在一切库之间启动比拟。

我差点疏忽了性能测试的最关键方面：它应该是收费的。毕竟这个系列文章的不成文规定就是相互应用彼此的成绩，因此我继续发扬这种精气，在此经常使用一个现成的JavaScript库性能测试。这个测试称为SlickSpeedSelectorsTest，它十分适宜我的需求。它将jQuery1.2.6（撰写本文时的***版本）与其余4个盛行的JavaScript库（MooTools、Prototype、YUI和Dojo）启动比拟。而后，它经常使用带有数千个页面元素的页面运转40个选用测试。换句话说，这是我所宿愿的***性能测试。我将在***共性能测试剖析中经常使用该测试。

对比JavaScript库的性能

关于***共性能测试，我经常使用的运转环境是2.2GHz处置器、2GBRAM和Firefox3.0.3（十分关键）。我在该性能下运转5次测试，图1显示了5次运转的平均结果。

图 1.性能测试1的结果

从***次测试能够得出什么论断？如今咱们仅关注总体结果，而不是每次测试。在取得一些总体论断之后，我将稍后在本文中关注每个测试。

论断1：YUI慢到了极点

对，与其余库相比，YUI真的很慢。细心检查每个测试，找出为什么这个库在选用元素组（例如“p,a”）时十分慢。关于要求具备很好性能的页面而言，这个库是最差的选用。

论断2：Mootools、jQuery和Dojo的运转期间简直一样

与其余两个库相比，这3个库是十分快的，并且Dojo是它们当中最快的，而jQuery是最慢的。但是从全局思考，它们之间的速度是很凑近的。

论断3：这些库之间的相对差异还是比拟清楚的

度量最快期间/最慢期间以确定速度的相对差异，您可以看到相对差异为332%。这个差异是比拟大的，这标明经常使用Firefox时选用不同的JavaScript库会对性能有影响。但是要记住，这些论断仅基于一个阅读器的结果。这是基于Firefox3.0.3得出的论断。如今咱们进入下一小节，我将在不同的阅读器上运转该测试。

在不同阅读器上的JavaScript性能

面对不同阅读器运转JavaScript会得出的不同结果（性能和期间都不同），许多初级Web程序员感觉无法思议。虽然这对初级Web程序员而言是个曲折（他们担忧要编写额外的代码来处置不同的阅读器），但是有阅历的Web程序员在Netscape和InternetExplorer的早期就知道如何处置该疑问。这也是经常使用JavaScript库的一个亮点，由于它们都审慎处置许多或大局部阅读器差异。

JavaScript速度差异的关键要素是每个阅读器都经常使用自己的JavaScript引擎。JavaScript引擎是用于解析JavaScript并依据Web运行程序执行它的本机代码。因此，JavaScript的执行速度与底层引擎间接关系。在最近几个月，许多阅读器公司越来越关注他们的阅读器的性能，这是有要素的。随着某些页面的JavaScript变得日益复杂，JavaScript引擎的快慢能够影响Web运行程序的照应速度。因此，当Google和Firefox等公司议论它们的JavaScript引擎时，它们就谈判及下一代引擎的速度要快10倍。这对Web运行程序而言是很关键的，由于底层JavaScript引擎的速度间接造成更复杂的Web运行程序的发生。

如今，您知道JavaScript引擎是JavaScript执行速度的一个要素，那么让咱们在不同的阅读器上运转刚才在Firefox上运转的测试，并尝试找出不同的引擎对JavaScript性能的影响。记住，这个测试与我前面在Firefox上运转的测试是一样的，因此除了JavaScript引擎以外，其余一切物品都是相反的。图2显示了测试结果。

图2. 性能测试2的结果

看完这些测试结果之后，您首先留意到的是在这些阅读器中运转获取的期间差很大。在Chrome1.0上运转jQuery要求168毫秒，而在IE6上运转要求1728秒。这是难以置信的期间差！jQuery选用方法在IE6上运转比在Chrome上运转慢10倍！如今，您知道为什么Google青睐炫耀它的JavaScript引擎，以及为什么某些阅读器很少引见自己的JavaScript引擎。这些差异还是比拟大的。

您应该留意到，jQuery在Firefox或一些其余阅读器上运转时速度排在第3位，而在另一些阅读器上排在第1位。理想上，这些结果标明，依据性能启动分类的话，这些库可以分为两组，而不论经常使用什么阅读器。Mootools、Dojo和jQuery通常属于一个组别，而Prototype和YUI属于另一个组别，前一组要比后一组快得多。

性能测试论断

我感觉一切这些论断都要求专门花一个小节启动论述，由于它们对JavaScript开发人员十分关键。我依然尝试总结上方的性能结果，并且没有遗记本文是以jQuery为主题的。

论断1：Mootools、jQuery和Dojo在性能方面不分高低

图3. 测试结果的平均值（Mootools、jQuery 和 Dojo）

检查它们在一切5个阅读器上启动的测试，在求取平均值之后，您可以看到这3个库的性能简直是一样的。（理想状况下，咱们应该考查每个阅读器的市场份额。但是调整这些数字很难，由于经常使用JavaScript库的站点不必定由“平均用户”访问）。

论断2：Prototype和YUI的性能很慢

看看这两个库在5个阅读器中的测试结果与jQuery的对比。在求取它们的平均值之后，您可以发现这两个库的性能差异有多大。它们在恣意阅读器中平均比jQuery慢300%。

图4. 测试结果的平均值（jQuery、Prototype 和 YUI）

论断3：假设对性能要求比拟高时，选用Mootools、jQuery和Dojo之一取得的性能简直一样

依据以上的平均值，选用这3个库之一比选用另外两个库之一能够取得更多的性能长处。从在一切阅读器上运转得出的平均值看，它们的性能是相当的。因此，当您选用JavaScript库时，选用这3个库之一是不会错的。

论断4：假设对性能要求比拟高时，不要选用Prototype或YUI

假设要求JavaScript库具备较高的性能，或许计划创立一个大型的JavaScript名目，那么就不应该选用这两个库之一。这两个库的性能要比其余库逊色得多。

论断5：阅读器对性能的影响是JavaScript库的9倍

我以为这是本文一切论断中最关键的论断。您可以在特定状况下讨论哪个JavaScript库最快，但它最终的影响却是很小的！关于性能而言，阅读器的影响比库自身要大得多。回忆一下图3和图4的平均值，您可以看到3个最快的库中，最慢那个（Dojo）仅比最快那个（jQuery）慢15%。只要15%！

但是，您看看jQuery在最快的阅读器（Chrome1.0）和最慢的阅读器（IE6）上运转的速度差异，这个差异居然到达1000%！从这两个数字看，15%对1000%而言是微无余道的。至此，关于3个较快的库中哪个是最快的争执可以中止了，由于它们对最终结果的影响是微乎其微的。

论断6：假设JavaScript性能对Web运行程序很关键，并且您可以控制选用什么阅读器，那么就选用最快的阅读器

在某些状况下，您可以控制经常使用什么阅读器访问站点。假设能够控制经常使用什么阅读器，那么您就是很幸运的。我就碰到这样幸运的名目。在这种状况下，假设您领有一个复杂的JavaScript运行程序，或许您以为性能很关键，那么您就应该控制用户用于访问Web运行程序的阅读器。这些测试曾经清楚地显示了阅读器的影响。假设您的JavaScript运行程序的访问量很大，那么您可以通知用户，他们必需经常使用Chrome。

论断7：假设您不能控制用户经常使用的阅读器，那么要首先思考在IE6上的性能

但是，在大局部状况下，咱们都无法控制用户经常使用什么阅读器访问咱们的站点。不过，很大一局部用户都经常使用IE6阅读网页。到目前为止的测试中，这个阅读器的JavaScript引擎是最慢的。但是由于依然有少量用户经常使用它，并且良好的Web设计要求“顺应最蹩脚的状况”，这象征着您可以思考依据IE6设计您的JavaScript运行程序。

jQuery性能调优

本文的第二局部将讨论如何改良jQuery代码的性能。前一局部标明选用jQuery作为JavaScript库指向了正确的性能方向。假设您正在阅读本文，您或许曾经经常使用了jQuery。但是底层库速度快并不象征着您编写的一切代码都是高品质的。假设您没有回过头来想想应该怎样做，经常使用jQuery依然会编写出十分慢的代码。

这个局部引见一些性能调优常识，以及改良jQuery代码速度的***通常技巧。

技巧#1-尽或许多地经过ID启动搜查，而不是CLASS

图5. ID搜查和CLASS搜查对比

在jQuery代码中两种经常出现的搜查技术是经过元素的ID启动搜查和经过元素的CLASS启动搜查。在经常使用惯例JavaScript的JavaScript库之前，经过ID查找页面元素还是相当便捷的。可以经常使用getElementById()方法极速找到元素。但是假设没有JavaScript库，要查找CLASS会愈加艰巨，在必要状况下，咱们还经过在其ID中启动编码协助查找。

经常使用jQuery时，搜查CLASS就像搜查页面上的ID一样便捷，因此这两个搜查仿佛是可调换的。但是实践状况并非如此。经过ID搜查比经过CLASS搜查要快得多。当经过ID启动搜查时，jQuery实践上仅经常使用内置的getElementById()方法，但经过CLASS启动搜查时必需遍历页面上的一切元素，以查找婚配项。很清楚，当页面越大并且越复杂时，经过CLASS启动搜查会造成照应十分慢，而经过ID启动搜查不会随着页面变大而变慢。

前面运转的jQuery性能测试结果支持这一数据。让咱们检查每个测试，看看要求留意jQuery代码的什么中央。在这个例子中，区分看看经过ID和CLASS启动搜查时的测试结果。

这些测试是不同的，但它们得出的数据标明经过ID启动搜查比经过CLASS启动搜查快得多。这如何影响到jQuery代码？在编写搜查时，您要记住这些技巧：假设既可选用CLASS又可选用ID，那么通常要选用ID。假设要求在您的代码中搜查某些元素，必定要给它们调配ID。清单1显示了一个实践的jQuery测试，您可以在您的机器上运转它对此启动验证：

ID测试耗时218毫秒，而CLASS测试耗时19.9秒！甚至在专门为该测试构建的便捷页面上，ID搜查也要比CLASS搜查快100倍！

技巧#2-提供尽或许多的搜查信息

图6. 尽或许多地提供信息

jQuery提供如此多的页面元素搜查方法，有时您难以指出哪种方法是***的。有一条阅历是不会错的，即为搜查参数提供尽或许多的信息。因此，假设您正在搜查带有“clickable”CLASS的一切页面元素，假设您提早知道仅有DIV附带有CLASS，那么就能提高搜查性能。所以，搜查“div.clickable”会愈放慢。图6显示了支持该技巧的结果。

思考究竟层JavaScript代码之后，这就无余为奇了。经过提供元素标志，与CLASS参数婚配的搜查元素数量将大大缩小，从而将搜查性能优化至与本例中的ID搜查相当。开发人员在编写jQuery选用方法时不能偷懒，虽然jQuery的便捷让人发生偷懒的愿望。便捷让您安适了警觉。搜查机制变得如此便捷，让咱们偏差于仅输入一条信息。但是，您应该总是尽或许多地输入信息，尤其是已知信息。清单2显示了一个很好的例子。

技巧#3-缓存选用器

***一共性能技巧应用了简直一切jQuery选用器都前往jQuery对象这个特性。这象征着无理想的状况下，您仅要求运转选用器一次性，并且能够轻松地将一切函数衔接在一同，或缓存结果供经常使用。您也不要担忧缓存，由于与总体可用内存相比，前往的对象是很小的。清单3给出了一些关于如何应用缓存的例子。

在我的***一个关于性能的示例代码中，将检查我在本系列的***篇文章中提到的小部件（见参考资料）。这个小部件是在表的左上角上的复选框，它准许您选用或敞开选用该列上的一切复选框。这个小部件在电子邮件运行程序中十分经常出现，用于选用或敞开选用一切信息。

关于性能的要点

经常使用JavaScript时，速度和性能相对不是小疑问。无理想中，创立jQuery的开发人员和处置阅读器内置JavaScript引擎的开发人员都十分关注性能疑问。理想上，在最近6个月以来，阅读器开发的最关键疑问就是JavaScript引擎的速度。阅读器开发者都努力于在下一年迅速优化JavaScript的执行性能，从而大大提高jQuery代码和JavaScript引擎的速度。来自这些“速度之战”的信息标明，优化JavaScript性能是大势所趋。

指导jQuery名目的JohnResig不时都在议论他的***“Sizzle”选用引擎。他从头编写了一个选用引擎，并宣称初步结果标明它比Firefox要快4倍。这是渺小的速度优化！在我撰写本文的***局部时，jQuery1.3曾经颁布，并且蕴含了Sizzle选用引擎。jQuery宣称，在一切阅读器上运转的总体结果标明选用引擎的1.3版本比1.2.6版本的快49%。此外，1.3颁布版在HTML注入（向DOM增加新的元素）上改良了6倍，在函数定位上改良了3倍。在我成功本文时，很多人都更新到了***的jQuery颁布版，这是十分令人激动的！

影响JavaScript性能的另一个要素是阅读器，如前所述，它的影响是所选的库的9倍。Firefox和Chrome在“最快JavaScript引擎”之战中各有输赢，而Safari的介入让竞争愈加强烈。从咱们上方的测试中，可以看到Chrome在JavaScript引擎性能方面远远超越Firefox，但是Firefox3.1将蕴含新的TracemonkeyJavaScript引擎，届时其速度将比的JavaScript引擎3.0快20至40倍（这是他们宣称的，不是我的观念），真无法思议！在未来一两年内，您将看究竟层JavaScript引擎和JavaScript库的速度获取渺小改良，从而导以至用JavaScript的Web运行程序将变得愈加复杂。

假设您正在选择是经常使用JavaScript库还是自己编写JavaScript，那么要求思考的另一件事件是处置和调试JavaScript库所需的所有上班。最近几年以来，有数百位用户不时在保养库中的每一个函数。您或许要忙到深夜，甚至精疲力竭地编写自己的函数。

您更置信谁呢？另外，即使您能编写出比jQuery库更快的代码，您能否想过经常使用jQuery库能够取得更多的长处？您能否为了辛劳地编写自己的代码而丢弃经常使用十分便利的jQuery及其函数库？自己编写代码不只要求少量期间，并且还会发生更多bug，因此我还是倡导经常使用现成的jQuery库。

我***讨论的要点或许会让一些人丧气，但是咱们必需思考编写这些jQuery库的程序员。他们当中的一些是最棒的，并且他们编写的超级优秀的代码（普通人不能编写这样杰出的代码）都支出到这些库中。我抵赖自己远远不如编写jQuery库的程序员。因此，为何不应用他们的智慧？

完结语

本文从总体上讨论了jQuery和JavaScript库的性能。经过对选用方法启动少量的测试，您看到这些库之间的速度存在渺小的差距，并且jQuery是最快的库之一。不过，即使您选用了最快的JavaScript库，还是不能处置Web运行程序的性能疑问，由于阅读器对性能的影响比库强9倍。假设您能够控制用户经常使用特定的Web阅读器，那么就让他们经常使用最快的阅读器。找到能够最快地运转您的Web运行程序的阅读器，并让用户经过经常使用它从中受益。理想状况下，让最慢的JavaScript阅读器隐没象征着发生更快的Web运行程序。

***，咱们极速检查了jQuery和阅读器的JavaScript引擎行将推出的改良。在我撰写本文的开头局部时，jQuery1.3曾经颁布了，它承诺在选用和代码的其余方面成功腾跃式性能改良。此外，Firefox还承诺它的下一代JavaScript引擎会快20至40倍！这些迹象标明，在未来的一两年内，JavaScript环境会在性能上取得严重打破。在不久的未来，复杂的Web运行程序会日益盛行，由于极速运转这些程序的条件曾经成熟。

【编辑介绍】