HTTP前端效能優化(壓縮與快取)

YXi發表於2019-09-11

HTTP前端優化快取

壓縮

適合壓縮的檔案型別：

並非所有的檔案需要壓縮。
比如，已經壓縮的檔案諸如JPEG、GIF、PNG、電影和打包內容等不需要HTTP壓縮過濾技術。對它們再次壓縮將無法得到顯著減小檔案體積的效果。

同時，網站還有大量的文字內容諸如HTML、XML、CSS和RSS等，他們都需要進行壓縮。
壓縮的程式取決於檔案的型別。

壓縮方式選擇

gzip是GUNzip的縮寫，使用無失真壓縮，壓縮效果最佳，已經成為使用最為普遍、支援的瀏覽器最多的資料壓縮格式。
目前國內的大型網站都使用的是這種方式（例如：淘寶、京東、騰訊等...）

壓縮過程

所有的現代瀏覽器以及伺服器都支援壓縮技術，唯一需要協商的是所採用的壓縮演算法。

為了選擇採用的壓縮演算法，瀏覽器和伺服器之間會使用主動協商機制。

瀏覽器傳送 Accept-Encoding 首部，（其中包含它所支援的壓縮演算法，以及各自的優先順序）
伺服器則從中選擇一種，使用該演算法對響應的訊息主體進行壓縮，並且傳送 Content-Encoding 首部來告知瀏覽器它選擇了哪一種演算法。

由於該內容協商過程是基於編碼型別來選擇資源的展現形式的，在響應中， Vary(渲染引擎) 首部中至少要包含 Accept-Encoding ；這樣的話，快取伺服器就可以對資源的不同展現形式進行快取。

如下圖：

也就是：

客戶端（HTTP請求頭）-->accept-encoding: gzip, deflate, sdch, br
伺服器（HTTP響應頭）-->content-encoding:gzip

示例：

gzip(filePath, req, res, statObj) {
let encoding = req.headers["accept-encoding"];

if (encoding) {
	  if (encoding.match(/gzip/)) {
			res.setHeader("Content-Encoding", "gzip");
			return _zlib.default.createGzip();
	  } else if (encoding.match(/deflate/)) {
			res.setHeader("Content-Encoding", "deflate");
			return _zlib.default.createDeflate();
	  }
	  return false;
}
複製程式碼

由於壓縮技術可以帶來很大的效能提升，建議對除了已經經過壓縮的檔案如圖片、音訊和視訊檔案之外的其他型別的檔案均進行應用。

壓縮的優缺點

優點：減少HTTP響應時間，提升傳輸效率。
壓縮過程佔用伺服器額外的CPU週期，客戶端也要對壓縮檔案進行解壓縮，這也需要佔用部分時間。

補充

請求頭：

user-agent：不同裝置自動帶上這個頭，判斷什麼樣的裝置，重定向到相同的專案

響應頭：

Content-Type：給瀏覽器內容的型別
Location：重定向到某個地方

快取

為方便理解，我們認為瀏覽器存在一個快取資料庫,用於儲存快取資訊。

在客戶端第一次請求資料時，此時快取資料庫中沒有對應的快取資料，需要請求伺服器，伺服器返回後，將資料儲存至快取資料庫中。

HTTP快取有多種規則，根據是否需要重新向伺服器發起請求來分類
將其分為兩大類 (強制快取，對比快取)
在詳細介紹這兩種規則之前，先通過時序圖的方式，讓大家對這兩種規則有個簡單瞭解。

已存在快取資料時，僅基於強制快取，請求資料的流程如下

已存在快取資料時，僅基於對比快取，請求資料的流程如下

我們可以看到兩類快取規則的不同:

強制快取如果生效，不需要再和伺服器發生互動
而對比快取不管是否生效，都需要與服務端發生互動。

兩類快取規則可以同時存在，強制快取優先順序高於對比快取，也就是說，當執行強制快取的規則時，如果快取生效，直接使用快取，不再執行對比快取規則。

強制快取

從上文我們得知，強制快取，在快取資料未失效的情況下，可以直接使用快取資料，那麼瀏覽器是如何判斷快取資料是否失效呢？
我們知道，在沒有快取資料的時候，瀏覽器向伺服器請求資料時，伺服器會將資料和快取規則一併返回，快取規則資訊包含在響應header中。

對於強制快取來說，響應header中會有兩個欄位用來標明失效規則 (Expires/Cache-Control)

呼叫開發者工具，可以很明顯的看到對於強制快取生效時，網路請求的情況

Expires

Expires的值為服務端返回的到期時間，即下一次請求時，請求時間小於服務端返回的到期時間，直接使用快取資料。(不過Expires 是HTTP 1.0的東西，現在預設瀏覽器均預設使用HTTP 1.1，所以它的作用基本忽略。)

另一個問題是，到期時間是由服務端生成的，但是客戶端時間可能跟服務端時間有誤差，這就會導致快取命中的誤差。(所以HTTP 1.1 的版本，使用Cache-Control替代.)

Cache-Control

Cache-Control 是最重要的規則。常見的取值有private、public、no-cache、max-age，no-store，預設為private。

private：客戶端可以快取
public：客戶端和代理伺服器都可快取
max-age=xxx：快取的內容將在 xxx 秒後失效
no-cache：需要使用對比快取來驗證快取資料
no-store：所有內容都不會快取，強制快取，對比快取都不會觸發（對於前端開發來說，快取越多越好）

示例：

圖中Cache-Control僅指定了max-age，所以預設為private，快取時間為31536000秒（365天）
也就是說，在365天內再次請求這條資料，都會直接獲取快取資料庫中的資料，直接使用。

對比快取

對比快取，顧名思義，需要進行比較判斷是否可以使用快取。

瀏覽器第一次請求資料時，伺服器會將快取標識與資料一起返回給客戶端，客戶端將二者備份至快取資料庫中。
再次請求資料時，客戶端將備份的快取標識傳送給伺服器，伺服器根據快取標識進行判斷，判斷成功後，返回304狀態碼，通知客戶端比較成功，可以使用快取資料。

第一次訪問：

再次訪問：

通過兩圖的對比，我們可以很清楚的發現，在對比快取生效時，狀態碼為304，並且報文大小和請求時間大大減少。
原因是，服務端在進行標識比較後，只返回header部分，通過狀態碼通知客戶端使用快取，不再需要將報文主體部分返回給客戶端。

對於對比快取來說，快取標識的傳遞是我們著重需要理解的，它在請求header和響應header間進行傳遞，

一共分為兩種標識傳遞，接下來，我們分開介紹：

Last-Modified / If-Modified-Since

Last-Modified：

伺服器在響應請求時，告訴瀏覽器資源的最後修改時間。

If-Modified-Since：

再次請求伺服器時，通過此欄位通知伺服器上次請求時，伺服器返回的資源最後修改時間。
伺服器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。
若資源的最後修改時間大於If-Modified-Since，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
若資源的最後修改時間小於或等於If-Modified-Since，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所儲存的cache。