Web性能優化與HTTP/2
如今，互聯網上的內容越來越豐富，過去幾年時間，一個頁面產生請求和整個大小都一直增長，這個趨勢還會一直保持，對頁面性能優化也要馬不停蹄。
一個頁面，會經歷過加載資源，執行腳本，渲染界面的過程。我們知道，100ms對于計算機來說，可以干很多事情了，但是對于網絡請求，可能一次RTT就沒了。因此，頁面加載對于Web性能是重中之重。
加載的快慢可以總結成受兩個因素影響：阻塞與延遲。
1、阻塞。瀏覽器在解析到腳本時，會阻塞頁面，等到腳本下載執行完才繼續解析文檔。此外，瀏覽器還會限制同域下的并行請求數，超過這個限制后的請求就會被阻塞住。
2、延遲。網絡請求都不可避免會有延遲，網頁上的延遲有兩種，一是DNS查詢，二是TCP連接。
克服這些缺點，我們有一些約定俗成的方案：
- 靜態資源要支持304，開啟HTTP緩存控制
- 開啟gzip，壓縮HTTP body
- css放在html的head里，js在body底部
- 合并請求
- 使用雪碧圖
- 域名分區（突破并行限制，也避免傳輸過多cookie）
- 使用cdn
這些方案基本都能立竿見影。但是，對于追求極致（KPI）的我們，這些還是遠遠不夠的。我們從頁面開始加載時說起。
重定向意味著要重新發起請求，當然我們沒事也不會亂跳。這里要說的一種重定向是，訪問HTTP站點，跳轉到HTTPS。
避免這種跳轉，我們可以用HSTS策略，就是告訴瀏覽器，以后訪問我這個站點，必須用HTTPS協議來訪問，讓瀏覽器幫忙做轉換，而不是請求到了 服務器后，才知道要轉換。只需要在響應頭部加上 Strict-Transport-Security: max-age=31536000 即可。
預加載DNS查詢需要個RTT時間，在瀏覽器級別，系統級別都會有層DNS緩存，之前解析過的可以直接從本機緩存獲取，以減少延遲。
Web標準提供了一種DNS預解析技術，因為服務器是知道頁面即將會發生哪些請求的，那我們可以在頁面頂部，插入 <link rel="dns-prefetch" href="http://host/">，讓瀏覽器先解析一下這個域名。那么，后續掃到同域的請求，就可以直接從DNS緩存獲取了。
此外，Web標準也提供prefetch，prerender的預加載技術。prefectch會在瀏覽器空閑的時候，向所提供的鏈接發起請求， 而prerender不僅會請求，還會幫你在后臺渲染頁面。如果在一個頁面中，你知道用戶有很大概率去點某個鏈接，可以嘗試把這個鏈接加到 prefetch或prerender，那么用戶就會秒開這個頁面了。
使用TCP、TLS最佳實踐HTTP請求要經過建立TCP連接這一步，而TCP為了可靠傳輸，建立連接需要三次握手。如果網站又接入了HTTPS，那還要額外多兩次RTT時 間以建立安全通道，這樣耗費了很多時間。HTTP是建立在TCP、TLS之上，那么TCP的最佳實踐，SSL的優化都是適用于HTTP的優化。
比如TCP慢啟動過程非常影響性能的，我們可以把初始窗口調大，讓慢啟動更快。對于TLS可用緩存session_ticket之類的優化可以減少一次RTT。
內聯對于一些簡單的頁面，CSS樣式和JavaScript腳本甚至圖片，可以不必使用外聯的方式引入，直接把子資源內嵌到HTML里，圖片可以用 base64編碼內嵌，這相當于請求頁面時，服務器順便把子資源給一共推送過去了。傳輸的內容都一樣，但減少好多請求了，自然節省不少時間。
不過這樣做的缺點是瀏覽器無法緩存這些子資源，這種做法只能降低首次加載時間，所以需要看取舍了。可能比較適用于一次性的頁面，類似活動之類的。
手動管理緩存為了代碼架構清晰，便于維護，我們都會用模塊化的方式去編碼，每個模塊一個文件，這樣帶來的問題是一個頁面需要很多文件，要很多請求，這對頁面性 能是不利的。合并是解決這個問題的好方法，但又因為HTTP緩存機制是基于URL的，只要某個模塊一改動，整個合并資源都要重新下載。
在對性能要求較高，比如在移動設備環境上，我們可以利用HTML5中的localStorage特性，來實現手動控制緩存。大概的思路是，在定義 模塊時，同時將模塊的代碼和版本號分別儲存到localStorage，在下一次打算請求模塊之前，我們先判斷模塊的最新版本是不是在 localStorage中，將不存在的模塊組合在一起，請求動態合并的資源。
不過，這種方案可能會引發安全問題。假如同域下的其他頁面被XSS攻擊，壞人就可以篡改localStorage的內容，可能導致原來的頁面代碼 被植入惡意程序。解決的方法是，在執行模塊之前，算一下代碼摘要，對比下服務器給的該模塊的摘要，再決定是否使用。也可以使用SRI策略，由瀏覽器幫你做 校驗。
HTTP持久連接HTTP持久連接可以重用已建立的TCP連接，減少三次握手的RTT延遲。瀏覽器在請求時帶上 connection: keep-alive 的頭部，服務器收到后就要發送完響應后保持連接一段時間，瀏覽器在下一次對該服務器的請求時，就可以直接拿來用。
以往，瀏覽器判斷響應數據是否接收完畢，是看連接是否關閉。在使用持久連接后，就不能這樣了，這就要求服務器對持久連接的響應頭部一定要返回 content-length標識body的長度，供瀏覽器判斷界限。有時，content-length的方法并不是太準確，也可以使用 Transfer-Encoding: chunked 頭部發送一串一串的數據，最后由長度為0的chunked標識結束。
HTTP管線化可以克服同域并行請求限制帶來的阻塞，它是建立在持久連接之上，是把所有請求一并發給服務器，但是服務器需要按照順序一個一個響 應，而不是等到一個響應回來才能發下一個請求，這樣就節省了很多請求到服務器的時間。不過，HTTP管線化仍舊有阻塞的問題，若上一響應遲遲不回，后面的 響應都會被阻塞到。
目前大部分模型都是，服務器把邏輯處理完之后，一次性把整個響應輸出。這里存在一個阻塞的過程，邏輯處理一般都涉及IO操作的都比較慢，而現代瀏 覽器都支持邊接收數據邊渲染，所以其實服務器可以接收到請求時就把頁面框架flush出來，如果頁面包含多個較獨立部分，也可以每處理完一部分就馬上輸 出，這樣可以縮短白屏。從用戶感受上可能會更好，頁面上一直有所反應，而不是一直白屏，完全不知道你在干嘛。
各種各樣的優化，都在填HTTP/1.x留下的坑，HTTP/2帶著填坑的使命，從根本上去解決這些問題。HTTP/1.x是一個文本協議，這注定它是非常冗余的協議，HTTP/2改變了這一點，在HTTP/1.x的語義上，將文本數據封裝在幀里，并采用二進制編碼。
下圖中binary framing就是二進制分幀層，這里會將HTTP/1.x的header翻譯成headers類型的幀，將body翻譯成data類型的幀。
HTTP/2的性能怎樣，akamai的這個demo(https://http2.akamai.com/demo)估計會讓你很興奮。
下面詳細介紹下HTTP/2。
多路復用在HTTP/2中，有兩個非常重要的概念：幀（frame）和流（stream）。
1、幀（frame）
HTTP/2中數據傳輸的最小單位，因此幀不僅要細分表達HTTP/1.x中的各個部份，也優化了HTTP/1.x表達得不好的地方，同時還增加了HTTP/1.x表達不了的方式。
每一幀都包含幾個字段，有length、type、flags、stream identifier、frame playload等，其中type代表幀的類型，在HTTP/2的標準中定義了10種不同的類型，包括上面所說的HEADERS frame和 DATA frame。此外還有
PRIORITY（設置流的優先級）
RST_STREAM（終止流）
SETTINGS（設置此連接的參數）
PUSH_PROMISE（服務器推送）
PING（測量RTT）
GOAWAY（終止連接）
WINDOW_UPDATE（流量控制）
CONTINUATION（繼續傳輸頭部數據）
2、流（stream）“流”在HTTP/2中是一個邏輯上的概念，就是說在一個TCP連接上，我們可以向對方不斷發送一個個的消息，這里每一個消息看成是一幀，而每一 幀有個stream identifier的字段標明這一幀屬于哪個“流”，然后在對方接收時，根據stream identifier拼接每個“流”的所有幀組成一整塊數據。我們把HTTP/1.x每個請求都當作一個“流”，那么請求化成多個流，請求響應數據切成多 個幀，不同流中的幀交錯地發送給對方，這就是HTTP/2中的多路復用。
從上圖我們可以留意到：
- 不同的流在交錯發送；
- HEADERS 幀在 DATA 幀前面；
- 流的ID都是奇數，說明是由客戶端發起的，這是標準規定的，那么服務端發起的就是偶數了。
多路復用讓HTTP連接變得很廉價，只需要創建一個新流即可，這不需要多少時間，而在HTTP/1.x時代卻要經歷三次握手時間或者隊首阻塞等問 題。而且創建新流默認是無限制的，也就是可以無限制的并行請求下載。不過，HTTP/2還是提供了 SETTINGS_MAX_CONCURRENT_STREAMS 字段在 SETTINGS 幀上設置，可以限制并發流數目，標準上建議不要低于100以保證性能。
優化Web性能有一個常用的技術，就是圖片延遲加載，目的是除了節省流量外，還能避免圖片資源與其他重要的腳本資源競爭下載。
HTTP/2提供了流的優先級與依賴性這種機制，可用 HEADERS 幀或 PRIORITY 幀設置，不過協議并沒有提供如何處理優先級的具體算法，這可由服務器靈活應對。我用個例子來說明這個機制。
<!-- a.html --> <html> <body> <script src="a.js"></script> <img src="a.jpg"> <img src="b.jpg"> <link rel="stylesheet" type="text/css" href="style.css"> </body> </html>
瀏覽器是邊下載邊解析的，文檔解析器首先遇到a.js，它就會去下載并且阻塞頁面，同時，資源探測器會繼續向下掃描，發現a.jpg、b.jpg 和style.css并服務器發起請求。在沒有優先級機制時，a.jpg、b.jpg會跟重要的a.js、style.css競爭下載，但在HTTP/2 中，瀏覽器可以給a.jpg、b.jpg設置較低的優先級，另外依賴關系為
這樣服務器根據優先級信息，首先吐出a.js、style.css，再吐出圖片，因此頁面在沒有圖片的情況下提前進入可交互狀態。例子所說的是在 瀏覽器層面上harcode的一個優先級策略，再比如上文提到的prefetch就可以給一個更低的優先級。在代碼層面上，也許之后會提供一些控制優先級 的特性，類似于目前只有IE支持的lazyload attribute。
服務器推送作為HTTP/2的一個重磅新功能，我們不要簡單理解字面意思，其實不是你想推，想推就能推的，服務器要遵循請求-響應這個模型，只不過服務器對 同一請求可以推送多個響應。客戶端在交換 SETTINGS 幀時，設置字段 SETTINGS_ENABLE_PUSH（0x2） 為1顯式允許服務器推送。
在HTTP/1.x時代，其實我們已經體驗過了“服務器推送”，就是資源內嵌到HTML里。服務器在響應HTML時，就已經知道瀏覽器會請求哪些 子資源了，這時一并響應這些子資源，可以節省了服務器到瀏覽器以及瀏覽器解析再發請求的這段延遲。但是內聯的問題是瀏覽器不會緩存這些數據，這意味要浪費 很多流量，而且有緩存時網頁性能還是很好的。
服務器推送解決了這個問題。服務器在接受到請求時，分析出要推送的資源，先發個 PUSH_PROMISE 幀給瀏覽器。此幀包含一個新的流ID，還有header block fragment字段，內容是請求的頭部信息，可理解為服務器模擬瀏覽器發起請求，然后再發送各個response header和response body。瀏覽器收到 PUSH_PROMISE 幀時，根據header block fragment字段里的url，可以知道當前有沒有緩存，從而判斷是否要接收。如果不要，瀏覽器就要發送個 RST_STREAM 來終止服務器推送。
如果瀏覽器不要這個推送，就會出現浪費流量的現象，因為整個過程都是異步的，在服務器接收到RST_STREAM時，響應很有可能部份發出或者全 部發出了。這種情況只能視場景而定，若是流量浪費不能容忍，我們可以使用prefetch來替代，讓瀏覽器盡早發現需要的資源，而HTTP/2中創建新的 請求并不需要多少時間，所以大概多了個RTT的時間。
首部壓縮服務器推送，此推送非彼推送，一開始以為，是不是以后可以拋棄輪詢這種技術了？并不是，該輪詢還是要輪詢。那么，在開啟keep-alive的情況下，輪詢在HTTP/2中的性能沒什么提升嗎？也并不是。
在HTTP/1.x中首部是沒有壓縮的，gzip只會壓縮body，HTTP/2提供了首部壓縮方案。一般輪詢請求首部，特別是cookie占用很多大部份空間，首部壓縮使得整個HTTP數據包小了很多，傳輸也就會更快。
剛開始spdy提出的首部壓縮方案比較簡單粗暴，直接像壓縮body那樣壓縮首部，這看起來好像沒什么不妥，但是有安全隱患，會有受到CRIME 式攻擊的可能性。這種攻擊方法簡單說，就是不斷地利用已知數據去探測密文，達到破解的目的。無損壓縮算法會有個特性，數據越冗余，壓縮效率越好。而首部中 的很多字段是已知的，我們只要構造個請求，請求中帶有首部的某個字段，經壓縮再加密后的密文長度就會有所變化，然后不斷構造猜測該字段的值，同時觀察密文 的長度，慢慢地確定首部字段的值。
GET /pwd=0 HTTP/1.1 Cookie: pwd=123 GET /pwd=1 HTTP/1.1 Cookie: pwd=123
我們會發現，前者的密文長度比后者長，這樣就確定了“d”，再慢慢的猜測，達到破解的目的。
HTTP/2中拋棄了這種方案，用專門設計的HPACK。它是在服務器和客戶端各維護一個“首部表”，表中用索引代表首部名，或者首部鍵-值對， 上一次發送兩端都會記住已發送過哪些首部，下一次發送只需要傳輸差異的數據，相同的數據直接用索引表示即可，另外還可以選擇地對首部值壓縮后再傳輸。按照 這樣的設計，兩次輪詢請求的首部基本是一樣的，那之后的請求基本只需要發送幾個索引就可以了。
“首部表”有兩種，一種是靜態表，即HTTP/2協議內置了常用的一些首部名和首部鍵值對。另一種是動態表，保存自定義的首部或五花八門的鍵值對等，動態表可以通過SETTINGS幀的SETTINGS_HEADER_TABLE_SIZE規定大小。
一次完整的HTTP/2通信
- 在尚未知道服務器是否支持HTTP/2時，http請求頭部加上upgrade: h2c，表明客戶端支持HTTP/2，詢問服務器要不要切換協議。
- 瀏覽器同時發送HTTP2-Settings頭部，帶上base64編碼的SETTINGS frame。
- 對于https請求，是在TLS握手時進行協商，瀏覽器發送ClientHello時，帶上h2標志，表明客戶端支持HTTP/2。
- 若服務器不支持，則忽略upgrade頭部，正常響應。若支持，則發送101響應，以空行結束響應，并開始發送HTTP/2幀。
- 服務器要先響應connection preface，帶上SETTINGS frame。
- 服務器創建新流，推送a.js。然后繼續發送index.html和a.js的response header、response body。
- 瀏覽器收到PUSH_PROMISE幀，發現服務器要推送的內容已經在瀏覽器緩存里了，遂發送RST_STREAM拒絕推送。
- 服務器收到RST_STREAM后，不再推送a.js剩下的數據。
- 服務器因為一些原因想要關閉連接，發送GOAWAY幀。也可以由瀏覽器關閉，只要瀏覽器覺得之后不再有請求了。
HTTP/2才剛剛正式發布不久，支持程度并沒有那么好，以后應該有相當長的一段時間，HTTP/2要與HTTP/1.x共存。特別是，Win7 快要成為下個XP的節奏，那么IE9就是下個IE6了。雙協議部署上，可能會有不少麻煩之處。HTTP/1.x時代的很多優化，在HTTP/2是不必要 的，也有沖突的，甚至是累贅。
比如子資源的位置，可以用HTTP/2優先級解決。
比如域名分區，在HTTP/2中本來可以用一個連接完成，卻要用多個連接，這樣就有性能損耗了。
比如合并、雪碧圖，之前是為了減少請求，但在HTTP/2新起請求不費事，但拆分開來倒可以更好地利用瀏覽器緩存。還有類似的內聯資源，可以用服務器推送，也同樣可以更好地利用緩存。
更多具體的問題，需要在生產實踐中得出了。
參考資料《Web性能權威指南》
https://httpwg.github.io/specs/rfc7540.html（HTTP/2協議）
https://httpwg.github.io/specs/rfc7541.html（HPACK）
https://imququ.com/post/http2-resource.html（HTTP/2資料匯總）
https://imququ.com/post/server-push-in-http2.html（HTTP/2中的Server Push討論）
https://www.gitbook.com/book/ye11ow/http2-explained/details（HTTP2講解）
http://httparchive.org/
http://segmentfault.com/a/1190000002642924
本文轉自： coding.js的微信公眾號