逐步指南：如何分析 LCP 並找出需要改善的重點領域。
發布日期：2020 年 4 月 30 日
最大內容繪製 (LCP) 是三項網站使用體驗核心指標之一，代表網頁主要內容的載入速度。具體來說，LCP 會評估使用者開始載入網頁，直到在可視區域中顯示最大圖片或文字區塊所需的時間。
為了提供良好的使用者體驗，網站應力求達到 2.5 秒或更短的 LCP 時間，至少佔 75% 的頁面造訪次數。
許多因素都會影響瀏覽器載入及轉譯網頁的速度，而任何因素的延遲都可能對 LCP 造成重大影響。
只修改單一網頁的某個部分，通常無法有效改善 LCP。為了改善 LCP，您必須查看整個載入程序，並確保過程中的每個步驟都最佳化。
瞭解 LCP 指標
最佳化 LCP 前，開發人員應想要瞭解是否有 LCP 問題以及這類問題的嚴重程度。
您可以使用多種工具評估 LCP，但並非所有工具都以相同方式評估 LCP。如要瞭解實際使用者的 LCP，我們應觀察實際使用者體驗，而非 Lighthouse 或本機測試等實驗室工具顯示的結果。這些實驗室工具可提供豐富資訊，協助您瞭解並改善 LCP，但請注意，實驗室測試可能無法完全代表實際使用者體驗。
您可以透過在網站上安裝的實際使用者監控 (RUM) 工具，或使用 Chrome 使用者體驗報告 (CrUX)，收集來自數百萬個網站的實際 Chrome 使用者匿名資料，以顯示以實際使用者為依據的 LCP 資料。
使用 PageSpeed Insights CrUX LCP 資料
您可以透過 PageSpeed Insights 存取 CrUX 資料位於頂端的「瞭解實際使用者體驗」部分。如要查看更詳細的研究資料，請前往標示為「診斷效能問題」的底部區段。如果網站有 CrUX 資料，請務必優先著重於實際使用者資料。
PageSpeed Insights 最多會顯示四種不同的 CrUX 資料：
- 這個網址的行動資料
- 這個網址的電腦版資料
- 整個來源的行動資料
- 整個來源的電腦資料
您可以在這個部分頂端和右上方的控制項中切換這些設定。如果網址沒有足夠資料 (可在網址層級顯示)，但其中確實有來源的資料，PageSpeed Insights 一律會顯示來源資料。
整個來源的 LCP 可能與個別網頁的 LCP 非常不同，這取決於該網頁的 LCP 載入方式，以及與該來源的其他網頁相比。訪客瀏覽這些網頁的方式也可能受到影響。首頁往往會被新使用者瀏覽，因此通常載入「冷」、沒有快取內容，因此通常是網站上速度最慢的網頁。
查看四種不同類別的 CrUX 資料，有助於瞭解 LCP 問題是特定於這個網頁，還是更普遍的網站問題。同樣地，這項指標也能顯示哪些裝置類型有 LCP 問題。
使用 PageSpeed Insights CrUX 輔助指標
如果要最佳化 LCP，也應採用「首次顯示內容所需時間 (FCP)」和「首次位元組時間 (TTFB)」時間，這兩項實用的診斷指標，有助於深入瞭解 LCP。
TTFB 是指從訪客開始前往網頁 (例如點選連結) 到接收 HTML 文件的首個位元組之間的時間。TTFB 值過高，可能會導致 LCP 達到 2.5 秒的目標變得困難，甚至無法達標。
TTFB 值偏高可能是因為伺服器重新導向次數過多、訪客位於離最近網站伺服器很遠的地方、網路連線品質不佳，或是因查詢參數而無法使用快取內容。
頁面開始轉譯後，畫面會先套用初始所需時間 (例如背景顏色)，之後可能會出現一些內容 (例如網站標題)。初始內容的顯示時間可透過 FCP 測量。FCP 與其他指標之間的差異可能非常明顯。
TTFB 和 FCP 之間的差異值越大，就表示瀏覽器需要下載大量會阻斷轉譯的素材資源。這也可能是網站必須完成大量工作才能顯示任何有意義的內容的徵兆，而這正是網站過度依賴用戶端端算繪製的典型徵兆。
FCP 和 LCP 之間的差距很大，表示瀏覽器無法立即取得 LCP 資源做為優先處理順序 (例如由 JavaScript 管理，而非提供初始 HTML 中之文字或圖片)，或者瀏覽器在顯示 LCP 內容之前，會先完成其他工作。
使用 PageSpeed Insights Lighthouse 資料
PageSpeed Insights 的 Lighthouse 部分提供了改善 LCP 的指南，但請先檢查你提供的 LCP 是否與 CrUX 提供的實際使用者資料一致。如果 Lighthouse 和 CrUX 不同意，CrUX 可能可以提供更準確的使用者體驗。請先確認 CrUX 資料是針對網頁 (而非完整來源) 收集，再採取行動。
如果 Lighthouse 和 CrUX 皆顯示需要改善的 LCP 值，Lighthouse 區段提供的指引能幫助您改善 LCP。使用 LCP 篩選器即可只顯示與 LCP 相關的稽核項目，方法如下：
除了改善的「商機」部分，您還可以查看「診斷」資訊，提供更多有助於診斷問題的資訊。「最大內容繪製元素」診斷工具會顯示 LCP 的各個時間點，並提供詳細資料：
我們將在下文深入探討這些子部分。
LCP 詳細資料
如果 PageSpeed Insights 無法讓您瞭解如何改善這項指標，進行 LCP 最佳化作業可能會較為複雜。對於複雜的工作，通常最好是分成較小型且易於管理的任務，然後逐一解決。
本節將說明如何將 LCP 細分為最關鍵的子部分，然後提供具體最佳化建議和最佳做法，說明如何最佳化各個部分。
大多數的網頁載入通常會包含多個網路要求，但為了找出改善 LCP 的機會，您應該先從兩個方面著手：
- 初始 HTML 文件
- LCP 資源 (如適用)
雖然網頁上的其他要求可能會影響 LCP，但這兩項要求 (特別是 LCP 資源開始和結束的時間) 會顯示網頁是否已針對 LCP 進行最佳化。
如要找出 LCP 資源，可以使用開發人員工具 (例如先前介紹的 PageSpeed Insights、Chrome 開發人員工具 或 WebPageTest) 判斷 LCP 元素。接著，您可以比對元素在網頁載入的所有資源網路階層中載入的網址 (如果適用的話)。
舉例來說，下圖以視覺化方式呈現這些資源，並在典型的網頁載入網路階層圖表中加以標示，其中 LCP 元素需要圖片要求才能算繪。
對於經過妥善最佳化的網頁，您希望 LCP 資源要求能盡早開始載入，並在 LCP 資源載入完成後，盡快算繪 LCP 元素。如要將特定網頁是否遵循這項原則，以圖表呈現，您可以將 LCP 總時間細分為下列子部分：
- 首次位元組時間 (TTFB)
- 從使用者開始載入網頁，到瀏覽器接收 HTML 文件回應的第一個位元組所需的時間。
- 資源載入延遲
- TTFB 與瀏覽器開始載入 LCP 資源之間的時間。如果 LCP 元素不需要資源載入作業即可顯示 (例如，如果元素是使用系統字型顯示的文字節點)，這個時間就會是 0。
- 資源載入時長
- 載入 LCP 資源本身所需的時間。如果 LCP 元素不需要資源載入才能算繪，這個時間就會是 0。
- 元素轉譯延遲
- 從 LCP 資源完成載入到 LCP 元素完全算繪的時間。
每個網頁的 LCP 都包含這四個子類別。兩者沒有差異或重疊 而且加總起來就是整個 LCP 時間
每個網頁的 LCP 值都可以細分為這四個子部分。兩者之間沒有重疊或空隙。兩者加總起來，等於整個 LCP 時間。
最佳化 LCP 時，建議您逐一最佳化這些子部分。不過請注意，您必須最佳化所有這些項目。在某些情況下，套用到某個部分的最佳化功能並不能改善 LCP，只會將省下的時間轉移至其他部分。
舉例來說，在先前的網路刊登序列中，如果您透過進一步壓縮圖片來縮減檔案大小，或是改用更好的格式 (例如 AVIF 或 WebP)，可縮短資源載入時間，但實際上不會改善 LCP，因為時間只會轉移至「元素轉譯延遲時間」子部分：
發生這種情況的原因是，在這個網頁上，JavaScript 程式碼載入完成前，LCP 元素會處於隱藏狀態，然後才會一次顯示所有內容。
這個例子說明您需要在哪些方面調整出最佳狀態，才能達到最佳的 LCP 效果。
最佳子部分時間
為了最佳化 LCP 的各個子部分，請務必瞭解這些子部分在經過妥善最佳化的網頁中，理想的細目為何。
在四個子部分中，有兩個名稱含有「delay」一詞。也就是說，您希望這些時間盡可能接近零。其他兩個部分是網路要求，由於其本質相當耗時。
請注意，這些時間分配只是參考準則，並非嚴格規定。如果網頁的 LCP 時間一律在 2.5 秒內，相對比例為何並不重要。不過，如果您在「延遲」部分花費大量不必要的時間，就很難持續達到 2.5 秒的目標。
如要瞭解 LCP 時間的細目資料，不妨參考以下說明：
- 絕大部分 LCP 時間都應花在載入 HTML 文件和 LCP 來源。
- 在 LCP 之前，如果這兩種資源有任何一項未載入，就是改善的機會。
如何改善各個層面
現在您已經瞭解每個 LCP 子部分在經過最佳化調整後應該如何進行細分，接下來就可以開始最佳化自己的網頁。
接下來的四節將針對各個環節提供最佳化的建議和最佳做法。系統會按照順序，由最有可能影響成效的最佳化著手。
1. 消除資源載入延遲
這個步驟的目標是確保 LCP 資源盡早開始載入。雖然理論上資源可能在 TTFB 後立即開始載入，但實際上瀏覽器實際開始載入資源時，總會有些延遲。
一般來說，LCP 資源應與該網頁載入的第一個資源同時開始載入。換句話說，如果 LCP 資源的載入時間比第一個資源晚，就表示有改善的空間。
一般而言，影響 LCP 資源的載入速度會受以下兩個因素影響：
- 發現資源時。
- 資源的優先順序。
找到資源時進行最佳化
為確保 LCP 資源盡早開始載入，瀏覽器的預先載入掃描器必須能在初始 HTML 文件回應中發現該資源。例如，在下列情況中，瀏覽器可以掃描 HTML 文件回應，找出 LCP 資源：
- LCP 元素是
<img>元素，其src或srcset屬性會出現在初始 HTML 標記中。 - LCP 元素需要使用 CSS 背景圖片，但該圖片是透過 HTML 標記中的
<link rel="preload">(或利用Link標頭) 預先載入。 - LCP 元素是需要網頁字型才能算繪的文字節點，而字型會在 HTML 標記中使用
<link rel="preload">(或使用Link標頭) 載入。
以下列舉幾個無法透過掃描 HTML 文件回應來偵測 LCP 資源的例子：
- LCP 元素是使用 JavaScript 以動態方式新增至網頁的
<img>。 - LCP 元素會透過 JavaScript 程式庫延遲載入，該程式庫會隱藏
src或srcset屬性 (通常為data-src或data-srcset)。 - LCP 元素需要 CSS 背景圖片。
在上述每個情況中，瀏覽器都需要執行指令碼或套用樣式表，這通常會涉及等待網路要求完成，才能發現 LCP 資源並開始載入。這絕非最佳做法。
為避免不必要的資源載入延遲，LCP 資源應可從 HTML 來源中找到。如果資源僅從外部 CSS 或 JavaScript 檔案參照，則應以高擷取優先順序預先載入 LCP 資源，例如：
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
最佳化資源的優先順序
即使 LCP 資源可從 HTML 標記中偵測，但「仍可能」比第一個資源晚載入。如果瀏覽器預先載入掃描器的優先順序分析法未將資源視為重要，或是判斷其他資源更重要，就可能發生這種情況。
舉例來說，如果您在 <img> 元素上設定 loading="lazy"，即可使用 HTML 延遲 LCP 圖片。使用延遲載入表示，等到版面配置確認圖片位於可視區域後，才會載入資源，因此可能之後才開始載入。
即使沒有延遲載入，瀏覽器也不會以最高優先順序載入圖片，因為圖片並不會阻斷轉譯。您可以使用 fetchpriority 屬性，為瀏覽器提供提示，指出哪些資源最重要，以便瀏覽器為優先順序較高的資源提供優先權：
<img fetchpriority="high" src="/path/to/hero-image.webp">
如果你認為網頁 LCP 元素很有可能是網頁的 LCP 元素，建議在 <img> 元素上設定 fetchpriority="high"。不過，如果為一或兩張以上的圖片設定高優先順序，優先順序設定就無法有效降低 LCP。
您也可以降低在文件回應初期，但因樣式而看不到的圖片 (例如啟動時未顯示的輪轉介面投影片中的圖片)，降低優先順序。
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
將特定資源降級，可為更需要頻寬的資源提供更多頻寬，但請小心使用。請務必在開發人員工具中檢查資源優先順序，並使用實驗室和實地工具測試變更。
最佳化 LCP 資源優先順序和探索時間後，網路刊登序列應如下所示 (其中 LCP 資源會與第一個資源同時開始)：
2. 消除元素轉譯延遲
這個步驟的目標是確保 LCP 元素在資源完成載入後「立即」顯示，無論發生情況為何。
LCP 元素在資源載入完畢後無法立即顯示的主要原因，是因為轉換作業遭到其他原因封鎖：
- 由於
<head>中的樣式表或同步指令碼仍在載入，因此系統無法轉譯整個網頁。 - LCP 資源已載入完成，但 LCP 元素尚未加入 DOM (正在等待載入某些 JavaScript 程式碼)。
- 其他程式碼隱藏了元素，例如 A/B 測試程式庫仍在決定使用者應進入的實驗。
- 主執行緒因長時間工作而遭到封鎖，轉譯工作必須等到這些長時間工作完成後才能執行。
下列各節說明如何解決造成不必要元素算繪延遲的最常見原因。
減少或內嵌禁止轉譯的樣式表
從 HTML 標記載入的樣式表，會讓所有後續內容無法顯示，這是很好的選擇，因為您通常不想轉譯未經樣式的 HTML。不過，如果樣式表太大，載入時間遠比 LCP 資源長，則會在資源完成載入之後，防止 LCP 元素算繪，如以下範例所示：
如要解決這個問題，您可以採用下列任一做法：
- 將樣式表單內嵌至 HTML 中，避免額外的網路要求；或
- 縮減樣式表的大小
一般來說，我們並不建議在樣式表中添加小型檔案的情況下，才建議嵌入樣式表，因為 HTML 中的內嵌內容無法透過後續載入的網頁進行快取。如果樣式表單的載入時間比 LCP 資源更長，就不太可能適合內嵌。
在大多數情況下，要確保樣式表不會阻礙 LCP 元素轉譯，最好的方式就是縮減其大小，使其小於 LCP 資源。這麼做應該可以確保這項服務不會成為大多數造訪的瓶頸。
以下是有助於縮減樣式表大小的建議：
- 移除未使用的 CSS：使用 Chrome 開發人員工具找出未使用的 CSS 規則，這些規則可能會遭到移除 (或已延遲)。
- 延後非必要的 CSS：將樣式表分割成初始網頁載入作業所需的樣式，以及可延後載入的樣式。
- 壓縮及壓縮 CSS：對於重要的樣式，請盡可能縮減傳輸大小。
延後或內嵌會阻礙轉譯的 JavaScript
在網頁的 <head> 中加入同步指令碼 (不含 async 或 defer 屬性的指令碼) 幾乎不見得需要，這麼做幾乎對成效造成負面影響。
如果 JavaScript 程式碼必須在網頁載入時盡早執行，建議您以內嵌的方式內嵌，以免轉譯程序因為出現其他網路要求而延遲。不過，與樣式表單一樣，您應該只在程式碼很小時才內嵌。
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>
使用伺服器端轉譯
伺服器端轉譯 (SSR) 是指在伺服器上執行用戶端應用程式邏輯，並使用完整 HTML 標記回應 HTML 文件要求的程序。
就最佳化 LCP 而言，SSR 主要有兩項優點：
- 使用者可以從 HTML 來源找到圖片資源 (如前文步驟 1 所述)。
- 網頁內容不需要額外的 JavaScript 要求才能算完成，即可顯示。
SSR 的主要缺點是需要額外的伺服器處理時間，可能會拖慢 TTFB。權衡取捨通常值得，因為伺服器處理時間完全由您掌控，但使用者的網路和裝置功能則並非如此。
與 SSR 類似的選項稱為靜態網站產生 (SSG) 或預先算繪。透過這個程序，您可以在建構步驟 (而非隨選) 中產生 HTML 網頁。如果您的架構可以進行預先算繪，那麼效能通常會是更好的選擇。
分散長時間執行的工作
即使您已遵循上述的建議，且您的 JavaScript 程式碼並未阻擋轉譯，也不是負責轉譯元素，還是可能會延遲 LCP。
發生這種情況最常見的原因，是網頁載入大型 JavaScript 檔案，而這些檔案需要在瀏覽器的主要執行緒上進行剖析及執行。也就是說，即使圖片資源已完全下載，仍可能需要等待不相關的指令碼執行完畢，才能進行轉譯。
目前，所有瀏覽器都會在主執行緒上轉譯圖片，也就是說，任何妨礙主執行緒的內容，都可能產生不必要的元素轉譯延遲。
3. 縮短資源載入時間
這個步驟的目標是縮短透過網路將資源位元組傳輸至使用者裝置所需的時間。一般而言，使用者可採用下列三種方式：
- 縮減資源大小。
- 減少資源行進的距離。
- 減少網路頻寬的爭用情形。
- 完全消除網路時間。
縮減資源大小
網頁的 LCP 資源 (如果有) 會是圖片或網路字型。下列指南詳細說明如何縮減兩者的大小：
減少資源傳輸的距離
除了縮減資源大小，您也可以盡可能讓伺服器靠近使用者所在的區域，藉此縮短載入時間。最佳做法是使用內容傳遞網路 (CDN)。
圖片 CDN 特別實用，因為它不僅可縮短資源傳輸的距離，還能縮減資源大小，自動為您實作先前提到的所有縮減大小建議。
減少網路頻寬的爭用情形
即使您同時縮減資源大小及所需的移動距離，但如果您同時載入許多其他資源，資源仍可能需要較長的處理時間。這種問題稱為網路爭用。
如果您為 LCP 資源指定了高 fetchpriority，並盡快開始載入，瀏覽器會盡力避免優先順序較低的資源與之競爭。不過，如果載入許多具有較高 fetchpriority 的資源，或一般只是載入大量資源，可能會影響 LCP 資源載入的速度。
完全省去網路時間
縮短資源載入時間的最佳方式，就是完全將網路從處理程序中刪除。如果您為資源設定了高效率的快取控制政策，第二次要求這些資源的訪客會從快取提供資源，將資源載入時間縮短為零！
如果 LCP 資源是網路字型，除了縮減網路字型大小，您也應考慮是否需要在網路字型資源載入時阻擋轉譯作業。如果您設定的 font-display 值不是 auto 或 block，則文字會在載入期間一律顯示，且 LCP 不會因額外網路要求而遭到封鎖。
最後，如果 LCP 資源很小，建議您將資源內嵌為 資料網址，這樣一來也可以消除額外的網路要求。不過，使用資料網址有其限制，因為這樣就無法快取資源，且在某些情況下，由於額外的解碼成本，可能會導致顯示時間延遲。
4. 縮短第一個位元組的時間
這個步驟的目標是盡快放送初始 HTML。我們將這個步驟列為最後一個，因為開發人員通常無法完全控制這個步驟。不過，這也是最重要的步驟之一，因為它會直接影響後續的每個步驟。後端必須先傳送第一個位元組的內容，前端才會開始運作，因此您可以採取任何措施來加快 TTFB，進而改善其他載入指標。
TTFB 速度緩慢的常見原因是訪客經過多次重新導向 (例如來自廣告或縮短連結) 才抵達網站。請務必盡量減少訪客必須等待的重新導向次數。
另一個常見原因是，當快取內容無法從 CDN 邊緣伺服器使用時，所有要求都必須導向原始伺服器。如果訪客使用不重複的網址參數來執行分析，即使訪客不會產生不同的網頁，也可能發生這種情況。
如需 TTFB 最佳化的具體指南，請參閱 TFB 最佳化指南。
監控 JavaScript 中的 LCP 細目
上述所有 LCP 子部分的時間資訊可透過 JavaScript 組合，讓您透過下列效能 API 使用：
在 JavaScript 中計算這些時間值的好處，是可將這些值傳送至分析服務供應商，或記錄至開發人員工具，以利進行偵錯和最佳化。
舉例來說，下列螢幕截圖使用 User Timing API 的 performance.measure() 方法，在 Chrome 開發人員工具效能面板中的 Timings 追蹤中加入長條。
當您一併查看「網路」和「主要執行緒」追蹤期間，系統會特別顯示「時機」測試群組中的視覺化圖表，因為您可以快速瞭解在這個時間範圍內還有哪些活動。
除了以視覺化方式呈現時間軌中的 LCP 子部分，您也可以使用 JavaScript 計算 LCP 總時間中每個子部分的百分比。掌握這項資訊，您就可以判斷網頁是否符合前述建議百分比細目。
這張螢幕截圖顯示一個範例，記錄每個 LCP 子部分的總時間，以及該 LCP 總使用時間在控制台中的記錄。
這兩種視覺化效果都是使用下列程式碼建立：
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
您可以將此程式碼直接用於本機偵錯，也可以修改程式碼將這些資料傳送給分析供應商，以便進一步瞭解實際使用者在網頁上的 LCP 細目。
使用 Chrome 開發人員工具監控 LCP 細目
Chrome 開發人員工具會即時記錄 LCP 時間、LCP 元素以及這四個子部分，方便你查看細目。
摘要
LCP 相當複雜，其時間點可能會受到多項因素影響。不過，若您認為最佳化 LCP 的重點在於改善 LCP 資源的負載，可能會大幅簡化 LCP。
大致來說，最佳化 LCP 最佳化可分為四個步驟：
- 確保 LCP 資源盡快開始載入。
- 確保 LCP 元素可在資源載入完成後立即轉譯。
- 在不影響品質的情況下，盡可能縮短 LCP 資源的載入時間。
- 請盡快提供初始 HTML 文件。
如果能在網頁上完成上述步驟，則應該確定網站能為使用者提供最佳載入體驗，也應該能反映實際的 LCP 分數。