jQuery選擇器深入分析:避免不必要的調用
上周我認真分析了一個Web 頁面,它在onLoad 事件中處理一段定制腳本文件用了4.8 秒。結果是其中2.8 秒消耗在動態菜單庫上(將會在博客中單獨記錄),剩下的 2 秒花費在jQuery的選擇器上。分析顯示多數選擇器不返回任何對象,而那些會返回對象的選擇器可考慮用不同的選擇器來改善性能。
關于jQuery選擇器
有大量的日志文章論述了jQuery選擇器及它們的性能影響。正如你所知,可以通過 ID, TagName 或 ClassName 選擇元素。依賴于不同的選擇器, jQuery 會使用瀏覽器本地方法,如 通過 ID 或標簽來選擇元素,或者在使用類名選擇時須手工從 DOM 中遍歷獲得元素(因為在 IE 中不存在相應的 getElementsByClssName).
分析我的頁面時間中這 2 秒
在 onLoad 處理器中對頁面中某些特定的元素使用 jQuery 設置為隱藏,顯示或改變樣式表...。這里是一個代碼片斷:

onLoad 中的 jQuery 腳本樣例
在 onLoad 事件處理器中充滿著這樣的調用。通過使用免費的 dynaTrace AJAX Edition, 你會看到被解析為選擇器的 $ 調用,并跟隨著那些方法調用,選擇器至少都能獲取到一個對象。下面通過 PurePath 對 onLoad 事件處理器的觀察,不僅給我們展示了每次選擇器調用所耗費的時間,還包括在不只一個對象時實際找到的對象數(下面還沒有哪個方法調用是連一個對象都找不到的).

非必要的 jQuery 選擇器調用導致無謂的開銷
所有紅色標記的調用都未返回一個元素,因為不存在直接基于查詢條件的 DOM 元素。JS 列顯示了每一次單獨方法調用的執行時間--范圍在 1ms 到大于 100 ms。Size 列告訴了我們每次單獨的調用產生了多少次的 JavaScript/DOM 的方法調用(譯者注:指瀏覽器本地的調用)。這里我們也能明白,為什么某些 $ 調用花費了那么長時間,是因為它們實際進行了許多的調用來完成請求。Invocation 列告訴了我們該方法被它的父級所調用的頻度。這里我們可看出一些對象實際被解析了多次,比如: ".pop-cart"。***的做法應該是只解析一次得到對象并緩存起來。
這里我們學到的***課是上面多數調用是非必要的,只會產生過量的消耗。如果你明確知道你需要解析出哪些頁面元素,那就不要試圖去解析其他的對象。我知道,用全局的腳本文件來處理不同頁面中的不同內容會導致出現這樣的情況--但是--你是否真愿意在這種無謂的開銷中生活呢?
分析 jQuery選擇器的差異
在分析頁面上的***個問題是致使了太多的非必要 $ 調用。繼而帶來的另一個疑問就是為何某些 $ 方法響應很快(幾微秒),而有些卻用了相當長的時間(超過 100ms)。理論上的答案可以參看 jQuery Best Prtice Blog. 回到我的頁面中來,它向我提示了如下的結論:
ID 選擇器,也就是使用了 getElementById,是最快的
下圖展示了一個使用 ID 的選擇器。它使用了 getElementById,因此很快就返回了。

jQuery ID 選擇器
TagName 選擇器使用的是 getElementsByTagName
下面的例子是通過 TagName 搭配 ClassName 來選擇元素。jQuery 首先使用本地實現 getElementsByTagName 來獲得所有指定標簽的元素。接著遍歷它們針對 ClssName 進行過濾。

jQuery 的 Tag 和 ClassName 選擇器
ClassName 選擇器需要遍歷所有的 DOM 元素
如果你只用 ClassName 選擇器 - jQuery 需要遍歷 DOM 中的每一個元素,因為在 Internet Explorer(對于 FireFox 是另一番情景) 中沒有對應于 getElementsByClassName 的本地實現。下圖顯示了在一直有著 3460 個 DOM 元素的頁面中選擇器使用開銷的情況。

jQuery ClassName 選擇器
小結
依賴于你的 Web 站點的大小(指 DOM 元素的數量 ), 你需要考慮每個單獨的選擇器方法的開銷。相比于通過 ClassName 來選擇,你應該優先考慮用 TagName 搭配 ClassName 來選擇,或是在你的頁面只有少量對象時用唯一性的 ID 來選擇。而且- 確保緩存了已解析獲得的對象,以避免再次解析調用時的開始。還有 - ***也是應該予以重視的一點 - 避免不必要的調用。如前面頁面我所分析的 - 2 秒中有超過 1.5 秒是可以規避那些調用來省去的。
原文標題:101 on jQuery Selector Performance
原文地址:http://blog.dynatrace.com/2009/11/09/101-on-jquery-selector-performance/