Largest Contentful Paint (LCP)

Philip Walton
Barry Pollard

瀏覽器支援

  • Chrome：77。
  • Edge：79。
  • Firefox：122。
  • Safari：不支援。

資料來源

過去，網頁開發人員很難評估網頁的主要內容載入速度，以及使用者能看到的內容。舊版指標 (例如 load 或 DOMContentLoaded) 無法正常運作，因為這些指標不一定與使用者在螢幕上看到的內容相符。而較新的以使用者為中心的指標 (例如首次顯示內容所需時間 (FCP)) 只會擷取載入體驗的開頭。如果網頁顯示啟動畫面或載入指標，使用者就不會覺得這段時間與自己相關。

過去，我們曾建議使用 First Meaningful Paint (FMP) 和 Speed Index (SI) (兩者皆可在 Lighthouse 中使用) 等效能指標，以便在初始繪製後，進一步掌握載入體驗，但這些指標複雜且難以解釋，且經常出錯，也就是說，它們無法指出網頁的主要內容何時載入。

根據 W3C 網頁效能工作小組的討論和 Google 的研究，我們發現，要準確評估網頁主要內容的載入時間，最準確的方法是查看最大元素的算繪時間。

什麼是 LCP？

LCP 會回報可視區域中最大圖片、文字區塊或影片的顯示時間 (相對於使用者首次瀏覽至相應頁面的時間)。

良好的 LCP 分數應如何？

為了提供良好的使用者體驗，網站應力求最大內容繪製時間為 2.5 秒以下。為確保多數使用者都能享有此等級的體驗，建議您以第 75 個百分位數做為門檻，評估網頁載入情形，並區分行動裝置和電腦。

良好的 LCP 值為 2.5 秒以下，不良的值為 4.0 秒以上，介於兩者之間的值則需要改善
良好的 LCP 值為 2.5 秒以下。

系統會考量哪些元素？

如同目前在最大內容繪製 API 中所指定，以下是系統會視為最大內容繪製的元素類型：

請注意，我們刻意將元素限制在這個有限的集合中，以便在初期簡化操作。隨著研究的深入，我們日後可能會加入其他元素 (例如完整的 <svg> 支援)。

LCP 評估除了考量部分元素外，也會運用經驗法則，排除使用者可能會認為「沒有內容」的特定元素。以 Chromium 為基礎的瀏覽器包括：

  • 不透明度為 0 的元素，使用者看不到
  • 涵蓋整個檢視區塊的元素，可能會被視為背景而非內容
  • 預留位置圖片或其他熵值偏低的圖片，可能無法反映網頁的實際內容

瀏覽器可能會持續改善這些推測法，確保我們能滿足使用者對最大「含有內容」元素的期望。

這些「內容建議」經驗法則可能與首次顯示內容所需時間 (FCP) 所使用的不同，雖然會考慮上述部分元素，例如預留位置圖片或完整可視區域圖片 (即使這些圖片不符合 LCP 資格條件)。雖然兩者名稱中都使用「contentful」，但這些指標的目標不同。FCP 會評估任何內容繪製至螢幕的時間，而 LCP 會評估主要內容繪製的時間，因此 LCP 的用途更為精確。

元素大小的決定方式

系統為 LCP 回報的元素大小，通常是使用者在可視區域內可見的大小。如果元素超出可視區域，或者有任何元素遭到裁剪或出現不可見的溢位，這些部分就不會計入元素的大小。

如果圖片元素已從內在大小重新調整大小，則會回報的大小為可見大小或內在大小 (以較小者為準)。

如果是文字元素，LCP 只會考慮可包含所有文字節點的最小矩形。

對於所有元素，LCP 不會考量使用 CSS 套用的邊界、邊框或邊距。

系統何時會回報 LCP？

網頁通常會分階段載入，因此網頁上最大的元素可能會變更。

為處理這種可能的變更，瀏覽器會在繪製第一個影格後，立即調度 largest-contentful-paint 類型的 PerformanceEntry，以識別最大內容元素。但在轉譯後續影格後，只要內容元素最大的變更，就會分派另一個 PerformanceEntry。

舉例來說，在含有文字和主頁橫幅圖片的網頁上，瀏覽器一開始可能只會轉譯文字，此時會調度 largest-contentful-paint 項目，其 element 屬性可能會參照 <p> 或 <h1>。主頁橫幅載入完成後，系統會分派第二個 largest-contentful-paint 項目，其 element 屬性會參照 <img>。

元素只有在轉譯完成並可供使用者查看時，才能視為最大內容元素。尚未載入的圖片不會視為「算繪」圖片。在字型封鎖期間，兩者都不會使用網路字型。在這種情況下，較小的元素可能會被回報為最大內容元素，但只要較大的元素完成算繪，就會建立另一個 PerformanceEntry。

除了延遲載入的圖片和字型，網頁可能會在有新內容時，將新元素新增至 DOM。如果這些新元素的大小大於先前最大的內容元素，系統也會回報新的 PerformanceEntry。

如果從可視區域 (甚至 DOM) 中移除最大內容元素，除非算繪較大的元素，否則該元素仍會是最大的內容元素。

當使用者與網頁互動 (透過輕觸、捲動或按下按鍵) 後，瀏覽器就會停止回報新項目，因為使用者互動經常會改變使用者能夠看到的內容 (尤其是捲動網頁時的情況更是如此)。

