沐鳴測速註冊_HTTP請求合併 vs HTTP并行請求,誰更快?

面試時,經常會問候選人一個問題:如何提高網頁性能?

有些基礎的人都會提到這麼一條:減少/合併HTTP請求。

繼續問:瀏覽器不是可以并行下載資源嗎?將多個資源合併成一個資源,只使用一個HTTP請求下載,難道要比用多個HTTP請求并行下載沒有合併過的多個資源速度更快?

候選人:……(至今,還沒有遇到讓我滿意的回答)

減少HTTP請求,是雅虎前端性能優化35條軍規的第1條,2006年雅虎提出了這35條軍規,從那以後,就深深地影響到了一批又一批的前端開發者,即使在12年後的今天,影響力依舊不減…..

但是,雅虎軍規中還有1條是:拆分資源以最大化利用瀏覽器并行下載的能力。現在問題就來了,減少HTTP請求,但網頁所需的資源並不能減少(否則網頁就不再是之前的網頁了),所以減少HTTP請求,主要是通過合併資源來實現的,一邊是建議合併資源,一邊是建議拆分資源,顯然是有衝突的地方,那麼到底該怎麼做呢?網上有些文章也討論過這個問題,但大多是停留在想當然的理論分析上,而且忽略了TCP傳輸機制的影響。今天,老幹部就帶大家一起用實驗+理論,仔細探討下這個問題。

HTTP請求過程

一個HTTP請求的主要過程是:

DNS解析(T1) -> 建立TCP連接(T2) -> 發送請求(T3) -> 等待服務器返回首字節(TTFB)(T4) -> 接收數據(T5)。

如下圖所示,是Chrome Devtools中显示的一個HTTP請求,显示了HTTP請求的主要階段,注意,Queueing階段是請求在瀏覽器隊列中的排隊時間,並不計入HTTP請求時間

從這個過程中,可以看出如果合併N個HTTP請求為1個,可以節省(N-1)* (T1+T2+T3+T4) 的時間。

但實際場景並沒有這麼理想,上面的分析存在幾個漏洞:

  1. 瀏覽器會緩存DNS信息,因此不是每次請求都需要DNS解析。
  2. HTTP 1.1 keep-alive的特性,使HTTP請求可以復用已有TCP連接,所以並不是每個HTTP請求都需要建立新的TCP連接。
  3. 瀏覽器可以并行發送多個HTTP請求,同樣可能影響到資源的下載時間,而上面的分析顯然只是基於同一時刻只有1個HTTP請求的場景。

實驗論證

我們來做4組實驗,對比一個HTTP請求加載合併后的資源所需時間,和多個HTTP請求并行加載拆分的資源所需時間。每組實驗所用資源的體積大小有顯著差異。

實驗環境:

服務器:阿里雲ECS 1核 2GB內存 帶寬1M

Web服務器:Nginx (未啟用Gzip)

Chrome v66 隱身模式,禁用緩存

Client 網絡:wifi 帶寬20M

實驗代碼地址:https://github.com/xuchaobei/…

實驗 1

測試文件:large1.css、large2.css … large6.css,每個文件141K;large-6in1.css,由前面6個css文件合併而成,大小為846K。parallel-large.html引用large1.css、large2.css … large6.css, combined-large.html引用large-6in1.css,代碼如下:

// parallel-large.html
<!DOCTYPE html>
<html>

  <head>
    <meta charset="utf-8" />
    <title>Parallel Large</title>
    <link rel="stylesheet" type="text/css" media="screen" href="large1.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large2.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large3.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large4.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large5.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large6.css" />
  </head>

  <body>
    Hello, world!
  </body>

</html>
// combined-large.html
<!DOCTYPE html>
<html>

  <head>
    <meta charset="utf-8" />
    <title>Combined Large</title>
    <link rel="stylesheet" type="text/css" media="screen" href="large-6in1.css" />
  </head>

  <body>
    Hello, world!
  </body>

</html>

分別刷新2個頁面各10次,利用Devtools 的Network計算CSS資源加載的平均時間。

