在連續(xù)寫了兩篇關(guān)于「HTTP/2 與 WEB 性能優(yōu)化」的文章后，今天來寫這個(gè)系列的***一篇。在正式開始之前，我們先來簡單回顧下之前兩篇文章：

「HTTP/2 與 WEB 性能優(yōu)化(一)」的結(jié)論是：HTTP/2 的 Server Push 機(jī)制，可以讓重要的 JS、CSS 等資源盡快加載，從而不再需要 HTTP/1 中「將重要資源內(nèi)聯(lián)在頁面頭部」的優(yōu)化方案了。

「HTTP/2 與 WEB 性能優(yōu)化(二)」的結(jié)論是：HTTP/2 支持了多路復(fù)用，HTTP 連接變得十分廉價(jià)，之前為了節(jié)省連接數(shù)所采用的類似于「資源合并、資源內(nèi)聯(lián)」等優(yōu)化手段不再需要了。多路復(fù)用可以在一個(gè) TCP 連接上建立大量 HTTP 連接，也就不存在 HTTP 連接數(shù)限制了，HTTP/1 中常見的「靜態(tài)域名」優(yōu)化策略不但用不上了，還會帶來負(fù)面影響，需要去掉。另外，HTTP/2 的頭部壓縮功能也能大幅減少 HTTP 協(xié)議頭部帶來的開銷。

但 HTTP/2 并不是***的，并不是說用了 HTTP/2 就不再需要性能優(yōu)化了。我在本系統(tǒng)第二篇文章末尾寫到：

據(jù)官方預(yù)測，HTTP/1 至少還需要 10 年才能徹底退出歷史舞臺，另外盡管 HTTP/2 協(xié)議允許脫離 TSL 部署，但 Chrome 和 Firefox 都表示不支持非 TLS 的 HTTP/2，之后很可能一個(gè)網(wǎng)站會同時(shí)提供 HTTP/1.1、HTTP/1.1 over TLS、HTTP/2 over TLS 三種服務(wù)。如何在每種情況下，都能給用戶提供***的體驗(yàn)，需要更加深入的優(yōu)化研究和更加精細(xì)的優(yōu)化策略。

實(shí)際上，除了前兩篇文章中提到的這些需要為 HTTP/2 做出調(diào)整的優(yōu)化策略之外，其余大部分 HTTP/1 時(shí)期的優(yōu)化策略依然有效。HTTP/1 的 WPO 并不是什么新鮮話題，大家早就熟門熟路了，本文只打算列舉其中幾個(gè)：

啟用壓縮

壓縮的目的是讓傳輸?shù)臄?shù)據(jù)變得更小。我們的線上代碼(JS、CSS 和 HTML)都會做壓縮，圖片也會做壓縮(PNGOUT、Pngcrush、JpegOptim、Gifsicle 等)。對于文本文件，在服務(wù)端發(fā)送響應(yīng)之前進(jìn)行 GZip 壓縮也很重要，通常壓縮后的文本大小會減小到原來的 1/4 - 1/3。對代碼進(jìn)行內(nèi)容壓縮已經(jīng)有成熟的工具和標(biāo)準(zhǔn)流程了，而服務(wù)端的 GZip 更是標(biāo)配，所以「壓縮」是一項(xiàng)收益投入比很高的優(yōu)化手段。

使用 HTTP 緩存

任何一個(gè) WEB 項(xiàng)目，要提高性能，各個(gè)環(huán)節(jié)的緩存必不可少。利用好 HTTP 協(xié)議的緩存機(jī)制，可以大幅減少傳輸數(shù)據(jù)，減少請求，這又是一項(xiàng)收益投入比超高的優(yōu)化手段。這里把之前我寫的 HTTP/1.1 緩存機(jī)制介紹翻出來：

首先，服務(wù)端可以通過響應(yīng)頭里的 Last-Modified(***修改時(shí)間) 或者 ETag(內(nèi)容特征) 標(biāo)記實(shí)體。瀏覽器會存下這些標(biāo)記，并在下次請求時(shí)帶上 If-Modified-Since: 上次 Last-Modified 的內(nèi)容 或 If-None-Match: 上次 ETag 的內(nèi)容，詢問服務(wù)端資源是否過期。如果服務(wù)端發(fā)現(xiàn)并沒有過期，直接返回一個(gè)狀態(tài)碼為 304、正文為空的響應(yīng)，告知瀏覽器使用本地緩存;如果資源有更新，服務(wù)端返回狀態(tài)碼 200、新的 Last-Modified、Etag 和正文。這個(gè)過程被稱之為 HTTP 的協(xié)商緩存，通常也叫做弱緩存。

