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。

Etag / If-None-Match

優先級高於Last-Modified / If-Modified-Since

Etag：

服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器決定）。

If-None-Match：

再次請求服務器時，經過此字段通知服務器客戶段緩存數據的惟一標識。
服務器收到請求後發現有頭If-None-Match 則與被請求資源的惟一標識進行比對，

不一樣，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
相同，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。

總結

對於強制緩存，服務器通知瀏覽器一個緩存時間，在緩存時間內，下次請求，直接用緩存，不在時間內，執行比較緩存策略。

對於比較緩存，將緩存信息中的Etag和Last-Modified經過請求發送給服務器，由服務器校驗，返回304狀態碼時，瀏覽器直接使用緩存。
瀏覽器第一次請求：

瀏覽器再次請求時：

緩存內容摘自：www.cnblogs.com/chenqf/p/63…

就這樣吧！！！！！

---

+_+