注意事項:

  1. large1.css、large2.css … large6.css的加載時間,計算方式為從第一個資源的HTTP請求發送開始,到6個文件都下載完成的時間,如圖2紅色框內的時間。
  2. 兩個html頁面不能同時加載,否則帶寬為兩個頁面所共享,會影響測試結果。需要等待一個頁面加載完畢后,再手動刷新加載另外一個頁面。
  3. 頁面兩次刷新時間間隔在1分鐘以上 ,以避免HTTP 1.1 連接復用對實驗的影響。​

實驗結果如下:

large-6in1.css large1.css、large2.css … large6.css
平均時間(s) 5.52 5.3

我們再把large1.css、large2.css … large6.css合併為3個資源large-2in1a.css、large-2in1b.css、large-2in1c.css,每個資源282K,在combined-large-1.html中引用這3個資源:

// combined-large-1.html
<!DOCTYPE html>
<html>

  <head>
    <meta charset="utf-8" />
    <title>Parallel Large 1</title>
    <link rel="stylesheet" type="text/css" media="screen" href="large-2in1a.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large-2in1b.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large-2in1c.css" />
  </head>

  <body>
    Hello, world!
  </body>

</html>

測試10次,平均加載時間為5.20s。

匯總實驗結果如下:

large-6in1.css large1.css、large2.css … large6.css large-2in1a.css、… large-2in1c.css
平均時間(s) 5.52 5.30 5.20

從實驗1結果可以看出,合併資源和拆分資源對於資源的總加載時間沒有顯著影響。實驗中耗時最少的是拆分成3個資源的情況(5.2s),耗時最多的是合併成一個資源的情況(5.52s),但兩者也只不過相差6%。考慮到實驗環境具有一定隨機性,以及實驗重複次數只有10次,這個時間差並不能表徵3種場景有明顯的時間差異性。

實驗 2

繼續增加css文件大小。

測試文件:xlarge1.css、xlarge2.css 、xlarge3.css,每個文件1.7M;xlarge-3in1.css,由前面3個css文件合併而成,大小為5.1M。parallel-xlarge.html引用xlarge1.css、xlarge2.css 、xlarge3.css, combined-xlarge.html引用xlarge-3in1.css。

測試過程同上,實驗結果如下:

xlarge-3in1.css xlarge1.css、xlarge2.css、xlarge3.css
平均時間(s) 37.72 36.88

這組實驗的時間差只有2%,更小了,所以更無法說明合併資源和拆分資源的總加載時間有明顯差異性。

實際上,理想情況下,隨着資源體積變大,兩種資源加載方式所需時間將趨於相同。

從理論上解釋,因為HTTP的傳輸通道是基於TCP連接的,而TCP連接具有慢啟動的特性,剛開始時並沒有充分利用網絡帶寬,經過慢啟動過程后,逐漸佔滿可利用的帶寬。對於大資源而言,帶寬總是會被充分利用的,所以帶寬是瓶頸,即使使用更多的TCP連接,也不能帶來速度的提升。資源越大,慢啟動所佔總的下載時間的比例就越小,絕大部分時間,帶寬都是被充分利用的,總數據量相同(拆分資源導致的額外Header在這種情況下完全可以忽略不計),帶寬相同,傳輸時間當然也相同。

實驗 3

減小css文件大小。

測試文件:medium1.css、medium2.css … medium6.css,每個文件9.4K;medium-6in1.css,由前面6個css文件合併而成,大小為56.4K。parallel-medium.html引用medium1.css、medium2.css … medium6.css, combined-medium.html 引用 medium-6in1.css。

實驗結果如下:

medium-6in1.css medium1.css、medium2.css … medium6.css
平均時間(ms) 34.87 46.24

注意單位變成ms

實驗3的時間差是33%,雖然數值上只差12ms。先不多分析,繼續看實驗4。

實驗 4

繼續減小css文件大小,至幾十字節級別。

測試文件:small1.css、small2.css … small6.css,每個文件28B;small-6in1.css,由前面6個css文件合併而成,大小為173B。parallel-medium.html引用small1.css、small2.css … small6.css, combined-medium.html 引用 small-6in1.css。

實驗結果如下:

small-6in1.css small1.css、small2.css … small6.css
平均時間(ms) 20.33 35

實驗4的時間差是72%。

