本文的寫作靈感源自讀者關(guān)于先前一篇文章的電子郵件反饋;該郵件這樣寫道 “jQuery 在簡單的頁面上無可挑剔，但在復(fù)雜的頁面上性能極其低下。在解決性能問題之前，您必須對復(fù)雜頁面使用常規(guī)的 JavaScript。” 這立即讓我想到 “jQuery 和 JavaScript 之間的性能比較會是什么樣的?”事實上，我很少看到將 jQuery 庫與 JavaScript 或其他 JavaScript 庫進行比較的文章。我可能像大多數(shù)人一樣，僅看到用 jQuery 編寫客戶端代碼的簡易，而忽略了可能的性能問題。在我看來，在易用性和性能之間進行折衷是值得的。但是，存在這樣一種折衷嗎?jQuery 是不是比 “一般” 的 JavaScript 慢?jQuery 是不是比其他庫慢?本文將嘗試解答這些問題。

51CTO推薦專題：jQuery從入門到精通

度量 JavaScript 性能要考慮的最重要問題是執(zhí)行 JavaScript 的環(huán)境。因為代碼是運行在客戶端上的，所以它的執(zhí)行依賴于客戶端計算機，這使得客戶端機器成為影響性能的最重要因素。很明顯，運行 4 核 CPU 的新服務(wù)器執(zhí)行代碼的速度肯定要比 400 MHz 老式處理器快。這是毫無疑問的。不過，由于您不能控制 Web 應(yīng)用程序用戶用于訪問您的站點的機器，所以在度量性能時要考慮關(guān)于硬件的許多因素。

JavaScript 性能的另一個重要方面是用于運行 JavaScript 的瀏覽器，JavaScript 新手可能不容易發(fā)覺這個影響因素。每個瀏覽器內(nèi)部都包含一個 JavaScript 引擎，即用于解析和執(zhí)行 JavaScript 代碼并處理 Web 應(yīng)用程序頁面的本機代碼。因此，JavaScript 的性能嚴重依賴于客戶端使用的瀏覽器，并且在某些情況下，您可以 控制用戶使用的瀏覽器。本文提供一些關(guān)于 JavaScript 性能的指導(dǎo)原則，并解釋不同瀏覽器對性能的影響。

最后，在總結(jié) JavaScript，尤其是 jQuery 的性能之后，我將確定一些能夠改進 jQuery 代碼性能的最佳實踐，充分利用運行得最快的代碼部分，而盡量避免運行得最慢的代碼部分。在您閱讀完本文之后，“jQuery 的性能好嗎” 這個問題將得到解答，并且給我發(fā)送那封電子郵件的人也將知道他的斷言是否正確。

創(chuàng)建性能測試

關(guān)于性能測試的第一步是創(chuàng)建一個合適的性能測試。jQuery 以及其他 JavaScript 庫在代碼中扮演的最重要角色就是使用選擇查找特定頁面元素。我在最初的性能測試中就以這方面為重點。一個良好的性能測試應(yīng)該真正地發(fā)揮 JavaScript 庫的全部力量，用包含數(shù)千個頁面元素的頁面測試它。應(yīng)該運行所有選擇方法，讓我看到哪個選擇方法最快，哪個最慢。測試應(yīng)該事先知道正確的答案，從而確定 JavaScript 庫是否正確地執(zhí)行選擇方法。最后，應(yīng)該顯示所有結(jié)果，并附帶所用的運行時間，讓我能夠在所有庫之間進行比較。

我差點忽略了性能測試的最重要方面：它應(yīng)該是免費的。畢竟這個系列文章的不成文規(guī)則就是相互利用彼此的成果，因此我繼續(xù)發(fā)揚這種精神，在此使用一個現(xiàn)成的 JavaScript 庫性能測試。這個測試稱為 SlickSpeed Selectors Test(見 參考資料)，它非常適合我的需求。它將 jQuery 1.2.6(撰寫本文時的最新版本)與其他 4 個流行的 JavaScript 庫(MooTools、Prototype、YUI 和 Dojo)進行比較。然后，它使用帶有數(shù)千個頁面元素的頁面運行40個選擇測試。換句話說，這是我所希望的最佳性能測試。我將在第一個性能測試分析中使用該測試。

對比JavaScript 庫的性能

