您好,登錄后才能下訂單哦!
這篇文章主要介紹了CSS性能優化的一些小技巧,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
css是一種用來表現HTML或XML等文件樣式的計算機語言,主要是用來設計網頁的樣式,使網頁更加美化。它也是一種定義樣式結構如字體、顏色、位置等的語言,并且css樣式可以直接存儲于HTML網頁或者單獨的樣式單文件中,而樣式規則的優先級由css根據這個層次結構決定,從而實現級聯效果,發展至今,css不僅能裝飾網頁,也可以配合各種腳本對于網頁進行格式化。
實踐型的4個優化技巧,先從首屏關鍵CSS開始。
性能優化中有一個重要的指標——首次有效繪制(First Meaningful Paint,簡稱FMP)即指頁面的首要內容(primary content)出現在屏幕上的時間。這一指標影響用戶看到頁面前所需等待的時間,而**內聯首屏關鍵CSS(即Critical CSS,可以稱之為首屏關鍵CSS)**能減少這一時間。
大家應該都習慣于通過link標簽引用外部CSS文件。但需要知道的是,將CSS直接內聯到HTML文檔中能使CSS更快速地下載。而使用外部CSS文件時,需要在HTML文檔下載完成后才知道所要引用的CSS文件,然后才下載它們。所以說,內聯CSS能夠使瀏覽器開始頁面渲染的時間提前,因為在HTML下載完成之后就能渲染了。
既然內聯CSS能夠使頁面渲染的開始時間提前,那么是否可以內聯所有的CSS呢?答案顯然是否定的,這種方式并不適用于內聯較大的CSS文件。因為初始擁塞窗口3存在限制(TCP相關概念,通常是 14.6kB,壓縮后大小),如果內聯CSS后的文件超出了這一限制,系統就需要在服務器和瀏覽器之間進行更多次的往返,這樣并不能提前頁面渲染時間。因此,我們應當只將渲染首屏內容所需的關鍵CSS內聯到HTML中。
既然已經知道內聯首屏關鍵CSS能夠優化性能了,那下一步就是如何確定首屏關鍵CSS了。顯然,我們不需要手動確定哪些內容是首屏關鍵CSS。Github上有一個項目Critical CSS4,可以將屬于首屏的關鍵樣式提取出來,大家可以看一下該項目,結合自己的構建工具進行使用。當然為了保證正確,大家最好再親自確認下提取出的內容是否有缺失。
不過內聯CSS有一個缺點,內聯之后的CSS不會進行緩存,每次都會重新下載。不過如上所說,如果我們將內聯后的文件大小控制在了14.6kb以內,這似乎并不是什么大問題。
如上,我們已經介紹了為什么要內聯關鍵CSS以及如何內聯,那么剩下的CSS我們怎么處理好呢?建議使用外部CSS引入剩余CSS,這樣能夠啟用緩存,除此之外還可以異步加載它們。
CSS會阻塞渲染,在CSS文件請求、下載、解析完成之前,瀏覽器將不會渲染任何已處理的內容。有時,這種阻塞是必須的,因為我們并不希望在所需的CSS加載之前,瀏覽器就開始渲染頁面。那么將首屏關鍵CSS內聯后,剩余的CSS內容的阻塞渲染就不是必需的了,可以使用外部CSS,并且異步加載。
那么如何實現CSS的異步加載呢?有以下四種方式可以實現瀏覽器異步加載CSS
。
第一種方式是使用JavaScript動態創建樣式表link元素,并插入到DOM中。
// 創建link標簽 const myCSS = document.createElement( "link" ); myCSS.rel = "stylesheet"; myCSS.href = "mystyles.css"; // 插入到header的最后位置 document.head.insertBefore( myCSS, document.head.childNodes[ document.head.childNodes.length - 1 ].nextSibling );
第二種方式是將link元素的media屬性設置為用戶瀏覽器不匹配的媒體類型(或媒體查詢),如media=“print”,甚至可以是完全不存在的類型media=“noexist”。對瀏覽器來說,如果樣式表不適用于當前媒體類型,其優先級會被放低,會在不阻塞頁面渲染的情況下再進行下載。
當然,這么做只是為了實現CSS的異步加載,別忘了在文件加載完成之后,將media的值設為screen或all,從而讓瀏覽器開始解析CSS。
<link rel="stylesheet" href="mystyles.css" media="noexist" onload="this.media='all'">
與第二種方式相似,我們還可以通過rel屬性將link元素標記為alternate可選樣式表,也能實現瀏覽器異步加載。同樣別忘了加載完成之后,將rel改回去。
<link rel="alternate stylesheet" href="mystyles.css" onload="this.rel='stylesheet'">
上述的三種方法都較為古老。現在,rel="preload"5這一Web標準指出了如何異步加載資源,包括CSS類資源。
<link rel="preload" href="mystyles.css" as="style" onload="this.rel='stylesheet'">
注意,as是必須的。忽略as屬性,或者錯誤的as屬性會使preload等同于XHR請求,瀏覽器不知道加載的是什么內容,因此此類資源加載優先級會非常低。as的可選值可以參考上述標準文檔。
看起來,rel="preload"的用法和上面兩種沒什么區別,都是通過更改某些屬性,使得瀏覽器異步加載CSS文件但不解析,直到加載完成并將修改還原,然后開始解析。
但是它們之間其實有一個很重要的不同點,那就是使用preload,比使用不匹配的media方法能夠更早地開始加載CSS。所以盡管這一標準的支持度還不完善,仍建議優先使用該方法。
該標準現在已經是候選標準,相信瀏覽器會逐漸支持該標準。在各瀏覽器的支持度如下圖所。
性能優化時有一個最容易想到,也最常使用的方法,那就是文件壓縮,這一方案往往效果顯著。
文件的大小會直接影響瀏覽器的加載速度,這一點在網絡較差時表現地尤為明顯。相信大家都早已習慣對CSS進行壓縮,現在的構建工具,如webpack、gulp/grunt、rollup等也都支持CSS壓縮功能。壓縮后的文件能夠明顯減小,可以大大降低了瀏覽器的加載時間。
雖然文件壓縮能夠降低文件大小。但CSS文件壓縮通常只會去除無用的空格,這樣就限制了CSS文件的壓縮比例。那是否還有其他手段來精簡CSS呢?答案顯然是肯定的,如果壓縮后的文件仍然超出了預期的大小,我們可以試著找到并刪除代碼中無用的CSS。
一般情況下,會存在這兩種無用的CSS代碼:一種是不同元素或者其他情況下的重復代碼,一種是整個頁面內沒有生效的CSS代碼。對于前者,在編寫的代碼時候,我們應該盡可能地提取公共類,減少重復。對于后者,在不同開發者進行代碼維護的過程中,總會產生不再使用的CSS的代碼,當然一個人編寫時也有可能出現這一問題。而這些無用的CSS代碼不僅會增加瀏覽器的下載量,還會增加瀏覽器的解析時間,這對性能來說是很大的消耗。所以我們需要找到并去除這些無用代碼。
當然,如果手動刪除這些無用CSS是很低效的。我們可以借助Uncss7庫來進行。Uncss可以用來移除樣式表中的無用CSS,并且支持多文件和JavaScript注入的CSS。
前面已經說完了實踐型的4個優化技巧,下面我們介紹下建議型的4個技巧。
大多數朋友應該都知道CSS選擇器的匹配是從右向左進行的,這一策略導致了不同種類的選擇器之間的性能也存在差異。相比于#markdown-content-h4,顯然使用#markdown .content h4時,瀏覽器生成渲染樹(render-tree)所要花費的時間更多。因為后者需要先找到DOM中的所有h4元素,再過濾掉祖先元素不是.content的,最后過濾掉.content的祖先不是#markdown的。試想,如果嵌套的層級更多,頁面中的元素更多,那么匹配所要花費的時間代價自然更高。
不過現代瀏覽器在這一方面做了很多優化,不同選擇器的性能差別并不明顯,甚至可以說差別甚微。此外不同選擇器在不同瀏覽器中的性能表現8也不完全統一,在編寫CSS的時候無法兼顧每種瀏覽器。鑒于這兩點原因,我們在使用選擇器時,只需要記住以下幾點,其他的可以全憑喜好。
保持簡單,不要使用嵌套過多過于復雜的選擇器。
通配符和屬性選擇器效率最低,需要匹配的元素最多,盡量避免使用。
不要使用類選擇器和ID選擇器修飾元素標簽,如h4#markdown-content,這樣多此一舉,還會降低效率。
不要為了追求速度而放棄可讀性與可維護性。
如果大家對于上面這幾點還存在疑問,筆者建議大家選擇以下幾種CSS方法論之一(BEM9,OOCSS10,SUIT11,SMACSS12,ITCSS13,Enduring CSS14等)作為CSS編寫規范。使用統一的方法論能夠幫助大家形成統一的風格,減少命名沖突,也能避免上述的問題,總之好處多多,如果你還沒有使用,就趕快用起來吧。
Tips:為什么CSS選擇器是從右向左匹配的?
CSS中更多的選擇器是不會匹配的,所以在考慮性能問題時,需要考慮的是如何在選擇器不匹配時提升效率。從右向左匹配就是為了達成這一目的的,通過這一策略能夠使得CSS選擇器在不匹配的時候效率更高。這樣想來,在匹配時多耗費一些性能也能夠想的通了。
在瀏覽器繪制屏幕時,所有需要瀏覽器進行操作或計算的屬性相對而言都需要花費更大的代價。當頁面發生重繪時,它們會降低瀏覽器的渲染性能。所以在編寫CSS時,我們應該盡量減少使用昂貴屬性,如box-shadow/border-radius/filter/透明度/:nth-child等。
當然,并不是讓大家不要使用這些屬性,因為這些應該都是我們經常使用的屬性。之所以提這一點,是讓大家對此有一個了解。當有兩種方案可以選擇的時候,可以優先選擇沒有昂貴屬性或昂貴屬性更少的方案,如果每次都這樣的選擇,網站的性能會在不知不覺中得到一定的提升。
在網站的使用過程中,某些操作會導致樣式的改變,這時瀏覽器需要檢測這些改變并重新渲染,其中有些操作所耗費的性能更多。我們都知道,當FPS為60時,用戶使用網站時才會感到流暢。這也就是說,我們需要在16.67ms內完成每次渲染相關的所有操作,所以我們要盡量減少耗費更多的操作。
3.1 減少重排
重排會導致瀏覽器重新計算整個文檔,重新構建渲染樹,這一過程會降低瀏覽器的渲染速度。如下所示,有很多操作會觸發重排,我們應該避免頻繁觸發這些操作。
改變font-size和font-family
改變元素的內外邊距
通過JS改變CSS類
通過JS獲取DOM元素的位置相關屬性(如width/height/left等)
CSS偽類激活
滾動滾動條或者改變窗口大小
此外,我們還可以通過CSS Trigger15查詢哪些屬性會觸發重排與重繪。
值得一提的是,某些CSS屬性具有更好的重排性能。如使用Flex時,比使用inline-block和float時重排更快,所以在布局時可以優先考慮Flex。
3.2 避免不必要的重繪
當元素的外觀(如color,background,visibility等屬性)發生改變時,會觸發重繪。在網站的使用過程中,重繪是無法避免的。不過,瀏覽器對此做了優化,它會將多次的重排、重繪操作合并為一次執行。不過我們仍需要避免不必要的重繪,如頁面滾動時觸發的hover事件,可以在滾動的時候禁用hover事件,這樣頁面在滾動時會更加流暢。
此外,我們編寫的CSS中動畫相關的代碼越來越多,我們已經習慣于使用動畫來提升用戶體驗。我們在編寫動畫時,也應當參考上述內容,減少重繪重排的觸發。除此之外我們還可以通過硬件加速16和will-change17來提升動畫性能,本文不對此展開詳細介紹,感興趣的小伙伴可以點擊鏈接進行查看。
最后需要注意的是,用戶的設備可能并沒有想象中的那么好,至少不會有我們的開發機器那么好。我們可以借助Chrome的開發者工具進行CPU降速,然后再進行相關的測試
如果需要在移動端訪問的,最好將速度限制更低,因為移動端的性能往往更差。
最后提一下,不要使用@import引入CSS,相信大家也很少使用。
不建議使用@import主要有以下兩點原因。
首先,使用@import引入CSS會影響瀏覽器的并行下載。使用@import引用的CSS文件只有在引用它的那個css文件被下載、解析之后,瀏覽器才會知道還有另外一個css需要下載,這時才去下載,然后下載后開始解析、構建render tree等一系列操作。這就導致瀏覽器無法并行下載所需的樣式文件。
其次,多個@import會導致下載順序紊亂。在IE中,@import會引發資源文件的下載順序被打亂,即排列在@import后面的js文件先于@import下載,并且打亂甚至破壞@import自身的并行下載。
所以不要使用這一方法,使用link標簽就行了。
感謝你能夠認真閱讀完這篇文章,希望小編分享的“CSS性能優化的一些小技巧”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。