前端HTTP優化

前端部署時，需將 html/css/js/img 等靜態資源發佈至服務器/CDNs，常規優化點以下：
基於 express server 的例子

1 合併、壓縮、混淆

文件合併，減小 http 請求次數
壓縮、混淆，減小靜態資源大小

實現上，可以使用 webpack 配合系列插件，打包過程當中可壓縮源代碼（去空格、換行、註釋，JS混淆代碼等等），webpack 配置複雜，不過多贅述

---

2 http gzip 壓縮

減小 http 傳輸過程當中文件大小

2.1 壓縮先後對比

2.2 HTTP 請求頭 Accept-Encoding

HTTP 請求頭 Accept-Encoding 會將客戶端可以理解的內容編碼方式——一般是某種壓縮算法——進行通知。經過內容協商的方式，服務端會選擇一個客戶端提議的方式，使用並在響應報文首部 Content-Encoding 中通知客戶端該選擇。

2.3 HTTP 響應頭 Content-Encoding

Content-Encoding 是一個實體消息首部，用於對特定媒體類型的數據進行壓縮。當這個首部出現的時候，它的值表示消息主體進行了何種方式的內容編碼轉換。這個消息首部用來告知客戶端應該怎樣解碼才能獲取在 Content-Type 中標示的媒體類型內容。

---

3 Not Modified 304

減小傳輸內容提高性能。
客戶端有緩衝的文檔併發出了一個條件性的請求。服務器告訴客戶端，原來緩衝的文檔還能夠繼續使用，涉及如下兩種 HTTP Header。

3.1 Last-modified / If-Modified-Since

1）瀏覽器第一次請求某個URL時，服務器端的返回狀態會是200，內容是你請求的資源，同時有一個Last-Modified的屬性標記此文件在服務期端最後被修改的時間

2）客戶端第二次請求此URL時，HTTP 協議的規定，瀏覽器會向服務器傳送 If-Modified-Since 報頭，詢問該時間以後文件是否有被修改過。

3）若是服務器端的資源沒有變化，則自動返回 HTTP 304 Not Modified 狀態碼，內容爲空，這樣就節省了傳輸數據量。當服務器端代碼發生改變或者重啓服務器時，則從新發出資源，返回和第一次請求時相似。從而保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端可以獲得最新的資源。

3.2 Etag / If-None-Match

Etag 相似於 hash 值，用來判斷請求的文件是否被修改，其 http 緩存步驟與 Last-Modified 相同。

HTTP 協議規格說明定義ETag爲「被請求變量的實體值」。 另外一種說法是，ETag是一個能夠與Web資源關聯的記號（token）。

3.3 Etag 主要爲了解決 Last-Modified 沒法解決的一些問題

1）一些文件也許會週期性的更改，但內容並未改變（僅僅改變的修改時間），這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新 GET
2）某些文件修改很是頻繁，好比在秒如下的時間內進行修改（比方說1s內修改了N次），If-Modified-Since能檢查到的粒度是s級的，這種修改沒法判斷(或者說UNIX記錄MTIME只能精確到秒)
3）某些服務器不能精確的獲得文件的最後修改時間

---

4 瀏覽器緩存

Last-Modified 和 Etag 標識資源變化狀況，服務器返回 304 Not Modified 下降網絡傳輸大小，提高性能。可是對於如圖片、react/vue這類庫資源、通用css這些不常常變化的靜態資源，應利用瀏覽器緩存功能，連304此次請求都優化掉。

4.1 Pragma

HTTP1.0 標準，代表禁用緩存，因爲 Pragma 在 HTTP 響應中的行爲沒有確切規範，因此不能可靠替代 HTTP/1.1 中通用首部 Cache-Control。看了下騰訊視頻、京東商城等頁面，用在html的請求頭中。

4.2 Expires

HTTP1.0 標準，代表過時時間，注意此處的時間都是指的是服務器的時間。（無效的日期，好比 0, 表明着過去的日期，即該資源已通過期）

**存在問題**：客戶端與服務器時間不一致，可能致使緩存失效。

4.3 Cache-Control

HTTP 1.1 標準，是 expires 的補充，使用的是相對時間的概念。
Cache-Control 屬性以下：

1）max-age: 設置緩存的最大的有效時間，單位爲秒（s）。max-age會覆蓋掉Expires
2）s-maxage: 只用於共享緩存，好比CDN緩存（s -> share）。與 max-age 的區別是：max-age 用於普通緩存，而 s-maxage 用於代理緩存。若是存在 s-maxage，則會覆蓋 max-age 和 Expires
3）public：響應會被緩存，而且在多用戶間共享。默認是public。
3）private: 響應只做爲私有的緩存，不能在用戶間共享。若是要求HTTP認證，響應會自動設置爲private。
4）no-cache: 指定不緩存響應，代表資源不進行緩存。可是設置了no-cache以後並不表明瀏覽器不緩存，而是在緩存前要向服務器確認資源是否被更改。所以有的時候只設置no-cache防止緩存仍是不夠保險，還能夠加上private指令，將過時時間設爲過去的時間。
5）no-store: 絕對禁止緩存。
6）must-revalidate: 若是頁面過時，則去服務器進行獲取。

更多屬性請參考 MDN：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control

使用瀏覽器緩存後，chrome 中網絡請求以下：
1）from memery cache 從內存中讀取
2）from disk cache 從瀏覽器緩存中讀取

Chorme官網描述

---

5 HTTP2

這篇文字介紹的很全面
協議遞進順序 HTTP1.0 -> HTTP1.1 -> spdy（谷歌） -> HTTP2

1） 多路複用 + 二進制分幀：使用 HTTP1.1，瀏覽器在同一時間，針對同一域名下的請求有必定的數量限制，超過限制數目的請求會被阻塞（不一樣瀏覽器不一樣），HTTP2 引入二進制數據幀和流的概念，而非 HTTP1.1 的文本形式，實如今同一 TCP 鏈接下的多併發請求（固然 HTTP1.1 優化的 keep-alive 也不須要了）
2） 頭部壓縮：HTTP1.1 Header 中有許多無心義的重複的頭部，HTTP2 使用 HPACK 算法進行頭部壓縮
3） 服務端推送：例如，在瀏覽器請求 html 時，服務端預測性的將 js、css 等文件推送回來，但在實際應用中有許多問題須要解決