對于第一個性能測試，我使用的運行環(huán)境是 2.2 GHz 處理器、2 GB RAM 和 Firefox 3.0.3(非常重要)。我在該配置下運行 5 次測試，圖 1 顯示了 5 次運行的平均結(jié)果。

圖 1. 性能測試 1 的結(jié)果

從第一次測試能夠得出什么結(jié)論?現(xiàn)在我們僅關(guān)注總體結(jié)果，而不是每次測試。在獲得一些總體結(jié)論之后，我將稍后在本文中關(guān)注每個測試。

◆  結(jié)論 1：YUI 慢到了極點!

對，與其他庫相比，YUI 真的很慢。仔細查看每個測試，找出為什么這個庫在選擇元素組(例如 “p, a”)時非常慢。對于要求具有很好性能的頁面而言，這個庫是最差的選擇。

◆  結(jié)論 2：Mootools、jQuery 和 Dojo 的運行時間幾乎一樣。

與其他兩個庫相比，這 3 個庫是非?？斓?，并且 Dojo 是它們當(dāng)中最快的，而 jQuery 是最慢的。但是從全局考慮，它們之間的速度是很接近的。

◆  結(jié)論 3：這些庫之間的相對差別還是比較明顯的。

度量最快時間/最慢時間以確定速度的相對差別，您可以看到相對差別為 332%。這個差別是比較大的，這表明使用 Firefox 時選擇不同的 JavaScript 庫會對性能有影響。

但是要記住，這些結(jié)論僅基于一個瀏覽器的結(jié)果。這是基于 Firefox 3.0.3 得出的結(jié)論?，F(xiàn)在我們進入下一小節(jié)，我將在不同的瀏覽器上運行該測試。

在不同瀏覽器上的JavaScript 性能

面對不同瀏覽器運行 JavaScript 會得出的不同結(jié)果(性能和時間都不同)，許多初級 Web 程序員覺得不可思議。盡管這對初級 Web 程序員而言是個挫折(他們擔(dān)心要編寫額外的代碼來處理不同的瀏覽器)，但是有經(jīng)驗的 Web 程序員在 Netscape 和 Internet Explorer 的早期就知道如何處理該問題。這也是使用 JavaScript 庫的一個亮點，因為它們都謹慎處理許多或大部分瀏覽器差異。

JavaScript 速度差異的主要原因是每個瀏覽器都使用自己的 JavaScript 引擎。JavaScript 引擎是用于解析 JavaScript 并根據(jù) Web 應(yīng)用程序執(zhí)行它的本機代碼。因此，JavaScript 的執(zhí)行速度與底層引擎直接相關(guān)。在最近幾個月，許多瀏覽器公司越來越關(guān)注他們的瀏覽器的性能，這是有原因的。隨著某些頁面的 JavaScript 變得日益復(fù)雜，JavaScript 引擎的快慢能夠影響 Web 應(yīng)用程序的響應(yīng)速度。因此，當(dāng) Google 和 Firefox 等公司談?wù)撍鼈兊?JavaScript 引擎時，它們就會談及下一代引擎的速度要快 10 倍。這對 Web 應(yīng)用程序而言是很重要的，因為底層 JavaScript 引擎的速度直接導(dǎo)致更復(fù)雜的 Web 應(yīng)用程序的出現(xiàn)。

現(xiàn)在，您知道 JavaScript 引擎是 JavaScript 執(zhí)行速度的一個因素，那么讓我們在不同的瀏覽器上運行剛才在 Firefox 上運行的測試，并嘗試找出不同的引擎對 JavaScript 性能的影響。記住，這個測試與我前面在 Firefox 上運行的測試是一樣的，因此除了 JavaScript 引擎以外，其他所有東西都是相同的。圖 2 顯示了測試結(jié)果。

圖 2. 性能測試 2 的結(jié)果

看完這些測試結(jié)果之后，您首先注意到的是在這些瀏覽器中運行得到的時間差很大。在 Chrome 1.0 上運行 jQuery 需要 168 毫秒，而在 IE6 上運行需要 1728 秒。這是難以置信的時間差!jQuery 選擇方法在 IE6 上運行比在 Chrome 上運行慢 10 倍!現(xiàn)在，您知道為什么 Google 喜歡夸耀它的 JavaScript 引擎，以及為什么某些瀏覽器很少介紹自己的 JavaScript 引擎。這些差別還是比較大的。

