目前業內有個大部分人都讚同的觀點：網絡相比較15年前速度更慢，而且錯誤更多。由於不斷增加的JavaScript、框架、Webfonts和polyfills，已經抵消了更快的計算性能、網絡和協議帶來的優勢。那麼實際情況真的如此嗎？

開發者Lars Eidnes 加載了全球排行前100 萬的網站，追踪每個量化指標，並記錄了每個錯誤、關注每個請求的URL。他創建首個將網絡性能、錯誤和庫聯繫起來的數據庫。而在本文中，他對這些數據進行了分析，並幫助站長找到創建高性能網站的合適方法。

為什麼要加載100 萬個網頁?

正如文章開頭所提及的，當前網絡真的要比15 年前更慢了嗎? 開發者Lars Eidnes 試圖找到2020 年網絡速度變慢以及出現崩潰的主要原因。

這個計劃非常簡單：編寫一個網頁瀏覽器的腳本，讓它加載渲染前100 萬個域名的主頁面，然後按照目前可以量化的指標進行追踪：包括渲染時間、請求次數、，重繪，JavaScript錯誤，使用的庫等等。

對這些數據進行分析之後，我們能夠更深入的了解不同因素之間的影響。例如，哪些因素導致頁面加載時間過長？哪些庫和長時間的可交互時間（Time to Interactive，簡稱TTI）有關？最常見的錯誤是什麼？是什麼原因導致的？

總體情況

開發者使用Puppeteer 編寫了一個Chrome 腳本，啟動了200 個EC2 實例，並在周末的時候加載渲染100 萬個網站。整體數據如下：

HTTP 2 現在比HTTP 1.1 更常見，但HTTP 3 仍然很少見。(注意：我們把任何使用QUIC協議的東西都算作HTTP 3，即使Chrome有時會報告為HTTP 2 + QUIC)。這是對根文件而言，對於鏈接資源，協議號看起來有些不同。

對於鏈接資源，HTTP 3 的普及率大約是HTML 文檔情況下的100 倍。這怎麼可能是真的呢？因為所有的網站都在鏈接同樣的東西。

在很大一部分網站上都有少量的腳本鏈接。這意味著我們可以期待這些資源在緩存中，對嗎？不再是了。從Chrome 86開始，從不同域請求的資源將不共享緩存。火狐正在計劃實現同樣的功能。Safari多年來一直這樣分割緩存。

那麼，是什麼讓網絡變得緩慢？預測交互時間（Predicting time-to-interactive）

鑑於這個網頁的數據集和它們的加載時間指標，如果能了解一些關於是什麼讓網頁變慢的信息就更好了。對此，開發者重點研究了dominteractive 指標，也就是文檔成為用戶互動之前的時間。最簡單的做法是，我們只需要看看每個指標與dominteractive 的相關性。

基本上每個指標都與dominteractive 呈現正相關的關係，除了0.x 和1.x 版本之外。這些指標中的許多指標之間也是正相關的。我們需要一個更複雜的方法來了解導致高交互時間的各個因素。

其中有些指標是時間，以毫秒為單位。我們可以看一下他們的框圖，了解瀏覽器的時間都花在哪裡。導致長互動時間的各個因素的一種方法是做一個線性回歸，我們從其他指標預測dominteractive。

也就是說，我們給每個指標分配一個權重，將一個頁面的dominteractive 時間建模為其他指標的加權和，再加上一些常數。優化算法設置權重，使整個數據集的預測誤差最小化。通過回歸發現的權重大小，可以告訴我們每個指標對頁面加載緩慢的影響有多大？

開發者從回歸算法中排除時間指標。如果我們花了500ms 建立連接，就會給dominteractive 增加500ms，但這並不是一個特別有趣的見解。時間指標從根本上說是結果。我們希望了解是什麼原因導致了它們。

括號中的數字是優化算法學習的回歸係數。您可以將這些數字解釋為具有毫秒的單位。雖然確切的數字應該帶著鹽分（見下面的註釋），但看到分配給每個特徵的比例是很有趣的。

例如，該模型預測，每當傳遞主文檔所需的重定向時，會有354ms的減速。每當主HTML文檔通過HTTP2或更高版本交付時，模型預測的交互時間會降低477ms。對於文檔觸發的每一個請求，它預測了額外的16ms。

在解釋回歸係數時，我們需要記住，我們是在現實的簡化模型上操作。事實上，交互時間並不是由這些輸入指標的加權和決定的。顯然，模型沒有機會發現一些因果因素。混淆變量顯然是一個問題。

舉個例子，如果用HTTP2加載主文檔與通過HTTP2加載其他請求是相關的，那麼模型會把這個優勢渲染到main_doc_is_http2_or_greater 的權重中，即使速度的提升來自主文檔以外的請求。當我們將模型所說的內容映射到關於現實的結論時，我們需要謹慎。

不同HTTP 協議版本對dominteractive 的影響有多大？

這裡有一個有趣的圖，dominteractive 按用於傳遞HTML 主頁面的HTTP 協議版本來劃分。有極少數網站仍然通過HTTP 0.9 和1.0 交付。而這些網站恰好都很快。似乎我們無法脫離這樣一個事實：協議變得更快的效果是，程序員會很樂意通過向瀏覽器交付更多的東西來消耗這種加速。

這是對用於交付HTML根基頁面的協議版本而言。如果我們看一下協議對該文檔中鏈接的資源的影響呢？如果我們按協議版本對請求次數進行回歸，就會得到以下結果。

如果我們相信這一點，我們就會得出這樣的結論：將請求的資源從HTTP 1.1移到2上，速度會加快1.8倍，而從HTTP 2移到3上則會慢0.6 倍。HTTP 3真的是一個較慢的協議嗎？不是：更可能的解釋是HTTP 3 很少見，通過HTTP 3發送的少數資源（如Google Analytics）是對dominteractive影響大於平均水平的東西。

不同類型的內容對dominteractive 的影響有多大？

我們從傳輸的字節數來預測dominteractive的時間，按照傳輸的數據類型來劃分。在這裡，請求是按照發起請求的內容來劃分的。顯然，並不是所有的請求都是平等的。由鏈接元素觸發的請求（即CSS、favicons）和由CSS觸發的請求（即字體、更多CSS）以及腳本和iframe會大大減慢速度。

在XHR和fetch上做請求會預示著比基線dominteractive時間更快（可能是因為這些請求幾乎都是異步的）。CSS和腳本經常以渲染阻塞的方式加載，所以發現它們與較慢的交互時間相關聯也就不足為奇了。視頻的成本相對較低。

經驗教訓

我們在這裡並沒有發現任何新的優化技巧，但分析確實讓人了解到各種優化所能帶來的影響情況。以下說法似乎有很好的經驗支持。

● 盡可能少地提出請求請求的數量比傳輸的千字節數更重要。

● 對於你必須要做的請求，如果可以的話，通過HTTP2或更高版本來做。

● 盡量避免渲染阻塞請求，盡可能選擇異步加載。