提醒：本文最後更新於 1320 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

在連續寫了兩篇關於「HTTP/2 與 WEB 效能優化」的文章後，今天來寫這個系列的最後一篇。在正式開始之前，我們先來簡單回顧下之前兩篇文章：

「HTTP/2 與 WEB 效能優化（一）」的結論是：HTTP/2 的 Server Push 機制，可以讓重要的 JS、CSS 等資源儘快載入，從而不再需要 HTTP/1 中「將重要資源內聯在頁面頭部」的優化方案了。

「HTTP/2 與 WEB 效能優化（二）」的結論是：HTTP/2 支援了多路複用，HTTP 連線變得十分廉價，之前為了節省連線數所採用的類似於「資源合併、資源內聯」等優化手段不再需要了。多路複用可以在一個 TCP 連線上建立大量 HTTP 連線，也就不存在 HTTP 連線數限制了，HTTP/1 中常見的「靜態域名」優化策略不但用不上了，還會帶來負面影響，需要去掉。另外，HTTP/2 的頭部壓縮功能也能大幅減少 HTTP 協議頭部帶來的開銷。

但 HTTP/2 並不是萬能的，並不是說用了 HTTP/2 就不再需要效能優化了。我在本系統第二篇文章末尾寫到：

據官方預測，HTTP/1 至少還需要 10 年才能徹底退出歷史舞臺，另外儘管 HTTP/2 協議允許脫離 TLS 部署，但 Chrome 和 Firefox 都表示不支援非 TLS 的 HTTP/2，之後很可能一個網站會同時提供 HTTP/1.1、HTTP/1.1 over TLS、HTTP/2 over TLS 三種服務。如何在每種情況下，都能給使用者提供最好的體驗，需要更加深入的優化研究和更加精細的優化策略。

實際上，除了前兩篇文章中提到的這些需要為 HTTP/2 做出調整的優化策略之外，其餘大部分 HTTP/1 時期的優化策略依然有效。HTTP/1 的 WPO 並不是什麼新鮮話題，大家早就熟門熟路了，本文只打算列舉其中幾個：

啟用壓縮

壓縮的目的是讓傳輸的資料變得更小。我們的線上程式碼（JS、CSS 和 HTML）都會做壓縮，圖片也會做壓縮（PNGOUT、Pngcrush、JpegOptim、Gifsicle 等）。對於文字檔案，在服務端傳送響應之前進行 GZip 壓縮也很重要，通常壓縮後的文字大小會減小到原來的 1/4 - 1/3。對程式碼進行內容壓縮已經有成熟的工具和標準流程了，而服務端的 GZip 更是標配，所以「壓縮」是一項收益投入比很高的優化手段。

使用 HTTP 快取

任何一個 WEB 專案，要提高效能，各個環節的快取必不可少。利用好 HTTP 協議的快取機制，可以大幅減少傳輸資料，減少請求，這又是一項收益投入比超高的優化手段。這裡把之前我寫的 HTTP/1.1 快取機制介紹翻出來：

首先，服務端可以通過響應頭裡的 Last-Modified（最後修改時間） 或者 ETag（內容特徵） 標記實體。瀏覽器會存下這些標記，並在下次請求時帶上 If-Modified-Since: 上次 Last-Modified 的內容 或 If-None-Match: 上次 ETag 的內容，詢問服務端資源是否過期。如果服務端發現並沒有過期，直接返回一個狀態碼為 304、正文為空的響應，告知瀏覽器使用本地快取；如果資源有更新，服務端返回狀態碼 200、新的 Last-Modified、Etag 和正文。這個過程被稱之為 HTTP 的協商快取，通常也叫做弱快取。

可以看到協商快取並不會節省連線數，但是在快取生效時，會大幅減小傳輸內容（304 響應沒有正文，一般只有幾百位元組）。另外為什麼有兩個響應頭都可以用來實現協商快取呢？這是因為一開始用的 Last-Modified 有兩個問題：1）只能精確到秒，1 秒內的多次變化反映不出來；2）在輪詢的負載均衡演算法中，如果各機器讀到的檔案修改時間不一致，有快取無故失效和快取不更新的風險。HTTP/1.1 並沒有規定 ETag 的生成規則，而一般實現者都是對資源內容做摘要，能解決前面兩個問題。

另外一種快取機制是服務端通過響應頭告訴瀏覽器，在什麼時間之前（Expires）或在多長時間之內（Cache-Control: Max-age=xxx），不要再請求伺服器了。這個機制我們通常稱之為 HTTP 的強快取。

一旦資源命中強快取規則後，再次訪問完全沒有 HTTP 請求（Chrome 開發者工具的 Network 面板依然會顯示請求，但是會註明 from cache；Firefox 的 firebug 也類似，會註明 BFCache），這會大幅提升效能。所以我們一般會對 CSS、JS、圖片等資源使用強快取，而入口檔案（HTML）一般使用協商快取或不快取，這樣可以通過修改入口檔案中對強快取資源的引入 URL 來達到即時更新的目的。

這裡也解釋下為什麼有了 Expire，還要有 Cache-Control。也有兩個原因：1）Cache-Control 功能更強大，對快取的控制能力更強；2）Cache-Control 採用的 max-age 是相對時間，不受服務端 / 客戶端時間不對的影響。

另外關於瀏覽器的重新整理（F5 / cmd + r）和強刷（Ctrl + F5 / shift + cmd +r）：普通重新整理會使用協商快取，忽略強快取；強刷會忽略瀏覽器所有快取（並且請求頭會攜帶 Cache-Control:no-cache 和 Pragma:no-cache，用來通知所有中間節點忽略快取）。只有從位址列或收藏夾輸入網址、點選連結等情況下，瀏覽器才會使用強快取。

減少 DNS 查詢

我們知道，建立 TCP 連線需要知道目標 IP，而絕大部分時候給瀏覽器的是域名。瀏覽器需要先將域名解析為 IP，這個過程就是 DNS 查詢，一般需要幾毫秒到幾百毫秒，移動環境下會更慢。DNS 解析完成之前，請求會被 Block。瀏覽器一般都會快取 DNS 查詢結果，頁面使用的域名（包括子域名）越少，花費在 DNS 查詢上的開銷就越小。另外，合理使用瀏覽器的 DNS Prefetching 技術，也是很好的做法。

減少重定向

無論是通過服務端響應頭產生的重定向，還是通過 <meta> 或者 JS 產生的重定向，都可能引入新的 DNS 查詢、新的 TCP 連線以及新的 HTTP 請求，所以減少重定向也很重要。瀏覽器基本都會快取通過 301 Moved Permanently 指定的跳轉，所以對於永久性跳轉，可以考慮使用狀態碼 301。對於啟用了 HTTPS 的網站，配置 HSTS 策略，也可以減少從 HTTP 到 HTTPS 的重定向。

WEB 效能優化是一個系統工程，不可能在這一篇文章裡寫完，我決定先就寫到這兒。最後，推薦一個 Chrome 擴充套件：HTTP/2 and SPDY indicator，它可以在位址列顯示當前網站是否啟用了 SPDY 或者 HTTP/2，點選圖示可以直接開啟 Chrome 的 HTTP/2 的除錯介面，十分方便。

--EOF--

發表於 2015-06-01 00:20:11 ，並被新增「 HTTP2 、 效能優化 」標籤 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 1320 天前，文中所描述的資訊可能已發生改變，請謹慎使用。