溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了CSS和網絡性能的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
CSS 是頁面渲染的關鍵因素之一，（當頁面存在外鏈 CSS 時，）瀏覽器會等待全部的 CSS 下載及解析完成后再渲染頁面。關鍵路徑上的任何延遲都會影響首屏時間，因而我們需要盡快地將 CSS 傳輸到用戶的設備，否則，（在頁面渲染之前，）用戶只能看到一個空白的屏幕。
廣義而言，CSS 是（渲染）性能的關鍵，這是由于：
瀏覽器直到渲染樹構建完成后才會渲染頁面；
渲染樹由 DOM 與 CSSOM 組合而成；
DOM 是 HTML 加上（同步）阻塞的 JavaScript 操作（DOM 后的）結果；
CSSOM 是 CSS 規則應用于 DOM 后的結果；
使 JavaScript 非阻塞非常簡單，添加 async 或 defer 屬性即可；
相對而言，要讓 CSS 變為異步加載是比較困難的；
所以記住這條經驗法則：（理想情況下，）最慢樣式表的下載時間決定了頁面渲染的時間。
基于上述考慮，我們需要盡快構建 DOM 與 CSSOM。一般情況下，DOM 的構建是相對較快，（當請求某個頁面時，）服務器響應的首個請求是 HTML 文檔。但一般 CSS 是作為 HTML 的子資源而存在，因此 CSSOM 的構建通常需要更長的時間。
在這篇文章中，會講述 CSS 為何是網絡瓶頸（無論是對于它自己或是其他資源），該如何突破它，從而縮短關鍵路徑以減少首次渲染前的等待時間。
如果條件允許，縮短渲染前等待時間最有效的方式就是使用 Critical CSS （關鍵 CSS）模式：找出首次渲染所需的樣式（通常是首屏相關的樣式），將它們內聯到 <head> 標簽中，其他樣式則通過異步的方式進行加載。
雖然這十分有效，但實施起來卻并不容易，比如：高度動態化的網站（譯者注：如 SPA）通常難以提取首屏相關的樣式、提取的過程需要自動化、需要對首屏不同元素顯示或隱藏的狀態作出假設、某些邊界情況難以處理以及相關工具仍未成熟等問題。如果你的項目相當龐大或是有歷史包袱，這將變得更為復雜。
如果在項目組難以執行關鍵 CSS 策略，可以嘗試根據媒體查詢拆分 CSS 文件，這也是一種可靠的策略。執行此策略后，瀏覽器表現如下：
以非常高的優先級下載符合當前上下文（設備、屏幕尺寸、分辨率、方向等）的 CSS 文件，阻塞關鍵路徑；
以非常低的優先級下載不符合當前上下文的 CSS 文件，不會阻塞關鍵路徑。
瀏覽器基本上能將未命中媒體查詢的 CSS 文件延遲下載。
<link rel="stylesheet" href="all.css" />
如果我們把全部的 CSS 代碼都放在一個文件中，請求的表現如下：
我們可以觀察到，這個單獨的 CSS 文件會以 最高 的優先級下載。
根據媒體查詢拆分成若干個 CSS 文件后：
<link rel="stylesheet" href="all.css" media="all" /> <link rel="stylesheet" href="small.css" media="(min-width: 20em)" /> <link rel="stylesheet" href="medium.css" media="(min-width: 64em)" /> <link rel="stylesheet" href="large.css" media="(min-width: 90em)" /> <link rel="stylesheet" href="extra-large.css" media="(min-width: 120em)" /> <link rel="stylesheet" href="print.css" media="print" />
瀏覽器會以不同的優先級下載 CSS 文件：
瀏覽器仍然會下載全部的 CSS 文件，但只有符合當前上下文的 CSS 文件會阻塞渲染。
@import為縮短渲染等待時間而努力的下一項任務非常簡單：避免在 CSS 文件中使用 @import
如果了解 @import 的原理，那應該清楚它的性能并不高，使用它會阻塞渲染更長時間。這是因為我們在關鍵路徑上創造了更多（隊列式）的網絡請求：
下載 HTML；
請求并下載依賴的 CSS；
（下載及解析完成后，本該是構造渲染樹，然而；）
CSS 依賴了其他的 CSS，繼續請求并下載 CSS 文件；
構造渲染樹。
以下是相關的案例：
<link rel="stylesheet" href="all.css" />
all.css 的內容：
@import url(imported.css);
最終，瀏覽器的請求瀑布圖呈現為：
關鍵路徑上的 CSS 文件并沒有并行下載。
通過將 @imports 請求的文件改為 <link rel="stylesheet" />：
<link rel="stylesheet" href="all.css" /> <link rel="stylesheet" href="imported.css" />
可以提高網絡性能：
關鍵路徑上的 CSS 文件是并行下載的。
注意，有一個特殊的情況值得討論。如果你沒有包含 @import 的 CSS 文件的修改權限，為了讓瀏覽器并行下載 CSS 文件，可以往 HTML 中補充相應的 <link rel="stylesheet" src="@import的地址" />。瀏覽器會并行下載相應的 CSS 文件且不會重復下載 @import 引用的文件。
@import本節的內容比較奇怪。各大瀏覽器的相關實現上似乎都有問題，我以前提交了相關的bugs（譯者注：簡單說，當頁面中存在：<style>@import url(xxx.url);</style>，瀏覽器不會并行下載，但加上引號后：<style>@import url("xxx.url");</style>，瀏覽器會并行下載）。
為了透徹地理解本節的內容，首先我們需要了解瀏覽器的預加載掃描器：各大瀏覽器都實現了一個名為預加載掃描器的輔助解析器。瀏覽器的核心解析器主要用于構建 DOM、CSSOM、運行 JavaScript 等。HTML 文檔中某些標簽與狀態會阻塞核心解析器，因而核心解析器的運行是斷斷續續的。而預加載掃描器可以跳到核心解析器尚未解析的部分，用以發現其他待引用的子資源（如 CSS、JS 文件、圖片等）。一旦發現此類子資源，預加載掃描器會開始下載它們，以便核心解析器在解析到對應內容時就能使用它們（，而不是直到那一刻才開始下載該資源）。預加載掃描器的出現，使網頁的加載性能提高了19%，這是一項了不起的成就，可以極大地優化用戶體驗。
作為開發者，需要警惕預加載掃描器背后隱藏的問題，這在后文會進行闡述。
在 HTML 中使用 @import，在以 WebKit 與 Blink 為內核的瀏覽器中，可能會觸發它們預加載掃描器的 bug，在 Firefox 與 IE/Edge 中，則表現低效。
@import 放在 JS 和 CSS 之前在 Firefox 與 IE/Edge 中，預加載掃描器不會并行下載 <script src=""> 和 <link rel="stylesheet" /> 后 @imports 引用的資源。
這意味著如下的 HTML：
<script src="app.js"></script> <style> @import url(app.css); </style>
會出現這樣的請求瀑布圖:
由于預加載掃描器失效，導致資源在 Firefox 中無法并行下載（IE/Edge 中有著同樣的問題）。
通過上圖，可以清晰地觀察到：直到 JavaScript 文件下載完成之后，@import 引用的 CSS 文件才開始下載。
不單 <script> 標簽會觸發此問題，<link> 標簽也會：
<link rel="stylesheet" href="style.css" /> <style> @import url(app.css); </style>
與 <script> 標簽一樣，子資源無法并行下載。
此問題最簡單的解決方案是調換 <script> 或 <link rel="stylesheet" /> 標簽與（包含 @import 的）<style> 標簽的位置。然而，當我們改變順序時，可能會對頁面造成影響。
最佳解決方案是完全不使用 @import，再往 HTML 文檔中加入另一個 <link rel="stylesheet" /> 取而代之：
<link rel="stylesheet" href="style.css" /> <link rel="stylesheet" href="app.css" />
修改后，瀏覽器表現更好：
瀏覽器并行下載資源，IE/Edge 表現相同。
@import 時，要用引號包裹 url。對于以 Blink 或 WebKit 為內核的瀏覽器而言，當 @import 引用的 url 未被引號包裹時，表現與 Firefox 和 IE/Edge 一致（無法并行下載）。這意味著上述兩個內核的預加載掃描器存在 bug。
因此，無需調整代碼的順序，只需要添加引號即可解決問題。但我還是建議使用另一個 <link rel="stylesheet" /> 取代 @import。
未添加引號時的代碼：
<link rel="stylesheet" href="style.css" /> <style> @import url(app.css); </style>
瀑布圖:
可以看到，缺失引號會破壞 Chrome 的預加載（Opera 與 Safari 表現也是如此。）
添加引號后的代碼：
<link rel="stylesheet" href="style.css" />
<style>
@import url("app.css");
</style>
添加引號后，Chrome、Opera 和 Safari 的預加載掃描器表現恢復正常，
這絕對是 WebKit 與 Blink 內核的一個 bug，是否添加引號不應成為影響預加載掃描器的因素。
感謝 Yoav 幫我追蹤這個問題。
現在這個 bug 現已在 Chromium 的待修復列表中。
<link rel="stylesheet" /> 之后在上一節中，我們了解到某些引用 CSS 文件路徑 的方法，會對其他資源的下載造成負面影響。在本節中，我們將探究為何稍有不慎，CSS 將延遲其他資源的下載。該問題主要出現在動態創建的 <script> 標簽中：
<script>
var script = document.createElement('script');
script.src = "analytics.js";
document.getElementsByTagName('head')[0].appendChild(script);
</script>所有瀏覽器都存在一個鮮為人知，但符合邏輯的現象，它會對性能造成很大的影響：
在瀏覽器下載完該 CSS 文件之前，不會執行下面的 JS
<link rel="stylesheet" href="slow-loading-stylesheet.css" />
<script>
console.log("I will not run until slow-loading-stylesheet.css is downloaded.");
</script>這是合理的。當 CSS 文件尚未下載完成時，HTML 文檔中任何同步的 JavaScript 代碼，均不會執行。考慮以下場景： <script> 中的代碼會訪問當前的頁面樣式，為確保結果正確，需要等待（ <script> 標簽前）所有 CSS 文件下載并解析完畢后再獲取，否則無法保證正確性。因此，在 CSSOM 構建完成之前，<script> 中的代碼不會執行。
根據這現象，CSS 文件的下載時間會對后續 <script> 的執行時間造成影響。下面的例子能較好地說明問題。
如果我們將一個 <link rel="stylesheet" /> 放在 <script> 之前，<script> 中動態創建新 <script> 的代碼只會在 CSS 文件下載完之后才會執行，這意味著 CSS 推遲了資源的下載與執行：
<link rel="stylesheet" href="app.css" />
<script>
var script = document.createElement('script');
script.src = "analytics.js";
document.getElementsByTagName('head')[0].appendChild(script);
</script>從下面的瀑布圖可以看到，JavaScript 文件在 CSSOM 構建完成之后才開始下載，完全失去了并行下載的優勢：
盡管預加載掃描器希望能預下載 analytics.js，但對 analytics.js 的引用并非一開始就存在于 HTML 的文檔之中，它是由 <link> 后面 <script> 的代碼動態創建的，在創建之前，它只是一些字符串，而不是預加載掃描器可識別的資源，無形中它被隱藏起來了。
為了更安全地加載腳本，第三方服務商經常提供這樣的代碼片段。然而，開發者通常不信任第三方的代碼，因而會把該片段放在頁面的最后，但這可能會導致不良的后果。事實上，Google Analytics （在文檔中）對此的建議是：
將代碼復制后，作為第一項粘貼到待追蹤頁面的 中。
綜上，我的建議是：
如果 <script> 中的代碼并不依賴 CSS，把它們放在樣式表之前。
調整一下代碼：
<script>
var script = document.createElement('script');
script.src = "analytics.js";
document.getElementsByTagName('head')[0].appendChild(script);
</script>
<link rel="stylesheet" href="app.css" />
交換位置之后，子資源可以并行下載，頁面的整體性能提高了兩倍以上。（譯者注：本節的內容只同意一半，<head> 中的代碼，確實是建議先放 <script>，再放 <link>，后文也會有相關的內容，但第三方代碼放在 <head> 中的第一項，取決于相關代碼的用途。如非必要，放在頁面末尾或空閑時下載及執行也未嘗不可）
這條建議遠比你想象中的有用。
上文討論了插入新 <script> 的代碼應放在 <link> 之前，那是否能推廣到其他的 CSS 與 JavaScript 呢？為了弄明白這個問題，先提出以下假設：
假設：
CSSOM 的構建會阻塞 CSS 后面同步 JS 的執行；
同步的 JS 會阻塞 DOM 的構建...
那如果 JS 并不依賴 CSSOM，以下那種情況會更快？
script 在前 style 在后;
style 在前 script 在后?
答案是：
如果 JS 文件沒有依賴 CSS，你應該將 JS 代碼放在樣式表之前。 既然沒有依賴，那就沒有任何理由阻塞 JavaScript 代碼的執行。
（盡管執行 JavaScript 代碼時會停止解析 DOM， 但預加載掃描器會提前下載之后的 CSS）
如果你一部分 JavaScript 需要依賴 CSS 而另一部分卻不用，最佳的實踐是將 JavaScript 分為兩部分，分別置于 CSS 的兩側：
<!-- 這部分 JavaScript 代碼下載完后會立即執行 --> <script src="i-need-to-block-dom-but-DONT-need-to-query-cssom.js"></script> <link rel="stylesheet" href="app.css" /> <!-- 這部分 JavaScript 代碼在 CSSOM 構建完成后才會執行 --> <script src="i-need-to-block-dom-but-DO-need-to-query-cssom.js"></script>
根據這種組織方式，我們的頁面會按最佳的方式下載與執行相關代碼。下面的截圖中，粉色代表 JS 的執行，但它們都比較“纖細”了，希望你能看得清楚。（第一欄的（下同））第一行是整個頁面的時間軸，留意該行粉色的部分，代表 JS 正在執行。第二行是首個 JS 文件的時間軸，可以看到下載完后并立即執行。第三行是 CSS 的時間軸，因而沒有任何 JS 執行。最后一行是第二個 JS 文件的時間軸，可以清晰地看到，直到 CSS 下載完成后才執行。
注意，你應該根據頁面的實際情況測試這種代碼組織方式，取決于 CSS 與 JavaScript 文件大小與 JavaScript 文件執行所需的時間，可能會出現不同的結果。記得多測試！（譯者注：根據實踐經驗，<head> 中的代碼組織基本可以按照這種方式，即 JS 在 CSS 之前，因為 <head> 中的 JS 代碼基本不依賴 CSS，唯一的反例是 JS 代碼體積非常大或執行時間很長。）
<link rel="stylesheet" /> 放在 <body> 中。最后一條優化策略比較新穎，它對頁面性能有很大幫助，并使頁面達到逐步渲染的效果，同時易于執行。
在 HTTP/1.1 中，我們習慣于將全部的 css 打成一個文件，如 app.css：
<html> <head> <link rel="stylesheet" href="app.css" /> </head> <body> <header class="site-header"> <nav class="site-nav">...</nav> </header> <main class="content"> <section class="content-primary"> <h2>...</h2> <div class="date-picker">...</div> </section> <aside class="content-secondary"> <div class="ads">...</div> </aside> </main> <footer class="site-footer"> </footer> </body>
然而，從三方面而言，渲染性能降低了：
每個頁面只用到 app.css 中的部分樣式： 用戶會下載多余的 CSS。
難以制定緩存策略： 例如，某個頁面使用的日期選擇器更改了背景顏色，重新生成 app.css 后，舊的 app.css 緩存將失效。
整個 app.css 在解析構建完 CSSOM 之前，頁面渲染被阻塞： 盡管當前頁面可能只用到了 17% 的 CSS代碼，但（瀏覽器）仍需等待其他 83% 的代碼下載并解析完后，才能開始渲染。
使用 HTTP/2，可以解決第一與第二點：
<html> <head> <link rel="stylesheet" href="core.css" /> <link rel="stylesheet" href="site-header.css" /> <link rel="stylesheet" href="site-nav.css" /> <link rel="stylesheet" href="content.css" /> <link rel="stylesheet" href="content-primary.css" /> <link rel="stylesheet" href="date-picker.css" /> <link rel="stylesheet" href="content-secondary.css" /> <link rel="stylesheet" href="ads.css" /> <link rel="stylesheet" href="site-footer.css" /> </head> <body> <header class="site-header"> <nav class="site-nav">...</nav> </header> <main class="content"> <section class="content-primary"> <h2>...</h2> <div class="date-picker">...</div> </section> <aside class="content-secondary"> <div class="ads">...</div> </aside> </main> <footer class="site-footer"> </footer> </body>
根據頁面的不同組件下載不同的 CSS，能有效地解決冗余問題。這減少了對關鍵路徑造成阻塞的 CSS 文件總大小。
同時，我們可以制定更有效的緩存策略，（當代碼產生變化之后，）只會影響對應文件的緩存，其他的文件保持不變。
但仍有解決的問題：下載并解析全部 CSS 文件之前，頁面的渲染仍然是阻塞的。頁面的渲染時間仍然取決于最慢的 CSS 文件下載與解析的時間。假設由于某種原因，頁腳的 CSS 下載需要很長時間，（即使頁頭的 CSSOM 已經構建完成，）瀏覽器也只能等待而無法渲染頁頭。
然而，這現象在 Chrome （v69）中得到緩解，Firefox 與 IE/Edge 也已經進行了相關的優化。<link rel="stylesheet" /> 只會阻塞后續內容，而不是整個頁面的渲染。這意味著我們可以用以下方式組織代碼：
<html> <head> <link rel="stylesheet" href="core.css" /> </head> <body> <link rel="stylesheet" href="site-header.css" /> <header class="site-header"> <link rel="stylesheet" href="site-nav.css" /> <nav class="site-nav">...</nav> </header> <link rel="stylesheet" href="content.css" /> <main class="content"> <link rel="stylesheet" href="content-primary.css" /> <section class="content-primary"> <h2>...</h2> <link rel="stylesheet" href="date-picker.css" /> <div class="date-picker">...</div> </section> <link rel="stylesheet" href="content-secondary.css" /> <aside class="content-secondary"> <link rel="stylesheet" href="ads.css" /> <div class="ads">...</div> </aside> </main> <link rel="stylesheet" href="site-footer.css" /> <footer class="site-footer"> </footer> </body>
這樣的結果是我們能逐步渲染頁面，當前面的 CSS 可用時，頁面將呈現對應的內容（，而不需等待全部 CSS 下載并解析完畢）。
I如果瀏覽器不支持這種特性，也不會損害頁面的性能。整個頁面將回退為原來的模式，只有在最慢的 CSS 下載并解析完成后，才能渲染頁面。
有關這種特性的更多細節，建議閱讀這篇文章。
本文內容比較 繁雜，成文后超出了本來的預期，嘗試總結了 CSS 加載相關的一系列的最佳實踐，值得仔細體會：
懶加載非關鍵 CSS：
優先加載關鍵 CSS，懶加載其他 CSS；
或根據媒體類型拆分 CSS 文件。
避免使用 @import：
在 HTML 文檔中應該避免；
在 CSS 文件之中更應避免；
以及警惕預加載掃描器的怪異行為。
關注 CSS 與 JavaScript 的順序：
將它放置于 CSS 之后。
將它放置于 CSS 之前；
在 CSS 文件后的 JavaScript 僅在 CSSOM 構建完成后才會執行；
如果你的 JavaScript 不依賴 CSS；
如果 JavaScript 依賴 CSS：
僅加載 DOM 依賴的 CSS：
這將提高初次渲染的速度使讓頁面逐步渲染。
感謝你能夠認真閱讀完這篇文章，希望小編分享的“CSS和網絡性能的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
