過度使用延遲載入的效能影響

以資料為依據的建議，協助您在考量 Core Web Vitals 的情況下延遲載入圖片。

Felix Arntz

Rick Viscomi

延遲載入技術會延後下載資源，直到需要時才下載，藉此節省數據用量，並減少重要素材資源的網路爭用情形。這項屬性在 2019 年成為網路標準，目前大多數主要瀏覽器都支援圖片的 loading="lazy"。

本指南總結了如何分析公開的網路透明度資料和臨時 A/B 測試，以瞭解瀏覽器層級圖片延遲載入的採用和成效特性。研究結果指出，延遲載入功能可有效減少不必要的圖片位元組，但過度使用可能會對效能造成負面影響。具體來說，這項分析顯示，在初始可視區域內更積極地載入圖片，同時自由延遲載入其餘圖片，可以兩全其美：載入較少位元組，並改善Core Web Vitals。

採用率

根據 HTTP Archive 的最新資料，29% 的網站使用內建圖片延遲載入功能，且採用率正快速成長。

查詢 HTTP Archive 專案中的原始資料，可讓我們更清楚瞭解哪些類型的網站會推動採用：使用瀏覽器層級圖片延遲載入功能的網站中，有 84% 使用 WordPress，2% 使用其他 CMS，其餘 14% 則未使用已知的 CMS。這些結果清楚顯示 WordPress 在採用率方面領先群雄。

採用率也值得注意。一年前 (2020 年 7 月)，使用延遲載入的 WordPress 網站在約 600 萬個網站的語料庫中占了數萬個 (占總數的 1%)。光是 WordPress 採用延遲載入的網站數量，就已成長到超過 100 萬個 (占總數的 14%)。

關聯成效

深入探討 HTTP 封存，可以比較有和沒有瀏覽器層級圖片延遲載入的網頁，在最大內容繪製 (LCP) 指標方面的表現。LCP 資料來自 Chrome 使用者體驗報告 (CrUX) 的實際使用者體驗，而非實驗室中的合成測試。下圖使用盒鬚圖，以視覺化方式呈現各網頁第 75 個百分位數 LCP 的分布情形：線條代表第 10 和第 90 個百分位數，方塊代表第 25 和第 75 個百分位數。

未使用延遲載入的中位數網頁，第 75 個百分位數的 LCP 為 2,922 毫秒，而使用延遲載入的中位數網頁則為 3,546 毫秒。整體而言，使用延遲載入的網站，LCP 效能往往較差。

請注意，這些是相關性結果，不一定代表延遲載入是效能降低的原因。假設 WordPress 網站的速度通常較慢，且延遲載入群組中有很多這類網站，這或許能解釋兩者之間的差異。為了消除這種變異性，可以將焦點縮小到 WordPress 網站。

可惜的是，深入分析 WordPress 網頁時，也會出現相同的模式；使用延遲載入的網頁，LCP 效能往往較慢。未採用延遲載入的 WordPress 網頁中位數，其第 75 百分位數 LCP 為 3,495 毫秒，而採用延遲載入的網頁中位數則為 3,768 毫秒。

這仍無法證明延遲載入導致網頁速度變慢，但使用延遲載入確實與效能降低有關。為找出因果關係，我們在實驗室中設定了 A/B 測試。

因果成效

A/B 測試的目標是證明或反駁以下假設：WordPress 核心中實作的內建圖片延遲載入功能，會導致 LCP 效能降低，且圖片位元組數減少。測試方法是使用 twentytwentyone 主題測試 WordPress 示範網站。我們使用 WebPageTest，在電腦和模擬行動裝置上測試封存和單一網頁類型 (類似首頁和文章頁面)。我們測試了啟用和未啟用延遲載入的各種網頁組合，每項測試執行九次，以取得 LCP 值和圖片位元組數的中位數。

這些結果比較了電腦和行動裝置上封存頁面和單一頁面測試的中位數 LCP (以毫秒為單位)。在封存頁面上停用延遲載入後，LCP 顯著改善。不過，在單頁上，差異較小。

停用延遲載入功能後，單一網頁的載入速度似乎稍微加快。不過，電腦和行動裝置測試的 LCP 差異均小於一個標準差，因此這可能是變異所致，整體而言，這項變更的影響中性。相較之下，封存頁面的差異接近兩到三個標準差。

