css
選擇器對效能的影響源於瀏覽器匹配選擇器和文件元素時所消耗的時間，所以優化選擇器的原則是應盡量避免使用消耗更多匹配時間的選擇器。而在這之前我們需要了解css選擇器匹配的機制， 如子選擇器規則：
#header > a我們會假設瀏覽器以這樣的方式工作：尋找 id 為 header 的元素，然後將樣式規則應用到直系子元素中的 a 元素上。我們知道文件中只有乙個 id 為 header 的元素，並且它只有幾個 a 元素的子節點，所以這個css選擇器應該相當高效。
事實上，卻恰恰相反，css選擇器是從右到左進行規則匹配。了解這個機制後，例子中看似高效的選擇器在實際中的匹配開銷是很高的，瀏覽器必須遍歷頁面中所有的 a 元素並且確定其父元素的 id 是否為 header 。
如果把例子的子選擇器改為後代選擇器則會開銷更多，在遍歷頁面中所有 a 元素後還需向其上級遍歷直到根節點。
#header a如何減少 css 選擇器效能損耗？
google 資深web開發工程師 steve souders 對 css 選擇器的執行效率從高到低做了乙個排序：
1.id選擇器（#myid）根據以上「選擇器匹配」與「選擇器執行效率」原則，我們可以通過避免不恰當的使用，提公升 css 選擇器效能。2.類選擇器（.myclassname）
3.標籤選擇器（div,h1,p）
4.相鄰選擇器（h1+p）
5.子選擇器（ul < li）
6.後代選擇器（li a）
7.萬用字元選擇器（*）
8.屬性選擇器（a[rel="external"]）
9.偽類選擇器（a:hover, li:nth-child）
1、避免使用通用選擇器
.content *2、避免使用標籤或 class 選擇器限制 id 選擇器
bad
button#backbutton
bad.menu-left#newmenuicon
good
#backbutton
good
#newmenuicon
bad
treecell.indented
good
.treecell-indented
best
.hierarchy-deep
bad
treeitem[mailfolder="true"] > treerow > treecell
good
.treecell-mailfolder
bad
treehead treerow treecell
better, but still bad
treehead > treerow > treecell
good
.treecell-header
bad
#bookmarkmenuitem > .menu-left
good
#bookmarkmenuitem
作為一名前端工程師，應該具有「提公升 css 選擇器效能」的意識，但實際應用中，是否需要完全貫徹這些原則呢？這是乙個探索「追求高效能」與「可維護性」兩者平衡的問題。
對於「**」，每個頁面的 dom 元素超過1000個以上的**來說，通過限制 css 選擇器，改善效能是具有實際意義的。但對於普通**，我更傾向於保證「語義化」和「可維護性」的前提下，提公升 css 選擇器效能。
參考
「1」efficiently rendering css
「2」writing efficient css
「3」performance impact of css selectors
「4」css test creator
「5」高效能css
「6」如何撰寫有效率的css選擇器
CSS 選擇器效能提公升
css 選擇器效能損耗來自?css選擇器對效能的影響源於瀏覽器匹配選擇器和文件元素時所消耗的時間，所以優化選擇器的原則是應盡量避免使用消耗更多匹配時間的選擇器。而在這之前我們需要了解css選擇器匹配的機制，如子選擇器規則 header a 我們中的大多數人都是從左到右的閱讀習慣，會習慣性的設定瀏覽器...
css選擇器效能情況
選擇器效率從高到低的排序列表 id選擇器 id 類選擇器 classname 標籤選擇器 div,h1,p 相鄰選擇器 h1 p 子選擇器 ul li 後代選擇器 li a 萬用字元選擇器 屬性選擇器 a rel external 偽類選擇器 a hover,li nth child 決定選擇器效能...
CSS選擇器效能分析
寫了幾篇關於js的部落格，也是關於效能的，現在，我覺得有必要那css來認真分析一下了。之前只是看別人這麼寫就跟著寫，但是沒有去研究這樣寫或者是不是正確的寫法，價效比怎麼樣，渲染的效率好麼！這些都沒有考慮。那麼，現在，我提出css的一些選擇器的效能分析。0 這樣寫完了以後，渲染的效果至少呈現出來了，可...