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 分數？

為了提供良好的使用者體驗，網站應力求 Largest Contentful Paint 為 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 的 Largest Contentful Paint 時間軸
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 時間，並使用實驗室資料深入分析及改善 LCP。

其他資源

變更記錄

有時，我們會在用於評估指標的 API 中發現錯誤，有時也會在指標定義中發現錯誤。因此，有時必須進行變更，這些變更可能會在內部報表和資訊主頁中顯示為改善或回歸。

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

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