這些結果比較了每項測試的圖片位元組中位數 (以 KB 為單位)。如預期，延遲載入對於減少圖片位元組數有非常明顯的正面效果。如果實際使用者捲動整個網頁，所有圖片都會在進入可視區域時載入，但這些結果顯示初始載入網頁效能有所提升。

總結 A/B 測試的結果，WordPress 使用的延遲載入技術，顯然有助於減少圖片位元組，但代價是 LCP 延遲。

測試修正

WordPress 目前針對這項實驗實作的延遲載入功能，最重要的部分在於延遲載入可視區域內的圖片 (不需捲動位置)。CMS 網誌文章指出，這是一種應避免的模式，但當時的實驗資料顯示，對 LCP 的影響微乎其微，因此值得簡化 WordPress 核心的實作。

根據這項新資料，我們建立了一項實驗性修正，避免延遲載入不需捲動位置的圖片，並在與第一次 A/B 測試相同的條件下測試修正。

這些結果更令人滿意。如果只對不需捲動位置下方的圖片進行延遲載入，LCP 迴歸就會完全反轉，甚至可能比完全停用延遲載入時略有改善。怎麼可能比完全不延遲載入更快？其中一個解釋是，不載入不需捲動位置的圖片，可減少與 LCP 圖片的網路競爭，進而加快載入速度。

就圖片位元組而言，修正後的行為與預設行為完全相同。這點很棒，因為這是目前做法的優勢之一。

這項修正有一些注意事項。WordPress 會在伺服器端決定要延遲載入哪些圖片，也就是說，WordPress 不知道使用者的可視區域大小，也不知道圖片是否一開始就在可視區域內載入。因此，修正程式會根據標記中圖片的相對位置，使用經驗法則猜測圖片是否會在可視區域中載入。具體來說，如果圖片是網頁上的第一張精選圖片，或是主要內容中的第一張圖片，系統會假設圖片位於不需捲動位置或附近，因此不會延遲載入。

網頁層級條件 (例如標題字數或主要內容開頭的段落文字量) 可能會影響圖片是否位於可視區域內。此外，使用者層級的條件也可能影響經驗法則的準確度，尤其是可視區域大小，以及會變更網頁捲動位置的錨點連結。

因此，請務必瞭解，修正措施僅經過校正，可在一般情況下提供良好效能，可能需要微調，才能將這些結果套用至所有實際情境。

導入作業

既然我們已經找到更好的延遲載入圖片方式，可以節省圖片用量並加快 LCP 效能，網站該如何開始使用呢？最優先的變更項目是向 WordPress 核心提交修補程式，以實作實驗性修正。我們也會更新「CMS 的瀏覽器層級延遲載入」網誌文章中的指南，說明不當延遲載入不需捲動位置內容的負面影響，以及 CMS 如何使用經驗法則避免這種情況。

由於這些最佳做法適用於所有網頁程式開發人員，因此在 Lighthouse 等工具中標記延遲載入反模式，也可能很有幫助。如果您想追蹤稽核進度，請參閱 GitHub 上的功能要求。在此之前，開發人員可以採取一項措施，找出 LCP 元素延遲載入的例項，那就是在欄位資料中加入更詳細的記錄。

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

上述 JavaScript 程式碼片段會評估最新的 LCP 元素，並在延遲載入時記錄警告。

這也凸顯了延遲載入技術的缺點，以及平台層級 API 改進的潛力。舉例來說，Chromium 有一個待解決的問題，就是實驗原生積極載入前幾張圖片，類似於修正，但有 loading 屬性。

結論

如果網站使用瀏覽器層級的圖片延遲載入功能，請檢查實作方式並執行 A/B 測試，進一步瞭解這項功能對成效的影響。如果能更積極載入不需捲動位置上方的圖片，或許能提升成效。如果您使用 WordPress 網站，WordPress 核心應該很快就會推出修補程式。如果您使用其他 CMS，請務必讓他們瞭解本文所述的潛在效能問題。

嘗試使用相對較新的網頁平台 API 可能會帶來風險和獎勵，因此稱為尖端功能。雖然我們開始瞭解瀏覽器層級圖片延遲載入的棘手之處，但也看到如何使用這項功能來提升效能。