儘管css選擇器效率問題已經不是什麼新鮮問題,可是我以爲仍是有必要拿出來認真分析一下。以前只是看到別人這麼寫我也跟着這麼寫,並無想清楚問什麼要這樣寫?這樣寫真的能提升頁面渲染效率嗎?儘管本身技術不怎麼樣,但仍是須要拿出一種打破砂鍋問到底的決心來深究一下css選擇器效率問題,經過本身寫個demo親自實踐來加深一下對這個問題的理解。
事情的通過是這樣子的,在以前的博文CSS選擇器總結中介紹了各類不一樣的css選擇器,頓時以爲css的世界很精彩,能夠有不少種不一樣的寫法,想怎麼寫就怎麼寫,因而就有了這種代碼css
.wrapper ul li a{color:red;……} .wrapper .list p.name{margin:10px 0;……} * {margin:0;padding:0} ……
寫完這樣樣式後,自我感受還不錯,至少頁面能呈現出來。但是直到有一天忽然發現html
CSS選擇器從右向左的匹配規則web
個人世界瞬間崩塌了,由於根據閱讀習慣在編寫CSS的時候也會天然而然是從左向右逐漸細化。頓時很想搞清楚瀏覽器在將DOM tree變成render tree的時候css規則是如何匹配的?因而查了這麼些資料:瀏覽器
看了這麼多個人理解是從右往左匹配會首先過濾掉一大批不符合規則的樣式,從而使得效率更高。舉個例子app
.wrapper .list a .demo{……}
若是從左往右匹配會先找到.wrapper,而後再找到裏面不少的.list,在往裏找直到找到那個.demo,查找的越深,過濾掉的也就越多,在這個查找的過程當中會有不少沒用的樣式也被遍歷過,這裏就致使匹配的效率很低。
若是從右向左匹配會首先過濾掉不是.demo的元素,在依次往上查找,越往上過濾掉的也就越少,這樣效率明顯比從左往右匹配要高不少
弄明白了從右向左匹配的規則那麼咱們要如何寫才能讓瀏覽器更快的匹配到呢?
瀏覽器在面對衆多的CSS樣式代碼時並非毫無規則的一個一個匹配,而是先將樣式規則分爲四個主要類別:ide
並引入關鍵選擇器的概念(選擇器最後的那部分)性能
.wrapper ul li a{color:red;……} /* 關鍵選擇器爲a */ .wrapper .list p.name{margin:10px 0;……} /* 關鍵選擇器爲.name */
根據關鍵選擇器屬於哪類再在這一類中查找,從而達到更快匹配的目的。那麼問題來了,怎樣寫才能達到高效呢?
CSS選擇器效率從高到低的排序以下:網站
以上引用自Steve Souders的Even Faster網站
在實際使用中咱們儘可能選擇高效一點的選擇器,可是有一點很難避免那就是組合選擇器的使用,通常都會用到。在使用組合選擇器時咱們須要注意一下幾點:ui
原本想寫幾個demo展現出不一樣選擇器的效率的,可是很差演示,你們能夠看看CSS selector performance
這篇文章中介紹了20中不一樣的選擇器的執行效率問題。code
結合本身的實踐經歷,在編寫CSS規則時需注意如下幾點:
CSS選擇器在性能提高上儘管相對於js等提高空間不大,但在大型項目中高效率的css選擇器的性能優點就能獲得展示
原文連接:http://www.jesse131.cn/blog/2016/12/05/HTML-CSS/CSS_selector_performance.html