武林網(www.survivalescaperooms.com)文章簡介：對大多數網站而言，優化CSS選擇器活得的性能提升很小，不值得去計較。有些配合Javascript交互的CSS規則會明顯的拖慢頁面。這是應該關注的焦點。所以我開始關注現實中影響頁面性能的CSS樣式相關的小問題。

本文是《Even Faster Web Sites: Performance Best Practices for Web Developers (Paperback)》的最后一章。上篇帖子《Performance Impact of CSS Selectors》（中文版）最后提出了一段假設：

對大多數網站而言，優化CSS選擇器活得的性能提升很小，不值得去計較。有些配合Javascript交互的CSS規則會明顯的拖慢頁面。這是應該關注的焦點。所以我開始關注現實中影響頁面性能的CSS樣式相關的小問題。

我收到了很多反饋。David Hyatt的文章《Writing Efficient CSS for use in the Mozilla UI》披露：

樣式系統渲染一條規則是從最右邊開始之后依次向左移動。在你的小子樹(subtree)持續檢測的時候，樣式系統將繼續向左側移動直到它不匹配CSS規則或匹配錯誤。

由此得出，我們優化工作的重點應該是：匹配大量頁面元素的最右側的CSS選擇器。我上篇博文測試的CSS選擇器看起來很費性能，但是按這條新觀點審視，我們發覺這其實不值得擔心，比如：

這個選擇器有5層，看起來很復雜，但是我們來看最右側的選擇器 A.class0007 ，我們發現，在整個頁面中需要瀏覽器逆向匹配的只有一個元素。

優化CSS選擇器的關鍵點在于最右側的選擇器，也叫做key selector (巧合？)。有一個更昂貴的選擇器

盡管這個選擇器看起來更簡單，但對瀏覽器匹配而言更昂貴。因為瀏覽器要從右至左，開始后要檢查匹配 * 的所有元素。這意味著瀏覽器會嘗試匹配頁面中的所有元素。下圖為普通選擇器與先前的后代選擇器加載時間的對比：

它清晰的反映出一個匹配很多元素的key selector會嚴重的拖慢頁面。其他可能會大量增加瀏覽器工作的key selector包括：

不是所有的CSS選擇器傷害性能，盡管看起來如此。CSS選擇器的關鍵點在于泛匹配的key selector。這對于含有大量DOM元素、CSS規則，更高 reflow 的Web 2.0應用更加重要。