您應(yīng)該注意到，jQuery 在 Firefox 或一些其他瀏覽器上運行時速度排在第 3 位，而在另一些瀏覽器上排在第 1 位。事實上，這些結(jié)果表明，根據(jù)性能進行分類的話，這些庫可以分為兩組，而不管使用什么瀏覽器。Mootools、Dojo 和 jQuery 通常屬于一個組別，而 Prototype 和 YUI 屬于另一個組別，前一組要比后一組快得多。

性能測試結(jié)論

我覺得所有這些結(jié)論都需要專門花一個小節(jié)進行闡述，因為它們對 JavaScript 開發(fā)人員非常重要。我仍然嘗試總結(jié)上面的性能結(jié)果，并且沒有忘記本文是以 jQuery 為主題的。

◆ 結(jié)論 1：Mootools、jQuery 和 Dojo 在性能方面不分上下。

查看它們在所有 5 個瀏覽器上進行的測試，在求取平均值之后，您可以看到這 3 個庫的性能幾乎是一樣的。(理想情況下，我們應(yīng)該調(diào)查每個瀏覽器的市場份額。但是調(diào)整這些數(shù)字很難，因為使用 JavaScript 庫的站點不一定由 “平均用戶” 訪問)。

圖 3. 測試結(jié)果的平均值(Mootools、jQuery 和 Dojo)

 

◆ 結(jié)論 2：Prototype 和 YUI 的性能很慢。

看看這兩個庫在 5 個瀏覽器中的測試結(jié)果與 jQuery 的對比。在求取它們的平均值之后，您可以發(fā)現(xiàn)這兩個庫的性能差別有多大。它們在任意瀏覽器中平均比 jQuery 慢 300%。

圖 4. 測試結(jié)果的平均值(jQuery、Prototype 和 YUI)

 

◆ 結(jié)論 3：如果對性能要求比較高時，選擇 Mootools、jQuery 和 Dojo 之一獲得的性能幾乎一樣。

根據(jù)以上的平均值，選擇這 3 個庫之一比選擇另外兩個庫之一能夠獲得更多的性能優(yōu)勢。從在所有瀏覽器上運行得出的平均值看，它們的性能是相當(dāng)?shù)摹Ｒ虼?，?dāng)您選擇 JavaScript 庫時，選擇這 3 個庫之一是不會錯的。

◆ 結(jié)論 4：如果對性能要求比較高時，不要選擇 Prototype 或 YUI。

如果要求 JavaScript 庫具有較高的性能，或者打算創(chuàng)建一個大型的 JavaScript 項目，那么就不應(yīng)該選擇這兩個庫之一。這兩個庫的性能要比其他庫遜色得多。

◆ 結(jié)論 5：瀏覽器對性能的影響是 JavaScript 庫的 9 倍。

我認為這是本文所有結(jié)論中最重要的結(jié)論。您可以在特定情況下討論哪個 JavaScript 庫最快，但它最終的影響卻是很小的!對于性能而言，瀏覽器的影響比庫本身要大得多。回顧一下圖 3 和圖 4 的平均值，您可以看到 3 個最快的庫中，最慢那個(Dojo)僅比最快那個(jQuery)慢 15%。只有 15%!然而，您看看 jQuery 在最快的瀏覽器(Chrome 1.0)和最慢的瀏覽器(IE6)上運行的速度差別，這個差別竟然達到 1000%!從這兩個數(shù)字看，15% 對 1000% 而言是微不足道的。至此，關(guān)于 3 個較快的庫中哪個是最快的爭論可以停止了，因為它們對最終結(jié)果的影響是微乎其微的。

◆ 結(jié)論 6：如果 JavaScript 性能對 Web 應(yīng)用程序很重要，并且您可以控制選擇什么瀏覽器，那么就選擇最快的瀏覽器!

在某些情況下，您可以控制使用什么瀏覽器訪問站點。如果能夠控制使用什么瀏覽器，那么您就是很幸運的。我就碰到這樣幸運的項目。在這種情況下，如果您擁有一個復(fù)雜的 JavaScript 應(yīng)用程序，或者您認為性能很重要，那么您就應(yīng)該控制用戶用于訪問 Web 應(yīng)用程序的瀏覽器。這些測試已經(jīng)清楚地顯示了瀏覽器的影響。如果您的 JavaScript 應(yīng)用程序的訪問量很大，那么您可以告訴用戶，他們必須 使用 Chrome。

