CSS性能優化 - JavaShuo

提升性能的方法有哪些?

合併css文件減小http請求，若是頁面加載10個css文件,每一個文件1k，那麼也要比只加載一個100k的css文件慢。
減小css嵌套，加速css解析，最好不要嵌套三層以上。
不要在ID選擇器前面進行嵌套，ID原本就是惟一的並且權限值大，嵌套徹底是浪費性能。
創建公共樣式類，把相一樣式提取出來做爲公共類使用。
減小通配符*或者相似[hidden="true"]這類選擇器的使用，挨個查找全部...這性能能好嗎？
巧妙運用css的繼承機制，若是父節點定義了，子節點就無需定義。
拆分出公共css文件，對於比較大的項目能夠將大部分頁面的公共結構樣式提取出來放到單獨css文件裏，這樣一次下載後就放到緩存裏，固然這種作法會增長請求，具體作法應以實際狀況而定。
不用css表達式，表達式只是讓你的代碼顯得更加酷炫，可是對性能的浪費多是超乎你想象的。
少用css rest，可能會以爲重置樣式是規範，可是其實其中有不少操做是沒必要要不友好的，有需求有興趣，能夠選擇normolize.css。
cssSprite，合成全部icon圖片，用寬高加上background-position的背景圖方式顯現icon圖，這樣很實用，減小了http請求。
善後工做，css壓縮(在線壓縮工具 YUI Compressor)
GZIP壓縮，是一種流行的文件壓縮算法。

性能優化

1. 避免使用@import，外部的css文件中使用@import會使得頁面在加載時增長額外的延遲。css

首先，使用@import引入css會影響瀏覽器的並行下載。使用@import引用的css文件只有在引用它的那個css文件被下載，解析以後，瀏覽器纔會知道還有另一個css須要下載，這時纔去下載，而後下載後開始解析，構建render tree等一系列操做，這就致使瀏覽器沒法並行下載
所需的樣式文件。
其次，多個@import會致使下載順序紊亂，在IE中，@import會引起資源文件的下載順序被打亂，即排列在@import後面的js文件優先於@import下載，而且打亂甚至破壞@import自身的並行下載。
因此不要使用這一方法，使用link標籤就好了。webpack

2.避免過度重排css3

瀏覽器爲了從新渲染部分或整個頁面，從新計算頁面元素位置和幾何結構的進程叫作reflow
瀏覽器根據定義好的樣式來計算，並將元素放到該出現的位置上，這個過程叫作reflow
頁面上任何一個節點觸發來reflow，會致使他的子節點和祖先節點從新渲染
致使reflow發生的狀況

1. 改變窗口的大小  
 2. 改變文字的大小
 3. 添加 刪除樣式表
 4. 內容的改變 輸入框輸入內容也會
 5. 僞類的激活
 6. 操做class屬性 7. 腳本操做dom js改變css類 8. 計算offsetWidth和offsetHeight 9. 設置style屬性 10.改變元素的內外邊距 複製代碼

常見重排元素

1. 大小有關的 width,height,padding,margin,border-width,border,min-height
 2. 佈局有關的 display,top,position,float,left,right,bottom
 3. 字體有關的 font-size,text-align,font-weight,font-family,line-height,white-space,vertical-align
 4. 隱藏有關的 overflow,overflow-x,overflow-y
複製代碼

減小reflow對性能的影響的建議

1. 不要一條條的修改dom的樣式，預先定義好class，而後修改dom的classname 2. 不要修改影響範圍較大的dom 3. 爲動畫元素使用絕對定位 4. 不要table佈局，由於一個很小的改動會形成整個table從新佈局 5. 避免設置大量的style屬性，經過設置style屬性改變節點樣式的話，每一次設置都會觸發一次reflow，因此最好使用class屬性 6. 若是css裏面有計算表達式，每次都會從新計算一遍，觸發一次reflow 複製代碼

repaintweb

當一個元素的外觀被改變，可是佈局沒有改變的狀況
當元素改變的時候，不影響元素在頁面中的位置，瀏覽器僅僅會用新的樣式重繪此元素
常見的重繪元素

- 顏色 color,background
 - 邊框樣式 border-style,outline-color,outline,outline-style,border-radius,box-shadow,outline-width
 - 背景有關 background,backgound-image,background-position,background-repeat,background-size
複製代碼

CSS動畫算法

