過去，網頁程式開發人員必須評估網頁載入及向使用者顯示的主要內容的速度。舊版指標 (例如 load 或 DOMContentLoaded) 的運作並不理想，因為這些指標不一定對應使用者在畫面上看到的內容。以使用者為中心的新版成效指標 (例如首次顯示內容所需時間 (FCP)) 則只會記錄載入體驗的一開始。如果網頁顯示啟動畫面或顯示載入指標，表示此時間點與使用者的關聯性不高。
過去，我們建議使用首次有效繪製 (FMP) 和速度指數 (SI) (兩者皆在 Lighthouse 中取得) 等成效指標，以便更全面地掌握初始繪圖後的載入體驗，但這些指標不僅複雜、難以解釋，而且常常出錯，因此使用者還是無法辨識網頁的主要內容。
根據 W3C Web Performance Working Group 的討論，以及 Google 進行的研究，我們發現想要更準確地評估網頁載入主要內容的時間，就是觀察轉譯最大元素的時間。
LCP 是什麼？
LCP 會回報可視區域中最大圖片或文字區塊的轉譯時間 (相對於使用者首次造訪網頁的時間)。
LCP 分數代表什麼？
為了提供良好的使用者體驗，網站應力求在 2.5 秒以內。為確保大部分使用者都能達成這個目標，評估的理想門檻為 75 個百分位數，分別在行動裝置和電腦上劃分。
系統會考量哪些元素？
如同目前「Largest Contentful Paint API」所指定，考量的「最大內容繪製」元素類型如下：
<img>元素 (第一個影格顯示時間用於 GIF 或動畫 PNG 等動畫內容)<svg>元素中的<image>元素<video>元素 (使用影片的代表圖片載入時間或第一個影格顯示時間，以較早者為準)- 使用
url()函式 (而非 CSS 漸層) 載入的背景圖片元素 - 包含文字節點或其他內嵌層級文字元素子項的區塊層級元素。
請注意，我們刻意將元素限制在限定範圍內，以便從頭開始。日後我們還會進行更多研究，因此可能會新增其他元素 (例如完整的 <svg> 支援)。
除了考量部分元素外，LCP 評估作業也會利用經驗法則，排除使用者可能視為「無內容」的特定元素。以 Chromium 為基礎的瀏覽器包括：
- 透明度為 0 的元素，使用者看不到
- 覆蓋整個可視區域的元素，可能被視為背景而非內容
- 含有低熵長度的預留位置圖片或其他圖片，可能與網頁實際內容不符
瀏覽器可能會繼續改善這些經驗法則，確保使用者期望最大的內容元素。
這些「內容式」經驗法則可能與首次顯示內容繪製 (FCP) 使用的工具不同，後者可能會考慮部分元素，例如預留位置圖片或完整可視區域圖片，即使這些元素不符合 LCP 候選資格也一樣。雖然兩者的名稱中都使用「內容用途」，但這些指標鎖定的目標卻與以往大不相同。當繪製主要內容時，FCP 會評估任何內容顯示到螢幕和 LCP 的時機，以使 LCP 盡可能選擇性。
元素的大小決定方式為何？
LCP 回報的元素大小通常就是使用者在可視區域中可見的大小。如果元素超出可視區域，或是有任何元素遭到裁剪或含有未顯示的overflow，則這些部分不會計入元素的大小。
如果圖片元素沒有先自內在大小調整大小，回報的大小就是顯示大小或內建函式尺寸 (以較小者為準)。
以文字元素來說，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 至數據分析服務。
載入時間與轉譯時間
基於安全考量，如果跨來源圖片缺少 Timing-Allow-Origin 標頭，系統就不會公開圖片的轉譯時間戳記。而只會公開他們的載入時間 (因為此內容已透過許多其他網路 API 公開)。
這可能會導致看似不可能的情況，也就是網路 API 回報 LCP 低於 FCP。情況並非如此，只是因為有這項安全性限製而顯示出來。
建議您盡可能設定 Timing-Allow-Origin 標頭，以便提高指標的準確度。
系統如何處理元素版面配置和大小變更？
為維持計算及分派新效能項目時的效能負擔，變更元素的大小或位置時，不會產生新的 LCP 候選項目。系統只會考慮元素的初始大小和在可視區域中的位置。
也就是說，使用者最初算繪出畫面外的圖片，之後才在畫面上轉場，系統可能就不會回報。這也意味著元素一開始在可視區域內算繪，然後向外延伸，但向外顯示時，仍會回報初始檢視點的初始大小。
示例
以下舉例說明幾個熱門網站出現最大內容繪製的情況：
在上方兩個時間軸中，最大的元素會在內容載入時變更。在第一個範例中，新內容會新增至 DOM 並變更最大的元素。在第二個範例中，系統會從可視區域中移除先前最大的版面配置變更和先前最大的內容。
儘管延遲載入的內容比網頁上的現有內容還要大，但不一定是如此。接下來兩個例子顯示網頁完全載入前發生的 LCP。
在第一個示例中，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，你必須考量這些資訊。子頁框可以使用 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 時間，以及運用研究室資料深入鑽研及最佳化。
其他資源
- 「Chrome 效能監控」 由 Annie Sullivan performance.now() (2019) 示範
變更記錄
有時候，我們在測量指標的 API 中會發現錯誤，有時則在指標本身定義中發現錯誤。因此，有時仍須做出變更，而這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。
為協助您管理，這些指標的導入或定義的所有變更，都會顯示在這份變更記錄中。
如果您對這些指標有任何意見，可以前往 web-vitals-feedback Google 群組提出。