◆ 結(jié)論 7：如果您不能控制用戶使用的瀏覽器，那么要首先考慮在 IE6 上的性能。

但是，在大部分情況下，我們都無法控制用戶使用什么瀏覽器訪問我們的站點。不過，很大一部分用戶都使用 IE 6 瀏覽網(wǎng)頁。到目前為止的測試中，這個瀏覽器的 JavaScript 引擎是最慢的。但是由于仍然有大量用戶使用它，并且良好的 Web 設(shè)計需要 “適應(yīng)最糟糕的情況”，這意味著您可以考慮根據(jù) IE6 設(shè)計您的 JavaScript 應(yīng)用程序。

#p#

jQuery 性能調(diào)優(yōu)

本文的第二部分將討論如何改進 jQuery 代碼的性能。前一部分表明選擇 jQuery 作為 JavaScript 庫指向了正確的性能方向。如果您正在閱讀本文，您可能已經(jīng)使用了 jQuery。但是底層庫速度快并不意味著您編寫的所有代碼都是高質(zhì)量的。如果您沒有回過頭來想想應(yīng)該怎么做，使用 jQuery 仍然會編寫出非常慢的代碼。

這個部分介紹一些性能調(diào)優(yōu)知識，以及改進 jQuery 代碼速度的最佳實踐技巧。

技巧 #1 - 盡可能多地通過 ID 進行搜索，而不是 CLASS

在 jQuery 代碼中兩種常見的搜索技術(shù)是通過元素的 ID 進行搜索和通過元素的 CLASS 進行搜索。在使用常規(guī) JavaScript 的 JavaScript 庫之前，通過 ID 查找頁面元素還是相當(dāng)簡單的?？梢允褂?getElementById() 方法快速找到元素。但是如果沒有 JavaScript 庫，要查找 CLASS 會更加困難，在必要情況下，我們還通過在其 ID 中進行編碼幫助查找。使用 jQuery 時，搜索 CLASS 就像搜索頁面上的 ID 一樣簡單，因此這兩個搜索似乎是可互換的。然而實際情況并非如此。通過 ID 搜索比通過 CLASS 搜索要快得多。當(dāng)通過 ID 進行搜索時，jQuery 實際上僅使用內(nèi)置的 getElementById() 方法，但通過 CLASS 進行搜索時必須遍歷頁面上的所有元素，以查找匹配項。很明顯，當(dāng)頁面越大并且越復(fù)雜時，通過 CLASS 進行搜索會導(dǎo)致響應(yīng)非常慢，而通過 ID 進行搜索不會隨著頁面變大而變慢。

前面運行的 jQuery 性能測試結(jié)果支持這一數(shù)據(jù)。讓我們查看每個測試，看看需要注意 jQuery 代碼的什么地方。在這個例子中，分別看看通過 ID 和 CLASS 進行搜索時的測試結(jié)果(圖 5)。

圖 5. ID 搜索和 CLASS 搜索對比

 

這些測試是不同的，但它們得出的數(shù)據(jù)表明通過 ID 進行搜索比通過 CLASS 進行搜索快得多。這如何影響到 jQuery 代碼?在編寫搜索時，您要記住這些技巧：如果既可選擇 CLASS 又可選擇 ID，那么通常要選擇 ID。如果需要在您的代碼中搜索某些元素，一定要給它們分配 ID。

清單 1 顯示了一個實際的 jQuery 測試，您可以在您的機器上運行它對此進行驗證：

清單 1. CLASS 和 ID

$(document).ready(function() {  
 
  console.info("Start Test");  
  var d = new Date();  
  console.info(d.getSeconds() + " " + d.getMilliseconds());  
 
  var testBody = "";  
  for (var i=0; i<1000; i++)  
  {  
     testBody += "<div class='testable"+i+"'>";  
  }  
  $("body").append(testBody);  
  for (var i=0; i<1000; i++)  
  {  
    $(".testable"+i);  
  }  
 
  var d = new Date();  
  console.info(d.getSeconds() + " " + d.getMilliseconds());  
  console.time("Start ID Test");  
 
  testBody = "";  
  for (var i=0; i<1000; i++)  
  {  
    testBody += "<div id='testable"+i+"'>";  
  }  
  $("body").append(testBody);  
  for (var i=0; i<1000; i++)  
  {  
    $("#testable"+i);  
  }  
  var d = new Date();  
  console.info(d.getSeconds() + " " + d.getMilliseconds());  
  console.info("End Test");  
  }); 

