網(wǎng)頁的 Largest Contentful Paint (LCP) 可能很難改進(jìn)，通常需要涉及多個動態(tài)部分并做出取舍蓉媳。此博文著眼于整個網(wǎng)絡(luò)中實際網(wǎng)頁加載的實測數(shù)據(jù)嫁怀，以確定開發(fā)者應(yīng)重點優(yōu)化哪些方面。

經(jīng)典 LCP 建議：縮減圖片大泄？洹层玲！

對于網(wǎng)絡(luò)上的大多數(shù)網(wǎng)頁，LCP 元素都是圖片反症。因此辛块，人們自然會認(rèn)為改善 LCP 的最佳方法是優(yōu)化 LCP 圖片。

在 LCP 問世后的大約五年里铅碍，這一直是大勢所趨润绵。請確保圖片尺寸合適且經(jīng)過充分壓縮，在制作圖片時也可以采用 21 世紀(jì)的圖片格式胞谈。Lighthouse 甚至有三種 不同的 審核來提出這些建議授药。

如果有娇澎，就去執(zhí)行吧！向用戶發(fā)送的字節(jié)數(shù)很少會帶來優(yōu)勢睹晒。網(wǎng)絡(luò)上有許多網(wǎng)站仍在提供不必要的大圖片趟庄，即使進(jìn)行基本壓縮就可以解決問題昭卓。

然而涩僻，當(dāng)我們開始查看 Chrome 中用戶的現(xiàn)場性能數(shù)據(jù)，了解 LCP 時間通常都花在哪些地方時，我們發(fā)現(xiàn)圖片下載時間幾乎從未成為瓶頸镜硕。

相反，LCP 的其他部分是一個大得多的問題蚓再。

LCP 子部分細(xì)分

為了了解改進(jìn) LCP 的最大機(jī)會領(lǐng)域次和，我們查看了 LCP 子部分的數(shù)據(jù)，如優(yōu)化 LCP 中所述拖云。

雖然每個網(wǎng)頁和每個框架都可能會采用不同的方法來加載和顯示將成為網(wǎng)頁 LCP 元素的內(nèi)容贷笛，但每個網(wǎng)頁都可以分為以下子部分：

引用該文章中的各子部分如下：

• 首字節(jié)時間 (TTFB)
  從用戶開始加載網(wǎng)頁到瀏覽器加載網(wǎng)頁之間的時間 接收 HTML 文檔響應(yīng)的第一個字節(jié)。
• 資源加載延遲
  從 TTFB 到瀏覽器開始加載 LCP 資源所用的時間宙项。如果 LCP 元素不需要加載資源即可渲染乏苦，現(xiàn)為 0。
• 資源加載時長
  加載 LCP 資源本身所用的時長尤筐。如果 LCP 元素不需要加載資源即可渲染汇荐，時間為 0。
• 元素渲染延遲
  從 LCP 資源完成加載到 LCP 元素完成加載之間的時間 才能完全呈現(xiàn)

真實的導(dǎo)航性能數(shù)據(jù)

| LCP 分級 | TTFB（毫秒） | 圖片加載延遲（毫秒） | 圖片加載時長（毫秒） | 渲染延遲（毫秒） |
| 良好 | 600 | 350 | 160 | 230 |
| 需要改進(jìn) | 1,360,000 | 720 | 270 | 310 |
| 差 | 2,270,000 | 1290 | 350 | 360 |

在這篇博文中盆繁，我們使用了 Chrome 中帶有子資源圖片 LCP 的網(wǎng)頁導(dǎo)航數(shù)據(jù)來查看 LCP 子部分拢驾。我們以前了解過此類數(shù)據(jù)，但從未通過實測數(shù)據(jù)來了解真實用戶在等待網(wǎng)頁 LCP 時將時間花在了何處改基。
與 Core Web Vitals 一樣繁疤，對于 CrUX 數(shù)據(jù)集中每個來源的每個 LCP 子部分，我們選取了第 75 個百分位 (p75)秕狰，從而得出 p75 值的 4 次分布（每個子部分各一個）稠腊。為了總結(jié)這些分布情況，我們針對四個 LCP 子部分分別取了所有源中這些值的中位數(shù)鸣哀。

最后架忌，我們根據(jù)源是“良好”“需要改進(jìn)”還是“較差”將源分成多個存儲分區(qū)第 75 百分位的 LCP。這有助于顯示 LCP 良好與 LCP 不良的來源有何區(qū)別我衬。

要縮減 LCP 圖片的大小嗎叹放？這次有數(shù)據(jù)

加載時長用于衡量提取 LCP 資源（在本例中為圖片）所需的時間。該時間通常與映像中的字節(jié)數(shù)成正比挠羔，因此所有減少該字節(jié)數(shù)的性能建議都是如此井仰。

