如今，互聯網上的內容越來越豐富，過去幾年時間，一個頁面產生請求和整個大小都一直增長，這個趨勢還會一直保持，對頁面性能優化也要馬不停蹄。



一個頁面，會經歷過加載資源，執行腳本，渲染界面的過程。我們知道，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預解析技術，因為服務器是知道頁面即將會發生哪些請求的，那我們可以在頁面頂部，插入 ，讓瀏覽器先解析一下這個域名。那么，后續掃到同域的請求，就可以直接從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管線化可以克服同域并行請求限制帶來的阻塞，它是建立在持久連接之上，是把所有請求一并發給服務器，但是服務器需要按照順序一個一個響應，而不是等到一個響應回來才能發下一個請求，這樣就節省了很多請求到服務器的時間。不過，HTTP管線化仍舊有阻塞的問題，若上一響應遲遲不回，后面的響應都會被阻塞到。
  
  
  
  bigpipe
  
  目前大部分模型都是，服務器把邏輯處理完之后，一次性把整個響應輸出。這里存在一個阻塞的過程，邏輯處理一般都涉及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 幀設置，不過協議并沒有提供如何處理優先級的具體算法，這可由服務器靈活應對。我用個例子來說明這個機制。
    Html代碼
  • ?
  • ?
  • <script src=a.js></script>
  • ?
  • ?
  • 
    瀏覽器是邊下載邊解析的，文檔解析器首先遇到a.js，它就會去下載并且阻塞頁面，同時，資源探測器會繼續向下掃描，發現/uploadfile/2015/1020/20151020033422244.jpg、/uploadfile/2015/1020/20151020033422106.jpg和style.css并服務器發起請求。在沒有優先級機制時，/uploadfile/2015/1020/20151020033422244.jpg、/uploadfile/2015/1020/20151020033422106.jpg會跟重要的a.js、style.css競爭下載，但在HTTP/2中，瀏覽器可以給/uploadfile/2015/1020/20151020033422244.jpg、/uploadfile/2015/1020/20151020033422106.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式攻擊的可能性。這種攻擊方法簡單說，就是不斷地利用已知數據去探測密文，達到破解的目的。無損壓縮算法會有個特性，數據越冗余，壓縮效率越好。而首部中的很多字段是已知的，我們只要構造個請求，請求中帶有首部的某個字段，經壓縮再加密后的密文長度就會有所變化，然后不斷構造猜測該字段的值，同時觀察密文的長度，慢慢地確定首部字段的值。
    Java代碼
  • 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新起請求不費事，但拆分開來倒可以更好地利用瀏覽器緩存。還有類似的內聯資源，可以用服務器推送，也同樣可以更好地利用緩存。
      更多具體的問題，需要在生產實踐中得出了。

來源:https://www.2cto.com/kf/201510/446824.html

總結

以上是生活随笔為你收集整理的Web性能优化与Http2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。