ID 測試耗時 218 毫秒，而 CLASS 測試耗時 19.9 秒!甚至在專門為該測試構(gòu)建的簡單頁面上，ID 搜索也要比 CLASS 搜索快 100 倍!

技巧 #2 - 提供盡可能多的搜索信息

jQuery 提供如此多的頁面元素搜索方法，有時您難以指出哪種方法是最好的。有一條經(jīng)驗是不會錯的，即為搜索參數(shù)提供盡可能多的信息。因此，假如您正在搜索帶有 “clickable” CLASS 的所有頁面元素，如果您提前知道僅有 DIV 附帶有 CLASS，那么就能提高搜索性能。所以，搜索 “div.clickable” 會更加快。圖 6 顯示了支持該技巧的結(jié)果。

圖 6. 盡可能多地提供信息

 

考慮到底層 JavaScript 代碼之后，這就不足為奇了。通過提供元素標(biāo)記，與 CLASS 參數(shù)匹配的搜索元素數(shù)量將大大減少，從而將搜索性能提升至與本例中的 ID 搜索相當(dāng)。

開發(fā)人員在編寫 jQuery 選擇方法時不能偷懶，盡管 jQuery 的簡單讓人產(chǎn)生偷懶的欲望。簡單讓您放松了警惕。搜索機制變得如此簡單，讓我們傾向于僅輸入一條信息。然而，您應(yīng)該總是盡可能多地輸入信息，尤其是已知信息。清單 2 顯示了一個很好的例子。

清單 2. 提供充足的信息

// Assume there are 50 of these in some giant form, and you need to validate  
// these fields before they are submitted, and there are hundreds of other  
// elements on the page as well  
<input type=text class="notBlank">  
 
// the "bad" way to validate these fields  
$(".notBlank").each(function(){  
   if ($(this).val()=="")  
      $(this).addClass("error");  
});  
 
// the "good" way to validate these fields  
$("input.notBlank").each(function(){  
   if ($(this).val()=="")  
      $(this).addClass("error");  
});  
 
// the "best" way to validate these fields  
$("input:text.notBlank").each(function(){  
   if ($(this).val()=="")  
      $(this).addClass("error");  
      }); 

技巧 #3 - 緩存選擇器

最后一個性能技巧利用了幾乎所有 jQuery 選擇器都返回 jQuery 對象這個特性。這意味著在理想的情況下，您僅需要運行選擇器一次，并且能夠輕松地將所有函數(shù)連接在一起，或緩存結(jié)果供以后使用。您也不要擔(dān)心緩存，因為與總體可用內(nèi)存相比，返回的對象是很小的。

清單 3 給出了一些關(guān)于如何利用緩存的例子。

清單 3. 緩存

在我的最后一個關(guān)于性能

// Imagine a function that hides all the div's with a class of "hideable"   
// when a button is pressed.  These DIV's might reappear later when   
// working with the page,  so the button can be pressed any number of   
// times, and the DIV's that have reappeared  
// will again be made to be hidden.  
 
$("#ourHideButton").click(function(){  
   $(".hideable").hide();  
});  
 
// As you saw in the CLASS versus ID example, though, a search for   
// CLASS is very inefficient  
// If this button is pressed often, it could lead to a slow response  
// Instead of the above example, you should write your code like this  
 
var hideable;  
 
$("#ourHideButton").click(function(){  
   if (hideable)  
       hideable.hide();  
   else 
       hideable = $(".hideable").hide();  
});  
 
// You can cache your search in a JavaScript variable and reuse it every time  
// the button is pressed.  Because jQuery almost always returns the  
// jQuery object, you can save it the first time it is called for future use 

的示例代碼中，將查看我在本系列的第一篇文章中提到的小部件(見 參考資料)。這個小部件是在表的左上角上的復(fù)選框，它允許您選擇或取消選擇該列上的所有復(fù)選框。這個小部件在電子郵件應(yīng)用程序中非常常見，用于選擇或取消選擇所有消息。

清單 4. 性能改進

