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

2013 年 11 月份開始，我的部落格開始支援了 SPDY 協議（詳見這裡），也就是 HTTP/2 的前身。今年二月份，Google 宣佈將在 16 年初放棄對 SPDY 的支援，隨後 Google 自家支援 SPDY 協議的服務都切到了 HTTP/2。今年 5 月 14 日，HTTP/2 以 RFC 7540 正式釋出。目前，瀏覽器方面，Chrome 40+ 和 Firefox 36+ 都正式支援了 HTTP/2；伺服器方面，著名的 Nginx 表示會在今年底正式支援 HTTP/2。

不得不說這幾年 WEB 技術一直在突飛猛進，爆炸式發展。昨天還覺得 HTTP/2 很遙遠，今天已經遍地都是了。對於新鮮事物，有些人不願意接受，覺得好端端為什麼又要折騰；有些人會盲目崇拜，認為它是能拯救一切的救世主。HTTP/2 究竟會給前端帶來什麼，什麼都不是？還是像某些人說的「讓前端那些優化小伎倆直接退休」？我打算通過寫一系列文章來嘗試回答這個問題，今天是第一篇。

提出問題

我們知道，一個頁面通常由一個 HTML 文件和多個資源組成。有一些很重要的資源，例如頭部的 CSS、關鍵的 JS，如果遲遲沒有載入完，會阻塞頁面渲染或導致使用者無法互動，體驗很差。如何讓重要的資源更快載入完是我本文要討論的問題。

HTTP/1

分析

我們先來考慮資源外鏈的情況。通常，外鏈資源都會部署在 CDN 上，這樣使用者就可以從離自己最近的節點上獲取資料。一般文字檔案都會採用 gzip 壓縮，實際傳輸大小是檔案大小的幾分之一。服務端託管靜態資源的效率通常非常高，服務端處理時間幾乎可以忽略。在忽略網路因素、傳輸大小以及服務端處理時間之後，使用者何時能載入完外鏈資源，很大程度上取決於請求何時能發出去，這主要受下面三個因素影響：

• 瀏覽器阻塞（Stalled）：瀏覽器會因為一些原因阻塞請求。例如在 rfc2616 中規定瀏覽器對於一個域名，同時只能有 2 個連線（HTTP/1.1 的修訂版中去掉了這個限制，詳見 rfc7230，因為後來瀏覽器實際上都放寬了限制），超過瀏覽器最大連線數限制，後續請求就會被阻塞。再例如現代瀏覽器在載入同一域名多個 HTTPS 資源時，會有意等第一個 TLS 連線建立完成再請求其他資源；
• DNS 查詢（DNS Lookup）：瀏覽器需要知道目標伺服器的 IP 才能建立連線。將域名解析為 IP 的這個系統就是 DNS。DNS 查詢結果通常會被快取一段時間，但第一次訪問或者快取失效時，還是可能耗費幾十到幾百毫秒；
• 建立連線（Initial Connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文。這個過程通常也要耗費幾百毫秒；

當然我們一般都會給靜態資源設定一個很長時間的快取頭。只要使用者不清除瀏覽器快取也不重新整理，第二次訪問我們網頁時，靜態資源會直接從本地快取獲取，並不產生網路請求；如果使用者只是普通重新整理而不是強刷，瀏覽器會在請求頭帶上協商欄位 If-Modified-Since 或 If-None-Match，服務端對沒有變化的資源會響應 304 狀態碼，告知瀏覽器從本地快取獲取資源。304 請求沒有正文，非常小。

也就是說資源外鏈的特點是，第一次慢，第二次快。

再來看看資源內聯的情況。把 CSS、JS 檔案內容直接內聯在 HTML 中的方案，毫無疑問會在使用者第一次訪問時有速度優勢。但通常我們很少快取 HTML 頁面，這種方案會導致內聯的資源沒辦法利用瀏覽器快取，後續每次訪問都是一種浪費。

解決

很早之前，就有網站開始針對第一次訪問的使用者將資源內聯，並在頁面載入完之後非同步載入這些資源的外鏈版本，同時記錄一個 Cookie 標記表示使用者來過。使用者再次訪問這個頁面時，服務端就可以輸出只有外鏈版本的頁面，減小體積。

這個方案除了有點浪費流量之外（一份資源，內聯外鏈載入了兩次），基本上能達到更快載入重要資源的效果。但是在流量更加寶貴的移動端，我們需要繼續改進這個方案。

考慮到移動端瀏覽器都支援 localStorage，可以將第一次內聯引入的資源快取起來後續使用。快取更新機制可以通過在 Cookie 中存放版本號來實現。這樣，服務端收到請求後，首先要檢查 Cookie 頭中的版本標記：

• 如果標記不存在或者版本不匹配，就將資源內聯輸出，並提供當前版本標記。頁面執行時，會把內聯資源存入 localStorage，並將資源版本標記存入 Cookie；
• 如果標記匹配，就輸出 JavaScript 片段，用來從 localStorage 讀取並使用資源；

由於 Cookie 內容需要儘可能的少，所以一般只存總的版本號。這會導致頁面任何一處資源變動，都會改變總版本號，進而忽略客戶端所有 localStorage 快取。要解決這個問題可以繼續改進我們的方案：Cookie 中只存放使用者唯一標識，使用者和資源對應關係存在服務端。服務端收到請求後根據使用者標識，計算出哪些資源需要更新，從而輸出更有針對性的 HTML 文件。

這套方案要投入實際使用，要處理一系列異常情況，例如 JS / Cookie / localStorage 被禁用；localStorage 被寫滿；localStorage 內容損壞或丟失等等。考慮成本和實際收益，推薦只在移動專案中使用這種方案。

HTTP/2

對於 HTTP/2 來說，要解決前面這個問題簡直就太容易了，開啟「Server Push」即可。HTTP/2 的多路複用特性，使得可以在一個連線上同時開啟多個流，雙向傳輸資料。Server Push，意味著服務端可以在傳送頁面 HTML 時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發起請求再響應。另外，服務端主動推送的資源不是被內聯在頁面裡，它們有自己獨立的 URL，可以被瀏覽器快取，當然也可以給其他頁面使用。

服務端可以主動推送，客戶端也有權利選擇接收與否。如果服務端推送的資源已經被瀏覽器快取過，瀏覽器可以通過傳送 RST_STREAM 幀來拒收。

可以看到，HTTP/2 的 Server Push 能夠很好地解決「如何讓重要資源儘快載入」這個問題，一旦普及開來，可以取代前面介紹過的 HTTP/1 時代優化方案。

--EOF--

發表於 2015-05-19 23:58:03 ，並被新增「 HTTP2 、 HTTP 、 效能優化 」標籤 ，最後修改於 2015-05-19 01:35:03 。檢視本文 Markdown 版本 »

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