延遲載入過多會導致效能影響

考量到網站體驗核心指標，針對延遲載入圖片提供資料導向建議。

Felix Arntz

Rick Viscomi

延遲載入是一種技術，可將下載資源延後到需要時再下載，藉此節省資料並減少重要資產的網路爭用情形。這項工具在 2019 年成為網路標準，目前多數主要瀏覽器都支援圖片的 loading="lazy"。聽起來不錯，但 是否有些延遲會載入太慢？

本文總結了我們如何分析公開的網路透明度資料和臨時 A/B 測試，從而瞭解原生圖片延遲載入的採用率和效能特性。我們發現，延遲載入對於減少不必要的圖片位元組來說是非常有效的工具，但過度使用則會對效能造成負面影響。簡而言之，我們的分析顯示，如果加快在初始可視區域內載入圖片 (而嚴重延遲載入其餘圖片)，可以提供這兩種選擇的最佳效果：減少載入的位元組數，並改善 Core Web Vitals。

採用率

根據 HTTP 封存檔的最新資料，17% 的網站使用原生圖片延遲載入，而且採用率正在迅速成長。生態系統中大部分的據點 對於較新的 API 十分重要

在 HTTP Archive 專案中查詢原始資料，有助於我們進一步瞭解哪種類型的網站是採用 WordPress：使用原生圖片延遲載入功能的網站有 84% 使用 WordPress，其餘 14% 則未使用已知的 CMS。這些結果清楚呈現了 WordPress 如何領先業界採用。

此外，採用率也值得注意。2020 年 7 月前，使用延遲載入的 WordPress 網站在語料庫中有數萬個網站，約有 600 萬個網站 (佔總數的 1%)。光是在 WordPress 中採用延遲載入功能，就已經成長至超過 100 萬個網站 (佔總數的 14%)。

關聯成效

深入探索 HTTP 封存內容，我們可以透過「最大內容繪製」(LCP) 指標比較使用及不含原生圖片延遲載入的網頁效能。LCP 資料來自 Chrome 使用者體驗報告 (CrUX) 的實際使用者體驗，而非研究室的綜合測試。下方圖表使用盒子圖，以視覺化方式呈現各網頁的第 75 個百分位數的分佈情形：線條代表第 10 和第 90 個百分位數，方塊代表第 25 和第 75 個百分位數。

在沒有延遲載入的情況下，中位數網頁的 LCP 為 2,922 毫秒，而延遲載入的中位數頁面為 3,546 毫秒。整體而言，使用延遲載入的網站通常較差的 LCP 效能。

請特別注意，這些結果是「關聯」結果，不一定代表延遲載入是效能緩慢的「原因」。假設 WordPress 網站速度較慢，且在考量延遲載入同類群組的比例下，可說明兩者間的差異。為了消除這項差異，我們現在只看 WordPress 網站。

不幸的是，我們深入細查 WordPress 頁面時，也會出現相同的模式；使用延遲載入的網頁通常其 LCP 效能通常較低。沒有延遲載入的 WordPress 網頁中位數為 75 個百分位數，LCP 為 3,495 毫秒，而延遲載入網頁的中位數為 3,768 毫秒。

這仍然不代表延遲載入「造成」網頁載入速度變慢，但使用這種模式會一併降低效能。為回答因果問題，我們設定了研究室式 A/B 測試。

因果成效

A/B 測試的目標，在於證明或推翻原生圖片延遲載入的假設，也就是在 WordPress 核心中實作時，導致 LCP 效能變慢、圖片位元組更少。我們原先採用的方法是測試具有 2entytwentyone 主題的示範 WordPress 網站。我們針對電腦和行動裝置，使用 WebPageTest 測試封存和單一網頁類型 (例如首頁和文章頁面)。針對啟用和未啟用延遲載入功能的網頁組合，我們測試了各個網頁組合，並分別執行每項測試九次，取得圖片位元組數中位數和圖片位元組數。

以上結果比較封存測試以及電腦版與行動版單一網頁的測試 LCP (以毫秒為單位)。停用封存頁面的延遲載入功能後，我們發現 LCP 大幅改善了邊界。但在單一網頁上，差異顯得較為普通。

值得注意的是，停用延遲載入功能實際上會讓單一頁面的速度稍微加快。不過，LCP 與電腦和行動裝置測試的差異只有一項標準差，因此我們會將這項差異歸因於變異數，並將整體變更視為中立情況。相較之下，封存網頁的差異在於二到三個標準差。

上述結果比較每項測試的圖片位元組數中位數 (以 KB 為單位)。正如預期，延遲載入對於減少圖片位元組數量有非常正面的影響。假使使用者已經向下捲動整個網頁，所有圖片都會在跨越可視區域時繼續載入，但這些結果顯示，初次載入網頁時的效能將有所提升。

總結 A/B 測試結果時，WordPress 採用的延遲載入技術顯然有助於減少圖片位元組，但會導致 LCP 延遲。

測試修正項目

深入探討修正實作方式前，先來看看 WordPress 目前的延遲載入功能如何運作。目前實作的重點，就是將圖片延遲載入不需捲動位置 (位於可視區域內) 的圖片。CMS 網誌文章確認這是避免使用的模式，但當時的實驗資料顯示，在 WordPress 核心中的影響最小且值得簡化實作。

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

這些結果更令人信服。延遲載入位於需捲動位置的圖片會導致 LCP 迴歸完全復原，甚至在完全停用 LCP 時也可能會略有「改善」。相較於延遲載入，載入速度是怎麼辦到的？其中一個解釋是，不載入需捲動位置的圖片，就能減少 LCP 圖片的網路爭用情況，進而加快載入速度。

就圖片位元組而言，相較於預設行為，修正絕對沒有變化。這種做法很棒，因為這是目前做法的一部分。

這項修正有一些注意事項。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 可能會帶來風險和回報，因此稱為先進的功能。雖然我們開始瞭解原生圖片延遲載入的實用性，但我們也在發現如何善用這項功能來提高效能。

相片來源：Frankie Lopez 於 Unsplash 網站上