// Here is the code as I originally presented it in that article.  Let's see  
// if we can improve the performance in any way from the things we learned here  
 
function selectAll()  
{  
    var checked = $("#selectall").attr("checked");  
    $(".selectable").each(function(){  
       var subChecked = $(this).attr("checked");  
       if (subChecked != checked)  
          $(this).click();  
    });  
}  
 
// Here's the improved function.  The search for the ID of "selectall" is  
// OK as-is, because we saw how fast the ID search is.  
// The search for the CLASS of "selectable" was not well-designed though,  
// because we saw a search by CLASS is very inefficient.  
// First step was improving the search by supplying as much information as we know.  
// We narrowed the search to only checkboxes with the CLASS of selectable.  
// This should improve our search  
// Further, we can cache this search because we will only need to perform it once  
// Finally, we can perform this search before the selectall checkbox is even  
// checked (when the page is finished loading), so that the search is completed  
// and cached before the user even uses it.  
// These 3 simple performance steps gave me a 200% increase in speed when tested  
// on a page with 200 rows of data.  
 
var selectable = $(":checkbox.selectable");  
function selectAll()  
{  
    var checked = $("#selectall").attr("checked");  
    selectable.each(function(){  
       var subChecked = $(this).attr("checked");  
       if (subChecked != checked)  
          $(this).click();  
    });  
} 

關(guān)于性能的要點

使用 JavaScript 時，速度和性能絕對不是小問題。在現(xiàn)實中，創(chuàng)建 jQuery 的開發(fā)人員和處理瀏覽器內(nèi)置 JavaScript 引擎的開發(fā)人員都非常關(guān)注性能問題。事實上，在最近 6 個月以來，瀏覽器開發(fā)的最重要問題就是 JavaScript 引擎的速度。瀏覽器開發(fā)者都致力于在下一年迅速提升 JavaScript 的執(zhí)行性能，從而大大提高 jQuery 代碼和 JavaScript 引擎的速度。來自這些 “速度之戰(zhàn)” 的消息表明，提升 JavaScript 性能是大勢所趨。領(lǐng)導(dǎo) jQuery 項目的 John Resig 一直都在談?wù)撍淖钚?“Sizzle” 選擇引擎。他從頭編寫了一個選擇引擎，并聲稱初步結(jié)果表明它比 Firefox 要快 4 倍。這是巨大的速度提升!在我撰寫本文的最后部分時，jQuery 1.3 已經(jīng)發(fā)布，并且包含了 Sizzle 選擇引擎。jQuery 聲稱，在所有瀏覽器上運行的總體結(jié)果表明選擇引擎的 1.3 版本比 1.2.6 版本的快 49%。此外，1.3 發(fā)布版在 HTML 注入(向 DOM 添加新的元素)上改進了 6 倍，在函數(shù)定位上改進了 3 倍。在我完成本文時，很多人都更新到了最新的 jQuery 發(fā)布版，這是非常令人激動的!

影響 JavaScript 性能的另一個因素是瀏覽器，如前所述，它的影響是所選的庫的 9 倍。Firefox 和 Chrome 在 “最快 JavaScript 引擎” 之戰(zhàn)中各有勝負，而 Safari 的參與讓競爭更加激烈。從我們上面的測試中，可以看到 Chrome 在 JavaScript 引擎性能方面遠遠超過 Firefox，但是 Firefox 3.1 將包含新的 Tracemonkey JavaScript 引擎，屆時其速度將比當(dāng)前的 JavaScript 引擎 3.0 快 20 至 40 倍(這是他們聲稱的，不是我的觀點)，真不可思議!

在未來一兩年內(nèi)，您將看到底層 JavaScript 引擎和 JavaScript 庫的速度得到巨大改進，從而導(dǎo)致使用 JavaScript 的 Web 應(yīng)用程序?qū)⒆兊酶訌?fù)雜。

如果您正在決定是使用 JavaScript 庫還是自己編寫 JavaScript，那么需要考慮的另一件事情是處理和調(diào)試 JavaScript 庫所需的全部工作。最近幾年以來，有數(shù)百位用戶一直在維護庫中的每一個函數(shù)。您可能要忙到深夜，甚至筋疲力盡地編寫自己的函數(shù)。您更相信誰呢?另外，即使您能編寫出比 jQuery 庫更快的代碼，您是否想過使用 jQuery 庫能夠獲得更多的優(yōu)勢?您是否為了辛苦地編寫自己的代碼而放棄使用非常便利的 jQuery 及其函數(shù)庫?自己編寫代碼不僅需要大量時間，并且還會產(chǎn)生更多 bug，因此我還是建議使用現(xiàn)成的 jQuery 庫。

