外插一下，最近研究的。

HTTP1.1 遇到的問題

以前 HTTP 1.1 在頁面載入獲取資源 (圖片, 字體, JS, CSS) 時，都必須占用一個網路連線 (TCP Connect)，下載完才能下載下一個，Browser 無法同時下載。所以 HTTP1.1 為了加快下載速度，
只好同時允許六個 TCP Connect 併發 Request，同時下載 6 個資源，你可能會想那就增加 TCP Connect 就好啦，但也不是說無止盡的增加就能解決，因為每次 TCP Connect 都必須先經過三相交握的過程去建立初始化連線，而這個過程本身是相當費時的。

這樣有甚麼問題 ?

因為剛剛提到過多的 TCP Connect 會造成 Browser Pending，且因為平凡經過三相交握過程，導致
頁面載入時間過久，所以在 HTTP1.1 時，重點應該解決的是盡量減少 Request 的數量

所以才會有以下解法:

• 將圖片資源轉 Base64 轉成純文字放在 src ，不用在發 Request，但缺點是會破壞 Browser catch，原本可以 catch 靜態資源但 base64 轉成純文字就無法 catch 了，並且 Base64 會轉成純字放在 HTML，這會使圖片大小變更大，並且增加 HTML 下載時間。
• CSS Sprites
• 利用 Gulp/Grunt 等任務工具，將合併 CSS / JS，減少 Request 數量。

HTTP2.0 怎麼解決

• 只需要一個網路連線 (TCP Connect) 連接 Server 下載所有資源，不需像以前要一直建立 Connect，浪費建立時初始化的時間。
• 連線多工（Multiplexing），意思是能從單一 TCP Connect 中，同時傳輸處理多個 Request & Response 併發多個 CSS/JS/Image 等資源，並且不會佔住 TCP Connect ，所以部會 Pending 住其他資源的 Request，由此理解這就是 HTTP2.0 在傳輸多個資源時，能夠載入速度加快的優勢。
• HTTP1.1 時封包傳輸是使用純文字，HTTP2.0 是用 Binary 二進位的封包結構設計，對伺服器和瀏覽器來說，可以更快的解析這些資料，因為不用再從純文字再轉乘二進位。

HTTP2.0 有甚麼缺點

目前各瀏覽器大部分實作要啟用 HTTP2.0 ，必須啟用 HTTPS，所以必須去申請 TLS/SSL 安全性憑證 ，但如果只是幫網頁升級成 HTTP2.0，那還只是跑流程不難，但如果你的網站有一定規模，裡面的一些靜態資源路徑都是使用 http:// 開頭的話你突然升級成 HTTPS，那麼網頁因為 HTTPS 會給的安全性憑證 Icon 會消失並顯示你的網頁有漏洞，且如果是 CSS/JS 檔案的話甚至不下載了。

解決方法可能是導入使用 Webpack，去設定 publicPath，在 complier 的時候去更改路徑的前綴。

從 HTTP1.1 到 HTTP2.0 影響了甚麼

從 HTTP1.1 我們知道因為 TCP Connect 有數量限制且會 Pending 的問題，所以我們知道要減少 Request 數量
EX:

• CSS Sprites
• Merge CSS / JS File
• Image Base64

但到了 HTTP2.0 之後，由於只有單一 TCP Connect 不須經過不斷建立 Connect 時間，且可以併發 多個 Request 進行多工處理，所以在此時減少 Request 數量的 Issue 優先度就並不是那麼高，反而是檔案大小，在傳輸檔案時不希望她過大造成 Request 時間過長，所以出現 code split，減輕單一檔案大小。

後來我們的思考偏向，希望畫面第一次載入能加快，能讓使用者越快看到畫面越好，所以圍繞著一個概念是，那我只下載使用者目前必要看到的資源就好了，所以出現了 Lazyload，甚至 dynamic import，去根據目前頁面需要去 import 不同的資源。