關於如何最佳化 LCP 的常見誤解

網頁的最大內容繪製 (LCP) 可能難以改善,因為通常會涉及多個動態部分和權衡。這篇文章將探討來自網際網路上實際網頁載入作業的欄位資料,以判斷開發人員應將最佳化工作重點放在哪裡。

對於大多數網頁來說,LCP 元素是圖片。因此,我們自然會認為改善 LCP 的最佳方式,就是對 LCP 圖片進行最佳化。

自從 LCP 推出以來的五年左右,這一直是主要的建議。請確認圖片的大小適當且壓縮程度足夠,並且在使用時採用 21 世紀的圖片格式。Lighthouse 甚至提供三種 不同的 稽核,提供這些建議。

Lighthouse 報表中的三項圖片最佳化稽核
Lighthouse 報表中的三項圖片最佳化稽核項目。

這項建議之所以如此常見,是因為過多的位元組很容易評估,而且圖片壓縮工具也容易推薦。視建構和部署管道而定,這項功能也可能很容易實作。

如果是,請務必這樣做!向使用者傳送的位元組越少,幾乎總是有利的做法。網路上有許多網站仍提供不必要的大型圖片,即使採用基本壓縮功能也能解決。

不過,當我們開始查看 Chrome 使用者的實地效能資料,瞭解 LCP 通常花費的時間,我們發現圖片下載時間幾乎從未是瓶頸。

相反地,LCP 的其他部分才是更大的問題。

LCP 子部分細目

為瞭解改善 LCP 的最大商機所在,我們查看了 LCP 子部分的資料,詳情請參閱「改善 LCP」一文。

雖然每個網頁和架構可能會採用不同的方式載入及顯示網頁的 LCP 元素,但每個元素都可以分為以下子部分:

LCP 細目,顯示四個子部分

引用該文章,子部分如下:

收到第一個位元組的時間 (TTFB)
從使用者開始載入網頁,到瀏覽器收到 HTML 文件回應的第一個位元組所需的時間。
資源載入延遲
TTFB 與瀏覽器開始載入 LCP 資源之間的時間。如果 LCP 元素不需要資源載入就能轉譯,這個時間就是 0
資源載入時長
載入 LCP 資源本身所需的時間長度。如果 LCP 元素不需要資源載入才能算繪,則這段時間為 0
元素轉譯延遲
從 LCP 資源完成載入到 LCP 元素完全算繪的時間。

實際導覽成效資料

這張長條圖以視覺化方式呈現各個 LCP 子部分所花費的時間差異,並將 LCP 分為「良好」、「需要改善」和「不佳」等類別。TTFB 和載入延遲時間快速增加,但載入時間和轉譯延遲時間仍維持短暫。資料會在下表中重現

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 資料集中每個來源的每個 LCP 子部分,採用第 75 個百分位數 (p75),因此產生四個 p75 值分布 (每個子部分各一個)。為了總結這些分布情形,我們針對四個 LCP 子部分,計算所有來源的這些值的中位數。

最後,我們會根據來源網頁是否有 「良好」、「需要改善」或「低落」的 LCP 75 個百分位數,將來源網頁分成不同的類別。這有助於顯示 LCP 優良與 LCP 不佳的來源有何差異。

縮減 LCP 圖片的大小?這次是使用資料

載入時間長度是指擷取 LCP 資源 (在本例中為圖片) 所需的時間。這段時間通常會與圖片中的位元組數量成正比,因此所有效能建議都會建議減少位元組數量。

查看先前圖表中時間的流逝情形時,有一個明顯的現象,就是圖片載入時間並未耗費太多時間。事實上,在所有 LCP 值區間中,這是最短的 LCP 子部分。載入時間長短取決於 LCP 來源,但這並非主要影響時間的因素。

大多數 LCP 表現不佳的來源,其 p75 LCP 時間不到 10%,都用於下載 LCP 圖片。

