雖然我們生活在一個寬帶無處不在、4/5G 幾乎全覆蓋的時代，但網站加載緩慢還是常態，就算我們打開一個以文本為中心的新聞網站，都可能需要至少 30 秒才能開始閱讀。畢竟在內容膨脹時代，一張照片就能輕易超過 1MB 大小，許多網站為了顯示幾段文本，還會單獨加載至少 10MB 的 JS 和自定義字體。

　　對此，對優化和極簡主義充滿熱情的資深 Web 開發 Nathaniel 告訴我們，你應該讓你的網頁盡力控制在 14KB 以內，而且即使對于以富媒體為中心的網站，這條 14KB 的規則可能仍然值得遵循。如果 14KB 不足以用于最終布局，則需要優先考慮 “首屏” 字節，可以用發送給訪問者的前 14KB 數據來渲染一些有用的東西，減少用戶還沒有開始閱讀就流失掉的機會。

　　網頁越小，加載速度就越快——這一點都不奇怪。

　　但令人感到驚訝的是，14KB 網頁的加載速度比 15KB 要快得多——可能快 612 毫秒——而 15KB 和 16KB 網頁之間的加載速度差異微乎其微。

　　這是 TCP 慢啟動算法導致的。本文將介紹這個算法、它的原理以及為什么你應該關注它。但首先我們需要快速過一遍一些基礎知識。

　　1 TCP 是什么

　　傳輸控制協議(Transmission Control Protocol，TCP)是一種使用 IP 協議可靠地發送數據包的方法——有時被稱為 TCP/IP。

　　當瀏覽器向你的網站(或圖像或樣式表)發出請求時，它會使用 HTTP 請求。HTTP 建立在 TCP 之上，一個 HTTP 請求通常由許多 TCP 數據包組成。IP 只是一個將數據包從互聯網上的一個位置發送到另一個位置的系統。IP 沒有檢查數據包是否成功到達目的地的方法。

　　對于網站來說，確保所有的數據到達請求端是非常關鍵的，否則我們可能會因為丟失數據包無法獲得完整的網頁。但在網絡的其他應用場景中，這一點并不那么重要——比如流媒體直播視頻。

　　TCP 是 IP 的擴展，瀏覽器和網站服務器通過它告訴對方哪些數據包已經成功到達。

　　服務器發送一些數據包，然后等待瀏覽器已經收到數據包的響應(這叫確認或 ACK)，然后它繼續發送更多的數據包——或者如果它沒有收到 ACK，將再次發送相同的數據包。

　　2 什么是 TCP 慢啟動

　　TCP 慢啟動是一種算法，服務器用它來確定一次可以發送多少數據包。

　　當瀏覽器第一次連接到服務器時，服務器無法知道它們之間的帶寬是多少。帶寬是指在單位時間內網絡可以傳輸的數據量。通常以比特 / 秒(b/s)為單位。我們可以用管道來作類比——把帶寬想象成每秒從管道流出多少水。

　　服務器不知道網絡連接可以處理多少數據——所以它先發送少量且安全的數據——通常是 10 個 TCP 數據包。如果這些數據包成功地到達網站訪問者，他們的計算機返回確認(ACK)，表示數據包已經被收到了。然后，服務器發送更多的數據包，但這一次它將數據包的數量增加了一倍。

　　這個過程會不斷重復，直到數據包丟失，服務器沒有收到 ACK。(此時，服務器會繼續發送數據包，但速度較慢)。

　　這就是 TCP 慢啟動的要點——在現實當中，雖然算法各不相同，但這是它的基本原理。

　　3 那么 14KB 這個數字是怎么來的

　　大多數 Web 服務器的 TCP 慢啟動算法都是從發送 10 個 TCP 數據包開始的。

　　TCP 數據包最大長度為 1500 字節。這個最大值不是由 TCP 規范設置的，它來自于以太網標準。

　　每個 TCP 數據包的標頭占了 40 個字節，其中 16 個字節用于 IP，另外 24 個字節用于 TCP。

　　這樣每個 TCP 數據包還剩下 1460 個字節。10 x 1460 = 14600 字節，或大約 14KB!

　　因此，如果你能把網站的網頁——或網頁的關鍵部分——壓縮到 14KB，就可以為訪問者節省大量的時間——他們和網站服務器之間的往返時間。

　　一個數據往返能有多糟糕?但人們非常沒有耐心——一個數據往返可能會出奇地長，具體多長取決于延遲…… 延遲是指數據包從源傳輸到目的地所花費的時間。如果帶寬是每秒鐘可以通過管道的水的數量，那么延遲就是一滴水進入管道后從另一端流出所花費的時間。

　　下面是一個關于延遲有多糟糕的例子。

　　衛星網絡

　　衛星網絡是由環繞地球軌道的衛星提供的，在人煙稀少的地區、石油鉆井平臺、游輪以及飛機上，人們可以使用這種網絡。

　　為了說明這種糟糕的延遲，我們想象一群在石油鉆井平臺工作的兄弟把骰子忘在了家里，他們需要通過 missingdice.com(少于 14KB)來玩《龍與地下城》游戲。