css動畫啓用GPU加速，應用GPU的圖形性能對瀏覽器中的一些圖形操做交給GPU完成。canvas2D，佈局合成，css3轉換，css3d變換，webGL，視頻
2d加速
3d加速

文件壓縮chrome

性能優化時最容易想到的，也是最多見的方法，就是文件壓縮，這一方案每每效果顯著
文件的大小會直接影響瀏覽器的加載速度，這一點在網絡較差時表現尤其明顯，構建工具webpack，gulp/grunt，rollup，壓縮以後可以明顯減小，能夠大大下降瀏覽器的加載時間。gulp

去除無用CSScanvas

雖然文件壓縮可以下降文件大小，但css文件壓縮一般只會去除無用的空格，這樣就限制來css文件的壓縮比例。若是壓縮後的文件仍然超過來預期的大小，能夠試着找到並刪除代碼中無用的css。
通常狀況下，會存在這兩種無用的CSS代碼：瀏覽器

不一樣元素或者其餘狀況下的重複代碼，
整個頁面內沒有生效的CSS代碼

有選擇地使用選擇器緩存

css選擇器的匹配是從右向左進行的，這一策略致使來不一樣種類的選擇器之間的性能也存在差別。相比於 #markdown-content-h3,顯然使用 #markdown.content h3時，瀏覽器生成渲染樹所要花費的時間更多。由於後者須要先找到DOM中的全部h3元素，再過濾掉祖先元素不是.content的，最後過濾掉.content不是#markdown的。試想，頁面中的元素更多，那麼匹配所要花費的時間代價天然更高。
顯得瀏覽器在這一方面作了不少優化，不一樣選擇器的性能差異並不明顯，甚至能夠說差異甚微，此外不一樣選擇器在不一樣瀏覽器中的性能表現也不統一，在編寫css的時候沒法兼顧每種瀏覽器，鑑於這兩點，在使用選擇器時，儘可能記住如下幾點：

1. 保持簡單，不要使用嵌套過多過於複雜的選擇器
 2. 通配符和屬性選擇器效率最低，須要匹配的元素最多，儘可能避免使用。
 3. 不要使用類選擇器和ID選擇器修飾元素標籤，如：h3#markdown-content，這一畫蛇添足，還會下降效率
 4. 不要爲了追求速度而放棄可讀性和可維護性
複製代碼

TIPS：爲何css選擇器是從右向左匹配的？
css中更多的選擇器是不會匹配的，因此在考慮性能問題時，須要考慮的是如何在選擇器不匹配時提高效率，從右向左匹配就是爲了達成這一目的的，經過這一策略可以使得css選擇器在不匹配的時候效率更高。

減小使用昂貴的屬性

在瀏覽器繪製屏幕時，全部須要瀏覽器進行操做或計算的屬性相對而言都須要花費更大的代價，而頁面發生重繪時，它們會下降瀏覽器的渲染性能。因此在編寫css時，應該儘可能減小使用昂貴屬性，如:
box-shadow, border-radius, filter, 透明度, :nth-child等
固然並非不要使用這些屬性，這些都是常用的屬性，只是這裏能夠做爲一個瞭解。當有其餘方案能夠選擇的時候，能夠優先選擇沒有昂貴屬性或昂貴屬性更少的方案，這一網站的性能會在不知不覺中獲得必定的提高。

硬件加速的好壞

僅僅依靠GPU仍是不行的，許多動畫仍是須要CPU的介入，鏈接cpu和GPU的總帶寬不是無限的，因此須要注意數據在cpu和GPU之間的傳輸，儘可能避免形成通道的擁擠，要一直注意像素的傳輸。
一個重點是瞭解建立的合成層的數量，每個層都對應來一個GPU紋理，太多的層會消耗不少內存。
chrome://flags/#composited-layer-borders觀察的地址。
每個dom元素的合成層都會被標記一個額外的邊框，這一就能夠驗證是否有了不少層
另外一個重點是保持GPU和CPU之間傳輸量達到最小值，也就是說，層的更新數量最好是一個理想的常量，每次層更新的時候，一堆新的像素就可能須要傳輸給GPU。
由於爲了高性能，動畫開始以後避免層的更新也是很是重要的，避免動畫進行中其餘層一直更新致使擁堵。
也就是使用這些css屬性來實現動畫：transformation, opacity, filter
使用性能工具檢測優化的合理性，timeline檢測優化是否合理，還須要實現自動操做來作性能迴歸測試。
檢測層數和層更新次數是很是有用的。