為了進行分析，您應該只將最近一次調度的 PerformanceEntry 回報至 Analytics 服務。

載入時間與轉譯時間

基於安全性考量，如果跨來源圖片缺少 Timing-Allow-Origin 標頭，則不會顯示圖片的算繪時間戳記。反之，系統只會顯示載入時間 (因為許多其他網路 API 都已經公開該資訊)。

這可能會導致看似不可能的情況，也就是網頁 API 回報的 LCP 時間比 FCP 還早。雖然情況不同，但只會在有這項安全性限制的情況下出現。

建議盡可能設定 Timing-Allow-Origin 標頭，提升指標的準確度。

如何處理元素版面配置和大小的變更？

為降低計算及調度新成效項目的效能開銷，元素大小或位置的變更不會產生新的 LCP 候選項目。系統只會考量元素在可視區域中的初始大小和位置。

也就是說，一開始在畫面外算繪，然後在畫面上轉換的圖片可能不會回報。這也意味著元素一開始在可視區域顯示，然後被向下推，而在檢視區外，依然會報告其初始在可視區域內的大小。

範例

以下列舉幾個熱門網站的 Largest Contentful Paint 時間點：

cnn.com 的 Largest Contentful Paint 時間軸
cnn.com 的 LCP 時間軸。
techcrunch.com 的 Largest Contentful Paint 時間軸
techcrunch.com 的 LCP 時間軸。

在上述兩個時間軸中，最大的元素會隨著內容載入而變更。在第一個範例中，新內容會新增至 DOM，並變更哪個元素最大。在第二個範例中，版面配置會變更，且先前最大的內容會從可視區域中移除。

雖然晚載入的內容通常比網頁上已有的內容更大，但不一定是這樣。以下兩個範例顯示 LCP 發生在網頁完全載入前。

instagram.com 的最大內容繪製時間軸
instagram.com 的 LCP 時間軸。
google.com 上最大的內容繪製時間軸
google.com 的 LCP 時間軸。

在第一個範例中，Instagram 標誌的載入時間相對較早，即使其他內容不斷顯示，仍然會是最大的元素。在 Google 搜尋結果網頁的範例中，最大的元素是指圖片或標誌載入完成前顯示的一段文字，由於所有個別圖片都比這個段落小，因此在整個載入程序中，這個段落仍是最大的元素。

如何評估 LCP

您可以從研究室或實際操作中評估 LCP，以下工具也有提供這項指標：

欄位工具

實驗室工具

在 JavaScript 中評估 LCP

如要在 JavaScript 中評估 LCP，可以使用最大內容繪製 API。以下範例說明如何建立 PerformanceObserver，讓系統監聽 largest-contentful-paint 項目並將其記錄到控制台。

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

在上述範例中，每個記錄的 largest-contentful-paint 項目都代表目前的 LCP 候選項目。一般來說，最後一筆記錄的 startTime 值就是 LCP 值，但不一定是這樣。並非所有 largest-contentful-paint 項目都能用於評估 LCP。

下節將列出 API 回報內容和計算指標的方式之間的差異。

指標和 API 之間的差異

  • API 會為在背景分頁中載入的網頁調度 largest-contentful-paint 項目，但在計算 LCP 時，應忽略這些網頁。
  • API 會在網頁於背景運作後繼續分派 largest-contentful-paint 項目，但在計算 LCP 時，請忽略這些項目 (只有在網頁在整個前景中都處於前景時，才會考慮元素)。
  • 當網頁從前進/後退快取還原時，API 不會回報 largest-contentful-paint 項目，但在這種情況下，應測量 LCP，因為使用者會將這些情況視為不同的網頁瀏覽。
  • API 不會考量 iframe 中的元素，但指標會考量，因為這些元素是網頁使用者體驗的一部分。如果網頁在 iframe 中含有 LCP (例如內嵌影片的海報圖片)，則 CrUX 和 RUM 之間會出現差異。如要正確評估 LCP，請考慮使用這些指標。子影格可以使用 API 將 largest-contentful-paint 項目回報給父影格，以便匯總。
  • API 會從導覽開始時刻起測量 LCP，但對於預先轉譯的網頁，應從 activationStart 開始測量 LCP，因為這會對應到使用者體驗的 LCP 時間。

開發人員可以透過 web-vitals JavaScript 程式庫評估 LCP 差異，而與其記住這些細微差異，後者會盡可能為您處理這些差異 (請注意，不包含 iframe 的問題)：

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

如需在 JavaScript 中評估 LCP 的完整範例，請參閱 onLCP() 的原始碼。

如果最大的元素不是最重要的元素，該怎麼辦？

在某些情況下，網頁上最重要的元素 (或元素) 與最大的元素不同，開發人員可能更想評估這些其他元素的算繪時間。如要做到這點，您可以使用 Element Timing API，詳情請參閱自訂指標一文。

如何改善 LCP

我們提供最佳化 LCP 的完整指南，協助您瞭解如何在實地中找出 LCP 時間，並使用實驗室資料進行深入分析及最佳化。

其他資源

變更記錄

有時用於測量指標的 API 中會發現錯誤，有時在指標本身的定義中也會發現錯誤。因此，有時需要進行變更，這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。

為協助您管理這項情況，我們會在這個變更記錄中顯示這些指標的導入方式或定義所做的所有變更。

如果您對這些指標有任何意見，歡迎前往 web-vitals-feedback Google 群組提供意見。