我最后討論的要點可能會讓一些人沮喪，但是我們必須考慮編寫這些 jQuery 庫的程序員。他們當(dāng)中的一些是最棒的，并且他們編寫的超級優(yōu)秀的代碼(一般人不能編寫這樣出色的代碼)都收入到這些庫中。我承認自己遠遠不如編寫 jQuery 庫的程序員。因此，為何不利用他們的智慧?

結(jié)束語

本文從總體上討論了 jQuery 和 JavaScript 庫的性能。通過對選擇方法進行大量的測試，您看到這些庫之間的速度存在巨大的差距，并且 jQuery 是最快的庫之一。不過，即使您選擇了最快的 JavaScript 庫，還是不能解決 Web 應(yīng)用程序的性能問題，因為瀏覽器對性能的影響比庫強 9 倍。如果您能夠控制用戶使用特定的 Web 瀏覽器，那么就讓他們使用最快的瀏覽器。找到能夠最快地運行您的 Web 應(yīng)用程序的瀏覽器，并讓用戶通過使用它從中受益。理想情況下，讓最慢的 JavaScript 瀏覽器消失意味著出現(xiàn)更快的 Web 應(yīng)用程序。

我還提供了關(guān)于 jQuery 性能的 3 個技巧。盡管有好幾個站點都提供了關(guān)于 jQuery 性能的技巧，但是這 3 個技巧是最有效的。3 個技巧肯定比 50 個技巧容易記住，但其他技巧也是很好的，我將在 參考資料 部分指出另外一些技巧。不過，如果您在編寫代碼時記住了這 3 個技巧，將會獲得巨大的性能提升。應(yīng)該永遠記住的 3 個 jQuery 技巧是：通過 ID 搜索比通過 CLASS 搜索快 100 倍，盡可能多地提供搜索信息，以及盡量緩存選擇。

最后，我們快速查看了 jQuery 和瀏覽器的 JavaScript 引擎即將推出的改進。在我撰寫本文的結(jié)尾部分時，jQuery 1.3 已經(jīng)發(fā)布了，它承諾在選擇和代碼的其他方面實現(xiàn)跳躍式性能改進。此外，F(xiàn)irefox 還承諾它的下一代 JavaScript 引擎會快 20 至 40 倍!這些跡象表明，在未來的一兩年內(nèi)，JavaScript 環(huán)境會在性能上取得重大突破。在不久的將來，復(fù)雜的 Web 應(yīng)用程序會日益流行，因為快速運行這些程序的條件已經(jīng)成熟。

在本文結(jié)束時，我們應(yīng)該回過頭來重新檢驗這句話 “jQuery 在簡單的頁面上無可挑剔，但在復(fù)雜的頁面上性能極其低下。在解決性能問題之前，您必須對復(fù)雜頁面使用常規(guī)的 JavaScript。”根據(jù)我的經(jīng)驗，jQuery 的 “性能問題” 一樣出現(xiàn)在 “常規(guī)的 JavaScript” 中。事實上，真正影響性能的不是 jQuery 或 JavaScript，而是瀏覽器。因此我同意這樣的觀點：使用設(shè)計不良的 jQuery 代碼的復(fù)雜頁面運行在 IE6 上時會導(dǎo)致糟糕的性能。不過，我希望您已經(jīng)了解我要闡述的思想：只要擁有良好的 jQuery 代碼、運用 3 個最重要的技巧并選擇最快的瀏覽器，那么即使運行最復(fù)雜的頁面也不會出現(xiàn)明顯的性能問題。

原文鏈接：http://www.ibm.com/developerworks/cn/web/wa-aj-advjquery/

【編輯推薦】

1. 從零開始學(xué)習(xí)jQuery之萬能的選擇器
2. 從零開始學(xué)習(xí)jQuery之你必須知道的JavaScript
3. 分享10個超炫的jQuery網(wǎng)站
4. jQuery給力插件大閱兵
5. 18個最新最給力的jQuery教程分享