網頁的最大內容繪製 (LCP) 可能很難改善，通常會牽涉到多個需要移動的部分和取捨。本文將分析網路實際載入網頁的實際數據，以判斷開發人員該將最佳化作業投注在何處。
傳統 LCP 建議：請縮減圖片大小！
對網路上的大多數網頁來說，LCP 元素都是圖片。因此，一般會假設改善 LCP 的最佳方法就是最佳化 LCP 圖片。
自 LCP 推出以來，大約五年內就開始有許多頭條建議。請確保圖片尺寸適當且經過適當壓縮，並可能在該處使用 21 世紀的圖片格式。Lighthouse 甚至有三種 不同的 稽核來提出這些建議。
造成這種情況的部分常見原因，就是不易測量過多位元組，圖片壓縮工具也很容易提供。視您的建構和部署管道而定，可能也較容易實作。
如果有，請做到！傳送較少的位元組給使用者通常較為可行。網路上有許多網站仍提供不必要大型圖片，即使是基本壓縮也能修正。
不過，我們開始檢視 Chrome 使用者的現場效能資料，以瞭解 LCP 時間一般花費的時間時，我們發現圖片下載時間幾乎不會遇到瓶頸。
LCP 反而會遇到更大的問題。
LCP 子部分細目
為了瞭解改善 LCP 的最大商機領域，我們研究了 LCP 子部分的資料，如最佳化 LCP 所述。
雖然每個網頁和每個架構在載入和顯示網頁 LCP 元素時，可能各有不同，但每種架構都可分為下列子部分：
從該篇文章中排除，子部分為：
- 第一個位元組時間 (TTFB)
- 從使用者開始載入網頁到瀏覽器之間的時間 接收 HTML 文件回應的第一個位元組。
- 資源載入延遲
- 從 TTFB 到瀏覽器開始載入 LCP 資源之間的時間。如果
LCP 元素不需要載入資源就能顯示，這次為
0。 - 資源載入時長
- 載入 LCP 資源本身所需的時間。如果 LCP
元素不需要載入資源就能顯示，目前為
0。 - 元素轉譯延遲時間
- 從 LCP 資源完成載入到 LCP 元素之間的時間長度 算繪的所有結果
真實導航效能資料
| LCP 分級 | TTFB (毫秒) | 圖片載入延遲時間 (毫秒) | 圖片載入時間長度 (毫秒) | 轉譯延遲時間 (毫秒) |
|---|---|---|---|---|
| 不錯 | 600 | 350 | 160 | 230 |
| 需要改善 | 1,360 人 | 720 | 270 | 310 |
| 不佳 | 2,270 人 | 1,290 人 | 350 | 360 |
在這篇文章中，我們使用 Chrome 中帶有子資源圖片 LCP 的網頁瀏覽資料，查看 LCP 的子部分。我們之前已經查閱過這類資料，但從未透過現場資料瞭解實際使用者花時間在等待網頁的 LCP 階段。
如同 Core Web Vitals，我們針對 CrUX 資料集中的每個來源，採取第 75 個百分位數 (第 75 個)，因此產生了 4 個 p75 值 (每個子部分各一個) 的分佈情況。為彙整這些分佈情形，我們針對 4 個 LCP 子部分的所有來源，計算出這些值的中位數。
最後，我們會根據來源的「良好」、「需要改善」或「不佳」，將來源分成不同區塊LCP 位於第 75 個百分位數。這有助於區分 LCP 良好以及 LCP 不佳的來源區分兩者。
要縮減 LCP 圖片的大小嗎？這次有資料
載入時間會衡量擷取 LCP 資源所需的時間，在本範例中為圖片。所需時間通常與圖片中的位元組數量成正比，因此所有效能建議都能幫助您減少位元組數量。
查看先前的圖表中發生時間的情況時，會發現系統載入圖片的時限並沒有太多時間。事實上，這是所有 LCP 值區中最短的 LCP 子部分。與良好 LCP 來源相比，不良 LCP 來源的載入時間較長，但這仍不見得花費大量時間。
大多數 LCP 不佳的來源在下載 LCP 映像檔時，所花的時間都不到 p75 LCP 的 10%。
可以。您應該確保圖片都經過最佳化處理，但這只是改善 LCP 功能的一環。從這些資料可看出，網路上一般來源的資料可清楚看出，無論壓縮配置有多複雜， LCP 的整體潛在毫秒增幅都不大。
最後一個令人驚訝的是，應用程式載入時間緩慢，通常源自於行動裝置和行動網路的品質，我們曾經預期，一般手機和有線連線時，一般手機需要多次下載同一張圖片。資料顯示，目前情況已非如此。如果來源的 LCP 偏低，p75 圖片載入時間中位數，在行動裝置上比電腦慢 20%。
第一個位元組時間 (TTFB)
對於發出網路要求的導覽作業，TTFB 一律需要一些時間。執行 DNS 查詢並啟動連線需要一些時間。物理效法是非凡：要求必須透過線路和光學纜線通過現實世界，才能連上伺服器。這時回應必須再次回到伺服器。即使是有效 LCP 良好的來源，也在 TTFB 上花費超過一半的時間，第 75 個百分位數。
不過，LCP 來源優化與不佳的 LCP 差異時，則代表兩者仍有改善空間。對於 LCP 不佳的 LCP 低下，「光是」2,270 毫秒的 TTFB 幾乎可以保證 p75 LCP 不會比 2.5 秒「良好」更快。門檻。即使減少百分比，將能大幅改善 LCP。
你或許無法通過物理，但有某些事情可以做到。舉例來說，如果使用者經常和您的伺服器位置非常不同，CDN 可以縮短內容之間的距離。
詳情請參閱最佳化 TTFB 指南。
資源負載延遲，以及被忽略的 LCP 緩慢問題
如果 TTFB 可以改善，但任何改善都會受到物理影響，資源載入延遲可能會避免，因為實際上只受限於服務架構。
這個子部分會測量從 HTML 回應 (TTFB) 第一個位元組抵達，到瀏覽器開始 LCP 圖片要求的時間。我們一直致力於改善 LCP 圖片下載作業所需的時間，但我們通常忽略了瀏覽器系統通知開始下載前的浪費時間。
如果 LCP 品質不佳的網站，在等待開始下載 LCP 圖片的情況下，平均花費將近 4 倍；TTFB 和圖片要求之間會等候 1.3 秒。超過 2.5 秒 LCP 預算的一半超過一個子部分。
依附元件鏈結是載入時間過長的常見原因。簡而言之，頁面會載入樣式表，並在瀏覽器完成版面配置後設定背景圖片，圖片最後是 LCP。所有步驟都必須在瀏覽器知道開始下載 LCP 圖片之前完成。
使用 HTTP 封存的公開檢索資料，記錄「發起者」從 HTML 文件到 LCP 圖片的網路要求鏈結，可讓您看到要求鏈結長度與 LCP 較慢的明確關聯。
關鍵在於盡快讓瀏覽器瞭解 LCP，以便在網頁版面配置中有可以開始載入 LCP 的情況下開始載入。有多種工具可完成此作業，例如 HTML 中的傳統版 <img> 標記，讓預先載入掃描器可快速找到並下載該標記，或是對非 <img> 的圖片使用 <link rel="preload"> 標記 (或 HTTP 標頭)。
此外，協助瀏覽器決定要優先處理哪些資源也很重要。特別是當網頁載入期間發出大量要求時，特別是在許多資源已載入並完成版面配置之前，瀏覽器通常不會知道 LCP 元素將什麼影響。使用 fetchpriority="high" 屬性為可能的 LCP 元素加上註解 (並確保避免使用 loading="lazy")，可讓瀏覽器明確開始載入資源。
轉譯延遲
「轉譯延遲」是指從瀏覽器載入 LCP 圖片並準備就緒的時間，但因為某些原因，需要經過一段時間才會顯示在畫面上。有時這個長時間工作會在圖片準備就緒時阻斷主執行緒，而在其他情況下，這可能是 UI 選項來顯示隱藏的元素。
以網路上的典型來源來說，似乎沒有很高的轉譯延遲機會，不過在最佳化的過程中，有時你可以「建立」轉譯延遲，讓轉譯時間延遲於其他子部分。舉例來說，如果網頁開始預先載入 LCP 圖片以快速載入，將不會再延遲很久，但如果網頁本身無法繼續顯示圖片 (比如大型的轉譯的樣式表，或是必須完成所有 JavaScript 才能顯示任何內容的用戶端轉譯應用程式)，LCP 仍將速度比預期慢，且顯示所需時間也會因為顯示時間延遲而有所延遲。因此，就 LCP 而言，伺服器端轉譯或靜態 HTML 通常有優勢。
如果你的內容受到影響，請參閱更多有關最佳化轉譯延遲的建議。
勾選所有子部分
顯然要有效最佳化 LCP，開發人員需要全面檢視網頁的載入速度，而不只是專心改善圖片。使用 LCP 檢查時間的每個階段，因為都可能有較大的改善機會。
為了在領域收集這項資料，網站 Vitals 程式庫的歸因版本包含 LCP 子部分的時間。Chrome 使用者體驗報告 (CrUX) 尚未納入所有資料，但其中確實有 TTFB 和 LCP 項目，因此一切都是以此為基礎。我們希望未來能在 CrUX 中納入這篇文章使用的資料，敬請期待！
如要在本機測試 LCP 子部分，請嘗試使用網站體驗指標擴充功能或本文中的 JavaScript 程式碼片段。Lighthouse 也在「Largest Contentful Paint 元素」中加入細目稽核。你可以在即將推出的「開發人員工具」效能面板中查看更多 LCP 子部分建議。