是的,您必須確保圖片經過最佳化,但這只是改善 LCP 的其中一個環節。從這項資料可清楚看出,對於一般網站來源而言,無論壓縮方案有多複雜,LCP 的整體潛在毫秒增幅都很小。

最後一個令人意外的發現是:載入時間過長的問題,過去通常歸咎於行動裝置和行動網路品質。我們曾經預期,一般手機下載相同圖片的時間會比使用有線連線的桌上型電腦長上好幾倍。但資料顯示,現在已非如此。對於 LCP 不佳的來源,行動裝置的圖片載入時間中位數 (p75) 僅比電腦版慢 20%。

收到第一個位元組的時間 (TTFB)

對於發出網路要求的導覽,TTFB 一向需要一些時間。執行 DNS 查詢並開始連線需要一些時間。您無法違反物理定律:要求必須透過實體線路和光纖電纜傳送至伺服器,然後回應必須傳回。即使是 LCP 良好的中位來源,在 75 百分位數時,TTFB 也要花費超過半秒的時間。

不過,良好和不良 LCP 來源之間的 TTFB 差異,顯示了改善的機會。對於至少一半的 LCP 不佳來源,p75 TTFB 為 2,270 毫秒,幾乎保證 p75 LCP 不會快過「良好」門檻 2.5 秒。即使將這段時間減少的百分比不高,也能大幅改善 LCP。

雖然您無法違反物理定律,但仍有其他方法可以解決問題。舉例來說,如果使用者經常位於與伺服器位置相差甚遠的地點,CDN 就能將內容傳送至更靠近使用者的地點。

詳情請參閱「最佳化 TTFB 指南」。

資源載入延遲:造成 LCP 速度緩慢的常被忽略的因素

如果 TTFB 可以改善,但任何改善都受到物理限制,則資源載入延遲可能會消失,實際上只受服務架構限制。

這個子部分會計算從 HTML 回應第一個位元組到達 (TTFB) 到瀏覽器開始要求 LCP 圖片的時間。多年以來,我們一直專注於 LCP 圖片的下載時間,但經常忽略瀏覽器開始下載前所浪費的時間。

在 LCP 不佳的網站中,等待開始下載 LCP 圖片的時間,幾乎是實際下載時間的四倍,TTFB 和圖片請求之間的等待時間為 1.3 秒。這意味著,單一子部分就佔用了 2.5 秒 LCP 預算的一半以上。

依附元件鏈結是造成載入時間延遲的常見原因。簡單來說,網頁載入樣式表單,在瀏覽器完成版面配置後,會設定背景圖片,而這張圖片最終會成為 LCP。瀏覽器必須先完成所有這些步驟,才會開始下載 LCP 圖片。

使用 HTTP Archive 公開檢索資料,記錄從 HTML 文件到 LCP 圖片的網路要求「啟動」鏈結,您就能清楚瞭解要求鏈結長度與 LCP 速度較慢的關聯性。

這張圖表以視覺化方式呈現依附要求鏈結與 LCP 的關係。LCP 中位數從 0 個依附要求的 2,150 毫秒,增加到 1 個依附要求的 2,540 毫秒,再到 2 個依附要求的 2,850 毫秒
依附要求鏈結與 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 的每個時間部分,因為這可能有更大的改善空間。

如要在實地收集這類資料,web-vitals 程式庫的歸因建構程序會納入 LCP 子部分的時間。Chrome 使用者體驗報告 (CrUX) 尚未納入所有這類資料,但已包含 TTFB 和 LCP 的項目,所以這只是個開始。我們希望日後能將這篇文章所用的資料納入 CrUX,敬請持續關注相關消息。

如要在本機測試 LCP 子項,請試試 Web Vitals 擴充功能本文的 JavaScript 程式碼片段。Lighthouse 也會在「最大內容繪製元素」稽核項目中提供詳細資料即將推出的開發人員工具「效能」面板中,將提供更多 LCP 子部分建議。