close

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

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

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

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

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

總體情況

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

k9xny1fj.jpg

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

ifz9ybwa.jpg

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

41vs538s.jpg

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

那麼,是什麼讓網絡變得緩慢?預測交互時間(Predicting time-to-interactive)

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

qco1jtnn.jpg

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

g9cksjzx.jpg

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

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

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

jkeo7un1.jpg

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

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

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

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

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

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

rp93kbl9.jpg

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

79co38ee.jpg

如果我們相信這一點,我們就會得出這樣的結論:將請求的資源從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或更高版本來做。

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

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 Ken641228 的頭像
    Ken641228

    Ken641228的部落格

    Ken641228 發表在 痞客邦 留言(0) 人氣()