從前面的圖表中時間趨勢來看，有一點也值得注意破加，那就是圖片加載時長沒有花費(fèi)很多時間俱恶。事實上，在所有 LCP 分桶中，它是最短的 LCP 子部分合是。與 LCP 性能良好的源相比了罪，LCP 性能不佳的來源的加載時長更長，但這并不是耗費(fèi)大量時間的因素聪全。

大多數(shù) LCP 表現(xiàn)不佳的來源在下載 LCP 映像時所花的時間都不到其 p75 LCP 時間的 10%泊藕。

是的，您應(yīng)確保對圖片進(jìn)行優(yōu)化难礼，但這只是改進(jìn) LCP 的一個環(huán)節(jié)娃圆。從這些數(shù)據(jù)可以看出，對于網(wǎng)絡(luò)上的典型來源鹤竭，無論壓縮方案有多復(fù)雜，LCP 整體上的潛在毫秒增益都很小景醇。

注意：請注意臀稚，LCP 的實測數(shù)據(jù)包括到網(wǎng)頁的所有類型的導(dǎo)航，包括 LCP 資源已存在于瀏覽器緩存中的導(dǎo)航三痰。這可以降低這些數(shù)字吧寺，但是用每個源站的 p75 加載時長過濾掉了很多這種情況（在訪問您的網(wǎng)站的 75% 的導(dǎo)航中，雖然有 75% 的導(dǎo)航已在緩存中保存了 LCP 圖片散劫，但這種情況不太可能發(fā)生）稚机。

最后令人驚訝的是，加載速度過慢通常是在移動設(shè)備上和移動網(wǎng)絡(luò)的質(zhì)量造成的获搏。我們可能曾以為赖条，普通手機(jī)要像使用有線連接的桌面設(shè)備一樣要多次下載同一張圖片。數(shù)據(jù)顯示常熙，情況不再如此纬乍。對于 LCP 較低的來源，P75 圖片在移動設(shè)備上的加載時間中位數(shù)僅比桌面設(shè)備慢 20%裸卫。

首字節(jié)時間 (TTFB)

對于發(fā)出網(wǎng)絡(luò)請求的導(dǎo)航仿贬，TTFB 始終需要一些時間。執(zhí)行 DNS 查找和啟動連接需要花費(fèi)一些時間墓贿。物理問題無與倫比：一項請求必須通過電線和光纜在現(xiàn)實世界中穿行才能到達(dá)服務(wù)器茧泪，然后響應(yīng)必須返回該服務(wù)器。即使是具有良好 LCP 的中位數(shù)來源聋袋，在第 75 個百分位的 TTFB 上花費(fèi)的時間也超過 0.5 秒队伟。

然而，良好 LCP 源與不良 LCP 源之間的 TTFB 差異表明了改進(jìn)空間幽勒。對于至少一半的 LCP 較差的來源來說缰泡，僅 2,270 毫秒的 p75 TTFB 幾乎可以保證 p75 LCP 不會比 2.5 秒的“良好”快閾值。**即便是該時間的適度縮短百分比，也意味著 LCP 會得到顯著提升棘钞。

你可能無法通過物理驗證缠借，但可以做到這一點。例如宜猜，如果您的用戶經(jīng)常與您的服務(wù)器位于不同的位置泼返，那么 CDN 可以使您的內(nèi)容更靠近他們。

如需了解詳情姨拥，請參閱優(yōu)化 TTFB 指南绅喉。

資源加載延遲、LCP 運(yùn)行緩慢的罪魁禍?zhǔn)资潜缓鲆?/h2>

如果 TTFB 可以改進(jìn)叫乌，但任何改進(jìn)都受物理特性的約束柴罐，那么資源加載延遲或許可以消除，實際上憨奸，僅受服務(wù)架構(gòu)約束革屠。

該子部分測量從收到 HTML 響應(yīng) (TTFB) 的第一個字節(jié)到瀏覽器啟動 LCP 圖片請求所用的時間。多年來排宰，我們一直在關(guān)注下載 LCP 圖片所需的時間似芝，但我們經(jīng)常忽略了在瀏覽器收到開始下載提示之前就浪費(fèi)的時間。

對于 LCP 表現(xiàn)不佳的中位數(shù)網(wǎng)站板甘，其等待開始下載 LCP 圖片所用的時間幾乎是實際下載 LCP 圖片的四倍党瓮，在 TTFB 和圖片請求之間等待 1.3 秒。這超過了 2.5 秒 LCP 預(yù)算的一半以上盐类。