　　首先，他們中的一個用手機發出一個網頁請求……

　　手機將請求發送到鉆井平臺的 WiFi 路由器，路由器將數據發送給平臺上的衛星天線，我們假設這可能需要 1 毫秒時間。

　　然后，衛星天線將數據發送到地球軌道上方的衛星。

　　通常，這是通過在地球表面上方 35786 公里處運行的軌道衛星實現的。光速為 299792458 米 / 秒，所以信息從地球發送到衛星需要 120 毫秒。然后，衛星將信息傳回地面接收站，這又需要 120 毫秒。

　　然后，地面站必須將請求發送到位于地球任意位置的服務器(當光通過光纖電纜傳輸時，速度會降至每秒 200000000 米)。如果地面站和服務器之間的距離等于紐約到倫敦之間的距離，那么大約需要 28 毫秒，如果地面站和服務器之間的距離等于紐約到悉尼之間的距離，則需要 80 毫秒——所以我們姑且定一個 60 毫秒的數字(這個數字便于計算)。

　　然后，服務器需要處理請求，這可能需要 10 毫秒，然后服務器再次將它發送出去。

　　回到地面站，進入太空，回到衛星天線，然后回到無線路由器，再到手機上。

　　手機 -> WiFi 路由器 -> 衛星天線 -> 衛星 -> 地面站 -> 服務器 -> 地面站 -> 衛星 -> 衛星天線 -> WiFi 路由器 -> 手機

　　如果我們算一下，就是 10 + (1 + 120 + 120 + 60) x 2 = 612 毫秒。

　　這是每次往返額外的 612 毫秒——也許這看起來不是很長時間，但你的網站可能只是為了獲取第一個資源就需要許多個往返。

　　另外，HTTPS 在完成第一個往返之前需要額外的兩次往返——這使延遲達到了 1836 毫秒!

　　對于生活在陸地上的人，延遲又是怎樣的

　　衛星網絡似乎是一個極端的例子——我選擇它作為例子是因為它能夠充分說明了網絡延遲這個問題——但對于生活在陸地上的人來說，延遲可能比這更糟糕，原因有很多。

　　2G 網絡的延遲通常在 300 毫秒到 1000 毫秒之間;

　　3G 網絡的延遲可以在 100 毫秒到 500 毫秒之間;

　　嘈雜的移動網絡——比如在一個異常擁擠的地方，比如音樂節;

　　處理大流量的服務器;

　　其他一些不好的東西。

　　不穩定的網絡連接也會導致數據包丟失——導致需要另一個往返來獲取丟失的數據包。

　　4 了解了 14KB 法則，接下來可以做些什么

　　當然，你應該讓你的網頁盡可能的小——你愛你的訪客，你希望他們開心。將每個頁面的大小控制在 14KB 以內是一個不錯的主意。

　　這 14KB 可以是壓縮數據——所以實際上可以對應大約 50KB 的未壓縮數據——這已經非常慷慨了。要知道，阿波羅 11 的制導計算機只有 72KB 內存。

　　去掉自動播放的視頻、彈出窗口、Cookie、Cookie 橫幅、社交網絡按鈕、跟蹤腳本、JavaScript 和 CSS 框架，以及所有其他人們不喜歡的垃圾——你可能就能實現 14KB 法則。

　　假設你已經盡力將所有內容控制在 14KB 以內，但仍然做不到——但 14KB 法則仍然很有用。

　　你可以用發送給訪問者的前 14KB 數據來渲染一些有用的東西——例如一些關鍵的 CSS、JS 和解釋如何使用你的應用程序的前幾段文本。 需要注意的是，14KB 法則包含了 HTTP 標頭——這些是未壓縮的(即使是 HTTP/2 的第一個響應)，也包含圖片，所以你應該只加載在頁面上方的內容，并保持它們最小，或者使用占位符，讓訪問者知道他們在等待一些更好的內容。

　　關于這個法則的一些注意事項

　　14KB 法則更像是一種經驗之談，而不是計算的基本法則。

　　一些服務器已經將 TCP 慢啟動初始窗口從 10 個數據包增加到 30 個;

　　有時服務器知道它可以從更大數量的數據包開始傳輸，因為它使用 TLS 握手來建立一個更大的窗口;

　　服務器可以緩存路由可管理的數據包數量，并在下一次連接時發送更多的數據包;

　　還有其他需要注意的地方——這里有一篇文章更深入地探討關于為什么 14KB 法則并不總是這么回事。

　　HTTP/2 和 14KB 法則

　　有一種觀點認為，在使用 HTTP/2 時，14KB 法則不再適用。我已經讀了所有我能讀到的關于這個問題的東西，但我還沒有看到任何證據表明使用 HTTP/2 的服務器已經停止使用 TCP 慢啟動(從 10 個數據包開始)。

　　HTTP/3 和 QUIC

　　與 HTTP/2 類似，有一種觀點認為 HTTP/3 和 QUIC 將廢除 14KB 法則——事實并非如此。實際上，QUIC 仍然建議使用 14KB 法則。