CSS選擇器對性能的影響源於瀏覽器匹配選擇器和文檔元素時所消耗的時間,因此優化選擇器的原則是應儘可能避免須要消耗更多匹配時間的選擇器。而在這以前咱們須要瞭解CSS選擇器匹配的機制,如例子的子選擇器規則: 瀏覽器
#header > a {font-weight:blod;}
咱們中的大多數人都是從左到右的閱讀習慣,可能也會習慣性的設定瀏覽器也是從左到右的方式進行匹配規則,由於會推測這條規則的開銷並不高。咱們這樣假象瀏覽器會像這樣的方式工做:找到惟一的id爲header爲的元素,而後把這個樣式規則應用到直系子元素中的a元素上。咱們知道文檔中只有一個id爲header的元素,而且它只有幾個a類型的子節點,因此這個CSS選擇器應該至關高效。 性能
事實上,卻剛好相反,CSS選擇器是從右到左進行規則匹配。瞭解這個機制後,例子中看似高效的選擇器在實際中的匹配開銷是很高的,瀏覽器必須遍歷頁面中全部的a元素而且肯定其父元素的id是否爲header。 字體
若是把例子的子選擇器改成後代選擇器則會開銷更多,在遍歷頁面中全部a元素後還需向其上級遍歷直到根節點。 優化
#header a {font-weight:blod;}
理解了CSS選擇器從右到左匹配的機制後,能夠理解選擇器中最右邊的規則每每決定了瀏覽器繼續左移匹配的工做量,咱們把最右邊選擇規則稱之爲關鍵選擇器。 code
通配選擇器使用 * 符合表示,可匹配文檔中的每個元素。以下例規則將全部元素的字體大小設置爲20px: 文檔
* { font-size:20px;}
通配選擇器做用於全部的元素,如規則最右邊爲通配符: class
.selected * {color: red;}
瀏覽器匹配文檔中全部的元素後分別向上逐級匹配class爲selected的元素,直到文檔的根節點,所以其匹配開銷是很是大的,一般比開銷最小的ID選擇器高出1~3個數量級,因此應避免使用關鍵選擇器是通配選擇器的規則。 select