根據實驗3和實驗4,發現當資源體積很小時,合併資源和拆分資源的加載時間有了比較明顯的差異。圖3和圖4是實驗4中的某次測試結果的截圖,當資源體積很小時,數據的下載時間(圖中水平柱的藍色部分所示)佔總時間的比例就很小了,這時候影響資源加載時間的關鍵就是DNS解析(T1) 、 TCP連接建立(T2) 、發送請求(T3) 和等待服務器返回首字節(TTFB)(T4) 。但同時建立多個HTTP連接本身就存在額外的資源消耗,每個HTTP的DNS查詢時間、TCP連接的建立時間等也存在一定的隨機性,這就導致併發請求資源時,出現某個HTTP耗時明顯增加的可能性變大。如圖3所示,small1.css加載時間最短(16ms),small5.css加載時間最長(32ms),兩者相差了1倍,但計算時間是以所有資源都加載完成為準,這種情況下,同時使用多個HTTP請求就會導致更大的時間不均勻性和不確定性,表現結果就是往往要比使用一個HTTP請求加載合併后的資源慢。

更複雜的情況

對於小文件一定是合併資源更快嗎?

其實未必,在一些情況下,合併小文件反而有可能明顯增加資源加載時間。

再說些理論的東西。為了提高傳輸效率,TCP通道上,並不是發送方每發送一個數據包,都要等到收到接收方的確認應答(ACK)后,再發送下一個報文。TCP引入了”窗口“的概念,窗口大小指無需等待確認應答而可以繼續發送數據的最大值,例如窗口大小是4個MSS(Maximum Segment Size,TCP數據包每次能夠傳輸的最大數據分段),表示當前可以連續發送4個報文段,而不需要等待接收方的確認信號,也就是說,在1次網絡往返(round-trip)中完成了4個報文段的傳輸。如下圖所示(MSS為1,窗口大小為4),1 – 4000 數據是連續發送的,並沒有等待確認應答,同樣的,4001 – 8000也是連續發送的。請注意,這隻是理想情況下的示意圖,實際情況要比這裏更複雜。

在慢啟動階段,TCP維護一個擁塞窗口變量,這個階段窗口的大小就等於擁塞窗口,慢啟動階段,隨着每次網絡往返,擁塞窗口的大小就會翻一倍,例如,假設擁塞窗口的初始大小為1,擁塞窗口的大小變化為:1,2,4,8……。如下圖所示。

實際網絡中,擁塞窗口的初始值一般是10,所以擁塞窗口的大小變化為:10,20,40 … ,MSS的值取決於網絡拓撲結構和硬件設備,以太網中MSS值一般是1460字節,按每個報文段傳輸的數據大小都等於MSS計算(實際情況可以小於MSS值),經過第1次網絡往返后,傳輸的最大數據為14.6K,第2次后,為(10+20) 1.46 = 43.8K, 第3次后,為(10+20+40) 1.46 = 102.2K。

根據上面的理論介紹,實驗4中,不管是合併資源,還是拆分資源,都是在1次網絡往返中傳輸完成。但實驗3,拆分后的資源大小為9.4K,可以在1次網絡往返中傳輸完成,而合併后的資源大小為56.4K,需要3次網絡往返才能傳輸完成,如果網絡延時很大(例如1s),帶寬又不是瓶頸,多了兩次網絡往返將導致耗時增加1s,這時候合併資源就可能得不償失了。實驗3並沒有產生這個結果的原因是,實驗中網絡延時是10ms左右,由於數值太小而沒有對結果產生明顯影響。

總結

對於大資源,是否合併對於加載時間沒有明顯影響,但拆分資源可以更好的利用瀏覽器緩存,不會因為某個資源的更新導致所有資源緩存失效,而資源合併后,任一資源的更新都會導致整體資源的緩存失效。另外還可以利用域名分片技術,將資源拆分部署到不同域名下,既可以分散服務器的壓力,又可以降低網絡抖動帶來的影響。

對於小資源,合併資源往往具有更快的加載速度,但在網絡帶寬狀況良好的情況下,因為提升的時間單位以ms計量,收益可以忽略。如果網絡延遲很大,服務器響應速度又慢,則可以帶來一定收益,但在高延遲的網絡場景下,又要注意合併資源后可能帶來網絡往返次數的增加,進而影響到加載時間。

其實,看到這裏,是合是分已經不重要了,重要的是我們要知道合分背後的原理是什麼,和業務場景是怎樣的。