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 的元素，使用者看不到
  • 涵蓋整個檢視區塊的元素，可能會被視為背景而非內容
  • 預留位置圖片或其他含有較低熵的圖片，但可能無法反映網頁的實際內容

瀏覽器可能會繼續改進這些經驗法則，確保我們符合使用者對於最大 contentful 元素的期望。

這些「內容」經驗法則可能與首次顯示內容所需時間 (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 提供的最大內容繪製時間表
cnn.com 提供的 LCP 時間軸。
techcrunch.com 的 Largest Contentful Paint 時間軸
techcrunch.com 的 LCP 時間軸。

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

雖然延遲載入內容通常比網頁上現有的內容更大，但實際上並不一定是如此。接下來的兩個例子呈現了 LCP 在網頁完全載入前發生的情況。

instagram.com 的 Largest Contentful Paint 時間軸
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，但針對預先算繪的網頁的 LCP 應從 activationStart 評估，因為後者會對應到使用者完成的 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 群組提供意見。