可以看到協(xié)商緩存并不會節(jié)省連接數(shù)，但是在緩存生效時(shí)，會大幅減小傳輸內(nèi)容(304 響應(yīng)沒有正文，一般只有幾百字節(jié))。另外為什么有兩個(gè)響應(yīng)頭都可以用來實(shí)現(xiàn)協(xié)商緩存呢?這是因?yàn)橐婚_始用的 Last-Modified 有兩個(gè)問題：1)只能精確到秒，1 秒內(nèi)的多次變化反映不出來;2)在輪詢的負(fù)載均衡算法中，如果各機(jī)器讀到的文件修改時(shí)間不一致，有緩存無故失效和緩存不更新的風(fēng)險(xiǎn)。HTTP/1.1 并沒有規(guī)定 ETag 的生成規(guī)則，而一般實(shí)現(xiàn)者都是對資源內(nèi)容做摘要，能解決前面兩個(gè)問題。

另外一種緩存機(jī)制是服務(wù)端通過響應(yīng)頭告訴瀏覽器，在什么時(shí)間之前(Expires)或在多長時(shí)間之內(nèi)(Cache-Control: Max-age=xxx)，不要再請求服務(wù)器了。這個(gè)機(jī)制我們通常稱之為 HTTP 的強(qiáng)緩存。

一旦資源***強(qiáng)緩存規(guī)則后，再次訪問完全沒有 HTTP 請求(Chrome 開發(fā)者工具的 Network 面板依然會顯示請求，但是會注明 from cache;Firefox 的 firebug 也類似，會注明 BFCache)，這會大幅提升性能。所以我們一般會對 CSS、JS、圖片等資源使用強(qiáng)緩存，而入口文件(HTML)一般使用協(xié)商緩存或不緩存，這樣可以通過修改入口文件中對強(qiáng)緩存資源的引入 URL 來達(dá)到即時(shí)更新的目的。

這里也解釋下為什么有了 Expire，還要有 Cache-Control。也有兩個(gè)原因：1)Cache-Control 功能更強(qiáng)大，對緩存的控制能力更強(qiáng);2)Cache-Control 采用的 max-age 是相對時(shí)間，不受服務(wù)端 / 客戶端時(shí)間不對的影響。

另外關(guān)于瀏覽器的刷新(F5 / cmd + r)和強(qiáng)刷(Ctrl + F5 / shift + cmd +r)：普通刷新會使用協(xié)商緩存，忽略強(qiáng)緩存;強(qiáng)刷會忽略瀏覽器所有緩存(并且請求頭會攜帶 Cache-Control:no-cache 和 Pragma:no-cache，用來通知所有中間節(jié)點(diǎn)忽略緩存)。只有從地址欄或收藏夾輸入網(wǎng)址、點(diǎn)擊鏈接等情況下，瀏覽器才會使用強(qiáng)緩存。

減少 DNS 查詢

我們知道，建立 TCP 連接需要知道目標(biāo) IP，而絕大部分時(shí)候給瀏覽器的是域名。瀏覽器需要先將域名解析為 IP，這個(gè)過程就是 DNS 查詢，一般需要幾毫秒到幾百毫秒，移動環(huán)境下會更慢。DNS 解析完成之前，請求會被 Block。瀏覽器一般都會緩存 DNS 查詢結(jié)果，頁面使用的域名(包括子域名)越少，花費(fèi)在 DNS 查詢上的開銷就越小。另外，合理使用瀏覽器的 DNS Prefetching 技術(shù)，也是很好的做法。

減少重定向

無論是通過服務(wù)端響應(yīng)頭產(chǎn)生的重定向，還是通過 或者 JS 產(chǎn)生的重定向，都可能引入新的 DNS 查詢、新的 TCP 連接以及新的 HTTP 請求，所以減少重定向也很重要。瀏覽器基本都會緩存通過 301 Moved Permanently 指定的跳轉(zhuǎn)，所以對于***性跳轉(zhuǎn)，可以考慮使用狀態(tài)碼301。對于啟用了 HTTPS 的網(wǎng)站，配置 HSTS 策略，也可以減少從 HTTP 到 HTTPS 的重定向。

WEB 性能優(yōu)化是一個(gè)系統(tǒng)工程，不可能在這一篇文章里寫完，我決定先就寫到這兒。***，推薦一個(gè) Chrome 擴(kuò)展：HTTP/2 and SPDY indicator，它可以在地址欄顯示當(dāng)前網(wǎng)站是否啟用了 SPDY 或者 HTTP/2，點(diǎn)擊圖標(biāo)可以直接打開 Chrome 的 HTTP/2 的調(diào)試界面，十分方便。