度量 Web性能的一個重要指標就是頁面內容實際顯示在屏幕上需要多久。這個指標有時候也叫 “渲染時間” 或者 “上屏時間”。現代瀏覽器在屏幕上渲染之前，至少需要兩樣東西：HTML和CSS。這意味着讓瀏覽器儘快下載HTML和全部CSS極其重要。
瀏覽器只有掌握了佈局頁面的全部CSS信息，才能給出最佳響應。 因爲只有這樣，他們才知道應該把頁面渲染成什麼樣，從而一次性地把頁面繪製到屏幕上，而非一邊加載新樣式一邊重新調整頁面
1、減少HTTP請求
在鏈接外部樣式表時，保證鏈接的文件數量最少至關重要，因爲每個文件都需要單獨發送一次HTTP請求。相應地，每次服務器請求文件，瀏覽器需要花一定的時間下載，然後還要花時間應用其中的樣式。另外，額外的HTTP請求也意味着瀏覽器會向服務器發送多餘的數據，比如cookie或請求首部。服務器也必須針對每個請求返回響應首部。服務器也必須針對每個請求返回響應首部。兩個文件要比一個包含相同CSS內容的文件在瀏覽器和服務器間傳遞的數據更多。
所以線上網頁最好把需要加載的CSS文件控制在 1 或 2 個。只能一個 link 元素加載CSS文件，然後在其中使用 @import，並不能把請求控制爲1，因爲這意味着先需要 1 個請求下載鏈接的文件，此外還要發送額外的請求取得所有導入的文件。因此，在線上網頁中儘量不要使用@import
2、壓縮和緩存內容
GZIP壓縮線上資源。CSS壓縮的比率很高，因爲它的很多屬性和值都是重複的。一般來說，CSS文件壓縮後會減少70%~80%。這樣顯然可以減少帶寬佔用，從而爲用戶節省時間，多數Web服務器都會在瀏覽器支持的情況下啓用自動壓縮線上資源。（當下主流的瀏覽器都是支持 Gzip 壓縮，包括 IE6、IE7、IE8、IE9、FireFox、Google Chrome、Opera 等。）
GZIP壓縮：全稱GNUzip，gzip壓縮程序是使用DEFLATE 算法---- LZ77 和霍夫曼編碼的組合，最早用於 UNIX 系統的文件壓縮。對純文本內容可壓縮到原大小的40%，圖片文件不推薦（svg除外）。（在Network —> Reponse —> Header 中找到 content-encoding：gzip ----表明使用了gzip壓縮）
Brotli壓縮：Google 在 2015 年 9 月推出了無損壓縮算法 Brotli。Brotli 通過變種的 LZ77 算法、Huffman 編碼以及二階文本建模等方式進行數據壓縮，與其他壓縮算法相比，它有着更高的壓縮效率。使用 Brotli 取代DEFLATE 來對文本壓縮通常可增加20%的壓縮密度。
國內使用Brotli壓縮網站有：知乎
國外使用Brotli壓縮網站有：google，facebook，bing
類似地讓Web服務器幫你設置一定的CSS緩存時間也很重要，理想情況下，瀏覽器應該只下載一次CSS文件，除非線上文件有變化。方法就是通過HTTP首部告訴瀏覽器，把文件緩存較長的一段時間，如果文件有修改，則通過文件名來 “清除緩存”。
3、不讓瀏覽器渲染阻塞 JavaScript
如果你在HTML文檔的 < head >元素中加入< script >元素，瀏覽器必須先把它鏈接的腳本下載下來，然後再向用戶顯示頁面內容。換句話說，這種情況下的 HTML 和 CSS 解析完全被下載以及執行腳本阻斷了，也就是多爲的 “渲染阻塞”
比較現代的做法是在 < head > 中使用< script > 標籤，但添加 async 和 dafer 屬性。給< script > 標籤加上 async 屬性，不阻塞HTML解析，但會在腳本加載完畢執行時阻斷HTML解析。給 < script >標籤添加上 defer 屬性，同樣會異步加載腳本，不同的是會在HTML解析完畢後再執行加載的腳本。
使用以上方法加載JavaScript，可以確保瀏覽器首先解析HTML 和 CSS，不受請求JavaScript文件的影響。但async 和 defer 屬性是HTML5中定義的，IE10和更早版本的IE並不支持或不完全支持它們。