|
本文作者高峰，360奇舞團前端工程師，W3C性能工作組成員，同時參與WOT工作組的學習。博客地址：http:/// 我們都知道對于網(wǎng)站來說，性能至關(guān)重要，CSS作為頁面渲染和內(nèi)容展現(xiàn)的重要環(huán)節(jié)，影響著用戶對整個網(wǎng)站的第一體驗。因此，與其相關(guān)的性能優(yōu)化是不容忽視的。 對于性能優(yōu)化我們常常在項目完成時才去考慮，經(jīng)常被推遲到項目的末期，甚至到暴露出嚴重的性能問題時才進行性能優(yōu)化，相信大多數(shù)人對此深有體會。 筆者認為，為了更多地避免這一情況，首先要重視起性能優(yōu)化相關(guān)的工作，將其貫穿到整個產(chǎn)品設(shè)計與開發(fā)中。其次，就是了解性能相關(guān)的內(nèi)容，在項目開發(fā)過程中，自然而然地進行性能優(yōu)化。最后，也是最最重要的，那就是從現(xiàn)在開始實施優(yōu)化。 推薦大家閱讀下奇舞周刊之前推的《嗨，送你一張Web性能優(yōu)化地圖》1這篇文章，能夠幫助大家對性能優(yōu)化需要做的事以及需要考慮的問題形成一個整體的概念。 本文將會詳細介紹CSS性能優(yōu)化相關(guān)的技巧，筆者將它們分為實踐型和建議型兩類，共8個小技巧。實踐型技巧能夠快速地應(yīng)用在項目中，能夠很好地提升性能，也是筆者經(jīng)常使用的，建議大家盡快在項目中實踐。建議型技巧中，有的可能對性能影響并不顯著，有的平時大家也并不會那么用，所以筆者不會著重講述，讀者們可以根據(jù)自身情況了解一下即可。 在正式開始之前，需要大家對于瀏覽器的工作原理2有些一定的了解，需要的小伙伴可以先簡單了解下。 下面我們開始介紹實踐型的4個優(yōu)化技巧，先從首屏關(guān)鍵CSS開始。 1. 內(nèi)聯(lián)首屏關(guān)鍵CSS（Critical CSS）性能優(yōu)化中有一個重要的指標——首次有效繪制（First Meaningful Paint，簡稱FMP）即指頁面的首要內(nèi)容（primary content）出現(xiàn)在屏幕上的時間。這一指標影響用戶看到頁面前所需等待的時間，而內(nèi)聯(lián)首屏關(guān)鍵CSS（即Critical CSS，可以稱之為首屏關(guān)鍵CSS）能減少這一時間。 大家應(yīng)該都習慣于通過link標簽引用外部CSS文件。但需要知道的是，將CSS直接內(nèi)聯(lián)到HTML文檔中能使CSS更快速地下載。而使用外部CSS文件時，需要在HTML文檔下載完成后才知道所要引用的CSS文件，然后才下載它們。所以說，內(nèi)聯(lián)CSS能夠使瀏覽器開始頁面渲染的時間提前，因為在HTML下載完成之后就能渲染了。 既然內(nèi)聯(lián)CSS能夠使頁面渲染的開始時間提前，那么是否可以內(nèi)聯(lián)所有的CSS呢？答案顯然是否定的，這種方式并不適用于內(nèi)聯(lián)較大的CSS文件。因為初始擁塞窗口3存在限制（TCP相關(guān)概念，通常是 14.6kB，壓縮后大?。?，如果內(nèi)聯(lián)CSS后的文件超出了這一限制，系統(tǒng)就需要在服務(wù)器和瀏覽器之間進行更多次的往返，這樣并不能提前頁面渲染時間。因此，我們應(yīng)當只將渲染首屏內(nèi)容所需的關(guān)鍵CSS內(nèi)聯(lián)到HTML中。 既然已經(jīng)知道內(nèi)聯(lián)首屏關(guān)鍵CSS能夠優(yōu)化性能了，那下一步就是如何確定首屏關(guān)鍵CSS了。顯然，我們不需要手動確定哪些內(nèi)容是首屏關(guān)鍵CSS。Github上有一個項目Critical CSS4，可以將屬于首屏的關(guān)鍵樣式提取出來，大家可以看一下該項目，結(jié)合自己的構(gòu)建工具進行使用。當然為了保證正確，大家最好再親自確認下提取出的內(nèi)容是否有缺失。 不過內(nèi)聯(lián)CSS有一個缺點，內(nèi)聯(lián)之后的CSS不會進行緩存，每次都會重新下載。不過如上所說，如果我們將內(nèi)聯(lián)后的文件大小控制在了14.6kb以內(nèi)，這似乎并不是什么大問題。 如上，我們已經(jīng)介紹了為什么要內(nèi)聯(lián)關(guān)鍵CSS以及如何內(nèi)聯(lián)，那么剩下的CSS我們怎么處理好呢？建議使用外部CSS引入剩余CSS，這樣能夠啟用緩存，除此之外還可以異步加載它們。 2. 異步加載CSSCSS會阻塞渲染，在CSS文件請求、下載、解析完成之前，瀏覽器將不會渲染任何已處理的內(nèi)容。有時，這種阻塞是必須的，因為我們并不希望在所需的CSS加載之前，瀏覽器就開始渲染頁面。那么將首屏關(guān)鍵CSS內(nèi)聯(lián)后，剩余的CSS內(nèi)容的阻塞渲染就不是必需的了，可以使用外部CSS，并且異步加載。 那么如何實現(xiàn)CSS的異步加載呢？有以下四種方式可以實現(xiàn)瀏覽器異步加載CSS。 第一種方式是使用JavaScript動態(tài)創(chuàng)建樣式表link元素，并插入到DOM中。
第二種方式是將link元素的media屬性設(shè)置為用戶瀏覽器不匹配的媒體類型（或媒體查詢），如media='print'，甚至可以是完全不存在的類型media='noexist'。對瀏覽器來說，如果樣式表不適用于當前媒體類型，其優(yōu)先級會被放低，會在不阻塞頁面渲染的情況下再進行下載。 當然，這么做只是為了實現(xiàn)CSS的異步加載，別忘了在文件加載完成之后，將media的值設(shè)為screen或all，從而讓瀏覽器開始解析CSS。
與第二種方式相似，我們還可以通過rel屬性將link元素標記為alternate可選樣式表，也能實現(xiàn)瀏覽器異步加載。同樣別忘了加載完成之后，將rel改回去。
上述的三種方法都較為古老?，F(xiàn)在，rel='preload'5這一Web標準指出了如何異步加載資源，包括CSS類資源。
注意，as是必須的。忽略as屬性，或者錯誤的as屬性會使preload等同于XHR請求，瀏覽器不知道加載的是什么內(nèi)容，因此此類資源加載優(yōu)先級會非常低。as的可選值可以參考上述標準文檔。 看起來，rel='preload'的用法和上面兩種沒什么區(qū)別，都是通過更改某些屬性，使得瀏覽器異步加載CSS文件但不解析，直到加載完成并將修改還原，然后開始解析。 但是它們之間其實有一個很重要的不同點，那就是使用preload，比使用不匹配的media方法能夠更早地開始加載CSS。所以盡管這一標準的支持度還不完善，仍建議優(yōu)先使用該方法。 該標準現(xiàn)在已經(jīng)是候選標準，相信瀏覽器會逐漸支持該標準。在各瀏覽器的支持度如下圖所示。 從上圖可以看出這一方法在現(xiàn)在的瀏覽器中支持度不算樂觀，不過我們可以通過loadCSS6進行polyfill，所以支持不支持，這都不是事兒。 3. 文件壓縮性能優(yōu)化時有一個最容易想到，也最常使用的方法，那就是文件壓縮，這一方案往往效果顯著。 文件的大小會直接影響瀏覽器的加載速度，這一點在網(wǎng)絡(luò)較差時表現(xiàn)地尤為明顯。相信大家都早已習慣對CSS進行壓縮，現(xiàn)在的構(gòu)建工具，如webpack、gulp/grunt、rollup等也都支持CSS壓縮功能。壓縮后的文件能夠明顯減小，可以大大降低了瀏覽器的加載時間。 4. 去除無用CSS雖然文件壓縮能夠降低文件大小。但CSS文件壓縮通常只會去除無用的空格，這樣就限制了CSS文件的壓縮比例。那是否還有其他手段來精簡CSS呢？答案顯然是肯定的，如果壓縮后的文件仍然超出了預期的大小，我們可以試著找到并刪除代碼中無用的CSS。 一般情況下，會存在這兩種無用的CSS代碼：一種是不同元素或者其他情況下的重復代碼，一種是整個頁面內(nèi)沒有生效的CSS代碼。對于前者，在編寫的代碼時候，我們應(yīng)該盡可能地提取公共類，減少重復。對于后者，在不同開發(fā)者進行代碼維護的過程中，總會產(chǎn)生不再使用的CSS的代碼，當然一個人編寫時也有可能出現(xiàn)這一問題。而這些無用的CSS代碼不僅會增加瀏覽器的下載量，還會增加瀏覽器的解析時間，這對性能來說是很大的消耗。所以我們需要找到并去除這些無用代碼。 當然，如果手動刪除這些無用CSS是很低效的。我們可以借助Uncss7庫來進行。Uncss可以用來移除樣式表中的無用CSS，并且支持多文件和JavaScript注入的CSS。 前面已經(jīng)說完了實踐型的4個優(yōu)化技巧，下面我們介紹下建議型的4個技巧。 1. 有選擇地使用選擇器大多數(shù)朋友應(yīng)該都知道CSS選擇器的匹配是從右向左進行的，這一策略導致了不同種類的選擇器之間的性能也存在差異。相比于#markdown-content-h3，顯然使用#markdown .content h3時，瀏覽器生成渲染樹（render-tree）所要花費的時間更多。因為后者需要先找到DOM中的所有h3元素，再過濾掉祖先元素不是.content的，最后過濾掉.content的祖先不是#markdown的。試想，如果嵌套的層級更多，頁面中的元素更多，那么匹配所要花費的時間代價自然更高。 不過現(xiàn)代瀏覽器在這一方面做了很多優(yōu)化，不同選擇器的性能差別并不明顯，甚至可以說差別甚微。此外不同選擇器在不同瀏覽器中的性能表現(xiàn)8也不完全統(tǒng)一，在編寫CSS的時候無法兼顧每種瀏覽器。鑒于這兩點原因，我們在使用選擇器時，只需要記住以下幾點，其他的可以全憑喜好。
如果大家對于上面這幾點還存在疑問，筆者建議大家選擇以下幾種CSS方法論之一（BEM9，OOCSS10，SUIT11，SMACSS12，ITCSS13，Enduring CSS14等）作為CSS編寫規(guī)范。使用統(tǒng)一的方法論能夠幫助大家形成統(tǒng)一的風格，減少命名沖突，也能避免上述的問題，總之好處多多，如果你還沒有使用，就趕快用起來吧。 Tips：為什么CSS選擇器是從右向左匹配的？
2. 減少使用昂貴的屬性在瀏覽器繪制屏幕時，所有需要瀏覽器進行操作或計算的屬性相對而言都需要花費更大的代價。當頁面發(fā)生重繪時，它們會降低瀏覽器的渲染性能。所以在編寫CSS時，我們應(yīng)該盡量減少使用昂貴屬性，如box-shadow/border-radius/filter/透明度/:nth-child等。 當然，并不是讓大家不要使用這些屬性，因為這些應(yīng)該都是我們經(jīng)常使用的屬性。之所以提這一點，是讓大家對此有一個了解。當有兩種方案可以選擇的時候，可以優(yōu)先選擇沒有昂貴屬性或昂貴屬性更少的方案，如果每次都這樣的選擇，網(wǎng)站的性能會在不知不覺中得到一定的提升。 3. 優(yōu)化重排與重繪在網(wǎng)站的使用過程中，某些操作會導致樣式的改變，這時瀏覽器需要檢測這些改變并重新渲染，其中有些操作所耗費的性能更多。我們都知道，當FPS為60時，用戶使用網(wǎng)站時才會感到流暢。這也就是說，我們需要在16.67ms內(nèi)完成每次渲染相關(guān)的所有操作，所以我們要盡量減少耗費更多的操作。 3.1 減少重排重排會導致瀏覽器重新計算整個文檔，重新構(gòu)建渲染樹，這一過程會降低瀏覽器的渲染速度。如下所示，有很多操作會觸發(fā)重排，我們應(yīng)該避免頻繁觸發(fā)這些操作。
此外，我們還可以通過CSS Trigger15查詢哪些屬性會觸發(fā)重排與重繪。 值得一提的是，某些CSS屬性具有更好的重排性能。如使用Flex時，比使用inline-block和float時重排更快，所以在布局時可以優(yōu)先考慮Flex。 3.2 避免不必要的重繪當元素的外觀（如color，background，visibility等屬性）發(fā)生改變時，會觸發(fā)重繪。在網(wǎng)站的使用過程中，重繪是無法避免的。不過，瀏覽器對此做了優(yōu)化，它會將多次的重排、重繪操作合并為一次執(zhí)行。不過我們?nèi)孕枰?strong>避免不必要的重繪，如頁面滾動時觸發(fā)的hover事件，可以在滾動的時候禁用hover事件，這樣頁面在滾動時會更加流暢。 此外，我們編寫的CSS中動畫相關(guān)的代碼越來越多，我們已經(jīng)習慣于使用動畫來提升用戶體驗。我們在編寫動畫時，也應(yīng)當參考上述內(nèi)容，減少重繪重排的觸發(fā)。除此之外我們還可以通過硬件加速16和will-change17來提升動畫性能，本文不對此展開詳細介紹，感興趣的小伙伴可以點擊鏈接進行查看。 最后需要注意的是，用戶的設(shè)備可能并沒有想象中的那么好，至少不會有我們的開發(fā)機器那么好。我們可以借助Chrome的開發(fā)者工具進行CPU降速，然后再進行相關(guān)的測試，降速方法如下圖所示。 如果需要在移動端訪問的，最好將速度限制更低，因為移動端的性能往往更差。 4. 不要使用@import最后提一下，不要使用@import引入CSS，相信大家也很少使用。 不建議使用@import主要有以下兩點原因。 首先，使用@import引入CSS會影響瀏覽器的并行下載。使用@import引用的CSS文件只有在引用它的那個css文件被下載、解析之后，瀏覽器才會知道還有另外一個css需要下載，這時才去下載，然后下載后開始解析、構(gòu)建render tree等一系列操作。這就導致瀏覽器無法并行下載所需的樣式文件。 其次，多個@import會導致下載順序紊亂。在IE中，@import會引發(fā)資源文件的下載順序被打亂，即排列在@import后面的js文件先于@import下載，并且打亂甚至破壞@import自身的并行下載。 所以不要使用這一方法，使用link標簽就行了。 總結(jié)至此，我們介紹完了CSS性能優(yōu)化的4個實踐型技巧和4個建議型技巧，在了解這些技巧之后，CSS的性能優(yōu)化從現(xiàn)在就可以開始了。不要猶豫了，盡快開始吧。 致謝特別感謝@anjia(安佳)、@劉宇晨、@hxl(黃小璐)、@劉觀宇的辛苦審校，感謝你們對于文章結(jié)構(gòu)和內(nèi)容提出的寶貴建議。 文內(nèi)鏈接
參考文章
|
|
|
