最大內容繪製 (LCP) 是穩定的核心網站體驗指標，用於評估感知載入速度。它會在網頁載入時間軸中，標示網頁主要內容可能載入時的時間點。快速的 LCP 有助於讓使用者確認該網頁實用。
過去，網頁程式開發人員難以評估網頁載入及向使用者顯示的主要內容的速度。load 或 DOMContentLoaded 等舊指標的運作可能不太理想，因為這些指標不一定對應使用者在畫面上看到的內容。以使用者為中心的較新成效指標 (例如首次顯示內容所需時間 (FCP)) 則只會擷取載入體驗的最開始處。如果網頁顯示啟動畫面或顯示載入指標，那麼此時間點與使用者的關聯性並不高。
過去，我們推薦的成效指標包括首次繪製所需時間 (FMP) 和速度指數 (SI) (兩者皆在 Lighthouse 中提供)，以協助在初始繪製後擷取更多載入體驗，但這些指標非常複雜、難以解釋且通常發生錯誤，這代表使用者仍無法識別網頁主要內容何時載入。
根據 W3C Web Performance Working Group 的討論以及 Google 的研究，我們發現想要更準確地評估載入頁面主要內容的時間，就是觀察轉譯最大元素的時間。
LCP 是什麼？
LCP 會回報可視區域中最大圖片或文字區塊的轉譯時間 (相對於使用者首次瀏覽至網頁的時間)。
LCP 分數代表什麼？
為提供良好的使用者體驗，網站應力求在 2.5 秒內達到 LCP。為確保大部分使用者都能達成這個目標，評估的理想門檻是網頁載入第 75 個百分位數，並在行動裝置和電腦上區隔。
系統會考量哪些元素？
如 Largest Contentful Paint API 已指定，會考量最大內容繪製的元素類型為：
<img>元素 (第一個影格顯示時間用於 GIF 或動畫 PNG 等動畫內容)<svg>元素中的<image>元素<video>元素 (使用影片的代表圖片載入時間或第一個影格顯示時間，以較早者為準)- 使用
url()函式 (而非 CSS 漸層) 載入的背景圖片元素 - 包含文字節點或其他內嵌層級文字元素子項的區塊層級元素。
將元素限制在這類限制集的目的是為了降低複雜度。日後可能會因為進行更多研究，而新增其他元素 (例如完整的 <svg> 支援)。
除了考量部分元素外，LCP 評估作業也會利用經驗法則，排除使用者可能看為「無內容」的特定元素。以 Chromium 為基礎的瀏覽器包括：
- 透明度為 0 的元素，會讓使用者看不到這些元素。
- 覆蓋整個可視區域的元素，這些元素可能是背景元素。
- 帶有低熵幹擾的預留位置圖片或其他圖片，可能不符合網頁的實際內容。
瀏覽器可能會繼續改善這些經驗法則，確保使用者期待最大的「內容」元素。
這些「內容式」經驗法則與 FCP 使用的工具不同，FCP 可能會考慮部分元素，例如預留位置圖片或完整可視區域圖片，即使這些元素不符合 LCP 候選資格也一樣。雖然兩者在名稱中使用「內容用途」一詞，但這些指標的目標並不一樣。FCP 會評估任何內容顯示在螢幕上的時間，而 LCP 則會測量主要內容的顯示時機。
元素的大小決定方式為何？
LCP 回報的元素大小通常就是使用者在可視區域中可見的大小。如果元素超出可視區域範圍，或是有任何元素遭到裁剪或含有未顯示的overflow，則這些部分不會計入元素的大小。
如果圖片元素已由內在尺寸調整大小，回報的尺寸就是顯示大小或內建函式尺寸 (以較小者為準)。
以文字元素來說，LCP 只會考量可包含所有文字節點的最小矩形。
對於所有元素，LCP 不會考量使用 CSS 套用的邊界、邊框間距或邊框。
何時會回報 LCP？
網頁通常會分階段載入，因此網頁中最大的元素可能會在載入期間發生變化。
為了處理這項潛在變更，瀏覽器會在瀏覽器繪製第一個影格時，分派 largest-contentful-paint 類型的 PerformanceEntry，找出最大內容元素。算繪後續影格後，每當最大內容元素變更時，就會分派另一個 PerformanceEntry。
舉例來說，在含有文字和主頁橫幅的頁面上，瀏覽器一開始可能只會顯示文字，而瀏覽器會調度 largest-contentful-paint 項目，其 element 屬性參照 <p> 或 <h1>。主頁橫幅載入完畢後，系統會分派第二個 largest-contentful-paint 項目，並具有參照 <img> 的 element 屬性。
元素算繪並向使用者顯示後，才能視為最大的內容有元素。尚未載入的圖片不會視為「算繪」。在字型區塊期間，兩者都不是使用網路字型的文字節點。在這種情況下，系統可能會將較小的元素回報為最大內容元素，但只要較大的元素完成算繪，就會建立另一個 PerformanceEntry。
除了延遲載入圖片和字型以外，網頁可能會在新內容出現時，在 DOM 中加入新元素。如果任何新元素大於先前最大的內容元素，系統就會建立新的 PerformanceEntry。
如果從可視區域中移除最大內容元素，甚至是從 DOM 中移除，除非算繪較大的元素，否則仍是最大的內容元素。
使用者與網頁互動 (透過輕觸、捲動或按鍵) 時，瀏覽器會停止回報新項目，因為使用者互動往往會變更向使用者顯示的內容 (尤其是捲動畫面時)。
為了進行分析，請只回報最近調度的 PerformanceEntry 至數據分析服務。
載入時間與轉譯時間
基於安全考量，沒有 Timing-Allow-Origin 標頭的跨來源映像檔不會公開圖片的轉譯時間戳記。而僅提供其他 API 已公開的載入時間。
這可能會導致看似不可能的情況，也就是網路 API 回報 LCP 比 FCP 更早的資料。這只是因為這項安全性限制，不代表實際情況。
建議您盡可能設定 Timing-Allow-Origin 標頭，提高指標的準確度。
系統如何處理元素版面配置和大小變更？
為了讓計算及分派新效能項目時保持低的效能負擔，變更元素的大小或位置不會產生新的 LCP 候選項目。系統只會考量元素的初始大小和在可視區域中的位置。
也就是說，使用者最初在畫面外轉譯，然後在畫面上轉換的圖片，可能不會回報。這也意味著元素初次在可視區域中算繪後，會先從可視區域中轉譯，然後向外推入，仍會回報初始的可視區域大小。
示例
以下舉例說明幾個熱門網站何時出現最大內容繪製：
在這兩種時間軸中，最大的元素 (以綠色醒目顯示) 會在內容載入時變更。在第一個範例中，系統會在 DOM 中加入新內容，變更最大的元素。在第二個範例中，版面配置有所變更，從可視區域中移除上一個最大內容元素。
雖然延遲載入的內容通常比網頁上現有的內容還要大，但不一定是如此。接下來兩個例子顯示頁面完全載入前發生的 LCP
在第一個範例中，Instagram 標誌的載入速度較快，且即使加入其他內容，Instagram 標誌仍是最大的元素。在 Google 搜尋結果網頁範例中，最大的元素是一組文字，會在任何圖片或標誌載入完成前顯示。由於每張個別圖片都會小於這個段落，因此在整個載入程序中仍是最大的元素。
如何評估 LCP
您可以在研究室或實際領域測量 LCP，可以透過下列工具進行評估：
現場工具
研究室工具
評估 JavaScript 中的 LCP
如要測量 JavaScript 中的 LCP，請使用 Largest Contentful Paint 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，您必須加入 iframe。子頁框可以使用 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 時間，以及運用研究室資料深入鑽研及最佳化。
其他資源
- 「Chrome 效能監控」 由 Annie Sullivan performance.now() (2019) 示範
變更記錄
有時候，我們在測量指標的 API 中會發現錯誤，有時也會在指標本身定義中發現錯誤。因此，有時確實需要進行變更，而這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。
為協助您管理，這些指標的導入或定義的所有變更，都會顯示在這份變更記錄中。
如果您有這些指標的意見回饋，請透過 web-vitals-feedback Google 群組提出。