依賴項鏈?zhǔn)菍?dǎo)致加載延遲時間較長的常見原因寞奸。較為簡單的一點是，頁面加載樣式表在跳，在瀏覽器完成布局后蝇闭，系統(tǒng)會設(shè)置一個背景圖片，該圖片最終將成為 LCP硬毕。所有這些步驟都必須在瀏覽器確定開始下載 LCP 圖片之前完成呻引。

使用 HTTP Archive 公開抓取數(shù)據(jù)，其中記錄了“發(fā)起者”從 HTML 文檔到 LCP 圖片的網(wǎng)絡(luò)請求鏈吐咳，您可以看到請求鏈長度與 LCP 速度較慢之間有明確的關(guān)聯(lián)逻悠。

關(guān)鍵是要盡快讓瀏覽器知道 LCP 是什么，這樣瀏覽器就能開始加載韭脊，即使在頁面布局中有可用位置之前也是如此童谒。您可以使用一些工具完成此操作，例如在 HTML 中使用經(jīng)典的 <img> 標(biāo)記（這樣預(yù)加載掃描器可以快速找到它并開始下載）沪羔，或者使用 <link rel="preload"> 標(biāo)記（或 HTTP 標(biāo)頭）來標(biāo)記不屬于 <img> 的圖片饥伊。

幫助瀏覽器確定要優(yōu)先處理的資源也很重要象浑。如果您的網(wǎng)頁在網(wǎng)頁加載期間發(fā)出了很多請求，這一點尤為重要琅豆，因為瀏覽器通常只有在其中許多資源都已加載且布局已加載完畢之后才會知道 LCP 元素是什么愉豺。使用 fetchpriority="high" 屬性為可能的 LCP 元素添加注解（并確保避免使用 loading="lazy"），可讓瀏覽器明確知道應(yīng)立即開始加載資源茫因。

閱讀有關(guān)優(yōu)化加載延遲的更多建議蚪拦。

渲染延遲

呈現(xiàn)延遲時間用于衡量從瀏覽器加載并準(zhǔn)備就緒 LCP 圖片開始的時間，但出于某種原因冻押，圖片在屏幕上顯示時會有延遲驰贷。有時，這是一個耗時較長的任務(wù)洛巢，在圖片準(zhǔn)備就緒時阻塞主線程括袒，而在其他情況下，這可能是顯示隱藏元素的界面選擇稿茉。

對于網(wǎng)絡(luò)上的典型來源锹锰，呈現(xiàn)延遲似乎并不大，但在優(yōu)化期間狈邑，有時您可以創(chuàng)建渲染延遲城须，讓之前在其他子部分花費(fèi)的時間占到蚤认。例如米苹，如果網(wǎng)頁開始預(yù)加載 LCP 圖片以便快速加載，則不會再有很長的加載延遲砰琢，但如果網(wǎng)頁本身尚未準(zhǔn)備好顯示圖片（例如蘸嘶，如果網(wǎng)頁本身尚未準(zhǔn)備好顯示圖片（例如，從會阻止內(nèi)容呈現(xiàn)的大型樣式表或客戶端渲染應(yīng)用中必須加載完所有 JavaScript 才能顯示）陪汽，則 LCP 會比它應(yīng)該變慢训唱，而且等待時間也會顯示為呈現(xiàn)延遲。正因如此挚冤，在 LCP 方面况增，服務(wù)器端呈現(xiàn)或靜態(tài) HTML 通常具有優(yōu)勢。

如果您自己的內(nèi)容受到影響训挡，請參閱有關(guān)優(yōu)化渲染延遲的更多建議澳骤。

請檢查所有這些子部分

很明顯，要有效優(yōu)化 LCP澜薄，開發(fā)者需要全面關(guān)注網(wǎng)頁加載情況为肮，而不僅僅是專注于優(yōu)化圖片。請每時每刻檢查一次 LCP肤京，因為目前改進(jìn)的空間可能要大得多颊艳。

為了在字段中收集此類數(shù)據(jù)，web-vitals 庫的歸因 build 中會包含 LCP 子部分的計時。Chrome 用戶體驗報告 (CrUX) 尚未包含所有數(shù)據(jù)棋枕，但包含 TTFB 和 LCP 條目白修，因此是一個開始。我們希望將來在 CrUX 中包含這篇博文使用的數(shù)據(jù)戒悠，敬請關(guān)注更多相關(guān)新聞熬荆。

如需在本地測試 LCP 子部分，請嘗試使用網(wǎng)頁指標(biāo)擴(kuò)展程序或本文中的 JavaScript 代碼段绸狐。Lighthouse 還在其“Largest Contentful Paint 元素”中添加了細(xì)分卤恳。審核。您可以在開發(fā)者工具性能面板中查看更多 LCP 子部分建議（即將推出）寒矿。