LCP 優化做了卻沒效？你該知道的四段等待鏈

多數人以為 LCP 慢是圖片的錯，把首圖壓了又壓、格式換成 WebP、尺寸也砍到最小，PageSpeed Insights 的分數卻卡在同一個地方動不了。Google 在 web.dev 的一篇分析裡點出反例，多數 LCP 不佳的網站，圖片下載時間通常占不到整體 LCP 的一成。

LCP 優化真正要處理的，是使用者打開頁面後，視窗裡那塊最大主要內容（通常是首圖、大標題或商品主圖）多久才真正畫出來。Google 把 2.5 秒訂為「良好」的門檻，而且看的是 75% 使用者的真實體驗，不是單次測試跑出來的漂亮數字。台灣多數流量走手機，手機的 LCP 又天生比桌機更容易超標，這個門檻對本地網站格外吃重。

真正該做的，不是把力氣全押在圖片上，而是把 LCP 拆成四段各有分工的時間，一段一段揪出瓶頸卡在哪裡。先從這個門檻實際怎麼判定講起，再回頭拆解多數人想錯的地方。

LCP 是什麼？2.5 秒的門檻怎麼判定？

2.5 秒這個數字不是隨便訂的，它背後是 Google 對「使用者能不能在可接受時間內看到主要內容」畫出的一條線。LCP（Largest Contentful Paint，最大內容繪製）的定義，是使用者進入頁面後，視窗內最大的圖片、文字區塊或影片完成繪製所花的時間，也是 Core Web Vitals（網站體驗核心指標）三項指標之一，另外兩項是 INP（互動延遲，已於 2024 年取代 FID）與 CLS（版面穩定性）。

Google 把 LCP 分成三個等級：

要留意的是，這個門檻看的不是單一次測試，而是 75% 使用者的真實體驗。也就是說，就算多數訪客都能在 2.5 秒內看到主要內容，只要有超過四分之一的人等得比較久，這個頁面在 Google 眼中就還沒真正達標。

手機的 LCP 通常比桌機更難過關，原因不只是網路速度，還包含裝置運算能力較弱、頁面在手機上要處理的排版與腳本相對吃重。台灣網站的流量多半以手機為主，這個落差值得優先盯著手機資料看，而不是被桌機的漂亮分數安慰。

多數人以為問題出在圖片，其實通常不是

門檻定義清楚之後，回頭看開頭那個數據更有意思。Google 那篇分析持續追蹤了大量 LCP 不佳的網站，發現另外兩個現象同樣違反直覺。第一、同樣是 LCP 不佳的網站，手機下載圖片的時間平均只比桌機慢兩成左右，網路速度沒有想像中拖累那麼多。第二，也是影響最大的一點：這些網站的瀏覽器，等到真正開始下載 LCP 資源之前，平均要花掉接近實際下載時間四倍的時間在等待。

換句話說，問題往往不在圖片本身有多重，而在瀏覽器根本太晚才知道要去抓這張圖，或是等太久都拿不到伺服器回應的第一個位元組。把圖片壓到極致，省下的常常是這條時間鏈裡本來就最短的一段，難怪分數幾乎不動。

真正該查的，是接下來要拆開的四段時間，找出瀏覽器到底把時間花在哪裡，再決定該修伺服器、修發現順序，還是才輪到修圖片。

LCP 拆開來看是四段時間，不是憑感覺抓瓶頸

Google 把 LCP 拆解成四段，依發生順序排列：首位元組時間（TTFB）、資源載入延遲（Resource Load Delay）、資源載入耗時（Resource Load Duration）、元素渲染延遲（Element Render Delay）。四段合起來，就是使用者看到主要內容之前，瀏覽器實際在忙的每一步。

Google 官方也給了每段該占多少比重的參考：

這代表大部分時間該花在下載 HTML 與 LCP 資源這兩件真正在做事的環節，發現與渲染這兩段延遲加起來，理想上不該占超過整體的兩成。只要延遲段的占比明顯偏高，就代表瀏覽器多數時間都在等，而不是在做事，這正是前一節那個反直覺數據背後的原因。

要看到自己網站的四段實際數字，可以到 PageSpeed Insights 或 Chrome 開發者工具的 Performance 面板，找到「Largest Contentful Paint element」這個診斷項目，裡面會列出這四段各自花了多久。先看哪一段占比最大，再決定往下該查哪個原因。

原因一：TTFB 太高，後面每一段都陪著等

這條時間鏈最前面一段是 TTFB。HTML 還沒回來，瀏覽器連頁面上有什麼、該去抓哪張圖都不知道，這段時間，整台瀏覽器只能乾等。

Google 官方把 TTFB 的判定門檻分成三級，0.8 秒以內算良好，0.8 至 1.8 秒之間待改善，超過 1.8 秒就算不佳。

TTFB 偏高常見的原因不脫幾種：主機資源不夠、沒有啟用頁面快取、資料庫查詢太重、有不必要的重新導向、或伺服器離使用者太遠。以 WordPress 來說，如果每次請求都要 PHP 重新組頁、查一輪資料庫、跑完外掛邏輯才能吐出 HTML，TTFB 很難穩定壓低。

處理順序建議先確認有沒有啟用可靠的頁面快取，讓多數訪客拿到的是已經算好的 HTML，而不是每次都重新運算；接著檢查主機方案與資料庫，慢查詢與肥大的外掛都會拖累回應；同源之間不必要的重新導向也該一併清掉。判斷有沒有效，直接看 PageSpeed Insights 或瀏覽器網路面板裡那筆 document（HTML 文件）請求的等待時間有沒有縮短即可。

原因二：LCP 資源被瀏覽器發現得太晚，下載跟著慢半拍

前面提到的那個數據，在這裡最有解釋力。多數 LCP 不佳網站，瀏覽器要等到接近下載時間四倍那麼久，才真正開始下載 LCP 資源，這段等待就是 Resource Load Delay。常見成因包括首圖被設成延遲載入、圖片藏在 CSS 的 background-image 裡要等樣式表解析完才會被發現、圖片是由 JavaScript 動態插入畫面，或單純沒有下 preload 指示。

第一個該做的動作最直接，就是拿掉首圖或商品主圖上的 loading=”lazy”。延遲載入本來是省頻寬的好工具，但用在使用者一打開頁面就看得到的 LCP 元素上，只會讓瀏覽器等到它快滑進畫面才肯下載，白白拖長這段延遲。

<img
  src="hero.webp"
  alt="首頁主視覺"
  width="1200"
  height="630"
  fetchpriority="high">Code language: HTML, XML (xml)

接著可以用兩個工具讓它插隊。fetchpriority=”high” 用在圖片已經寫在 HTML 裡、只是被排在較低優先序的情況，直接告訴瀏覽器這張圖要先下載；preload 則用在資源藏得比較深、要等 CSS 解析完才會被發現的情況，例如背景圖：

<link
  rel="preload"
  as="image"
  href="hero.webp"
  fetchpriority="high">Code language: HTML, XML (xml)

這一步的效益相當直接。DebugBear 記錄過一個案例，某頁面的 LCP 圖片本來要先載入一份 CSS 才會被瀏覽器發現，等於排進一條請求鏈；補上 preload 讓 CSS 與圖片改成平行載入之後，LCP 從 2.29 秒降到 1.7 秒。要提醒的是，fetchpriority=”high” 不能整頁多個資源都設，一旦大家都搶著當第一優先，等於誰都不優先，原則上一頁只留給那一個 LCP 元素。

原因三：圖片格式或尺寸沒給對，下載時間被拉長

排到第三順位，不代表圖片不重要，只是它通常不是第一個該查的地方。如果前兩段時間都已經壓得夠低，PageSpeed Insights 標出的 LCP 元素又剛好是一張圖，這時候格式與尺寸才真正有感。

先講格式。WebP 與 AVIF 能在肉眼幾乎看不出差別的前提下，把檔案壓得比傳統 JPEG、PNG 小上不少。MDN（Mozilla）的一篇分析示範過，一張 1MB 的圖轉成 AVIF、品質設在 80%，檔案可以降到 46KB 左右，等於省下約九成五。實作上用 picture 元素把多種格式包在一起，瀏覽器會依支援度由上而下挑第一個能用的格式：

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="首頁主視覺" width="1200" height="630">
</picture>Code language: HTML, XML (xml)

再講尺寸，這點更容易被忽略。MDN 那篇分析也記錄過一個真實案例，一張 1920×1080、檔案 2.26MB 的首圖，在手機視窗底下依然被整張下載，光這張圖就拖了相當長的下載時間。問題不在格式，而在尺寸完全沒有跟著裝置縮小。正確做法是搭配 srcset 與 sizes，準備幾個不同寬度的版本，讓瀏覽器依螢幕寬度挑合適的那張，別讓手機使用者下載一張桌機規格的原圖。記得補齊 img 上的 width 與 height，避免圖片載入時把版面撐開造成跳動。

原因四：資源到位了，渲染卻被擋住

有時候 LCP 圖片明明很快就下載完成，畫面卻還是空白一段時間，問題就出在最後一段 Element Render Delay。資源已經備好，渲染卻被別的東西擋住。

擋路的通常是會阻擋渲染的 CSS 與 JavaScript。CSS 預設會擋住渲染，因為瀏覽器要先載完、解析完樣式，才不會讓使用者看到沒套樣式的畫面；放在 head 裡、沒加 defer 或 async 的 script，也會卡住 HTML 的解析進度。當這些資源肥大又載得慢，主要內容就只能在後面排隊。

處理方向有兩個。CSS 的部分，只保留首屏真正需要的關鍵樣式，其餘非首屏才用到的部分延後載入。WordPress 常見的狀況是佈景主題、外掛、區塊各自塞了一堆樣式，首屏被整包一起擋住，這時要做的不是全部砍掉，而是先讓首屏拿到它需要的那一小塊。JavaScript 的部分，用 defer 處理不需要在解析當下就執行的腳本，用 async 處理可以獨立執行的第三方腳本；分析工具、客服外掛、非必要動畫這類，幾乎都能延後到主要內容顯示之後再載入，不該搶在前面跟主要內容爭執行緒。

CDN 補的是哪一段，不是萬能解方

四個原因之外，還有一個工具兩段都幫得上忙，那就是 CDN（內容傳遞網路）。它的原理是把靜態資源快取到世界各地離使用者較近的節點上，使用者連到最近的節點，連線往返的距離變短，TTFB 跟著降；圖片、CSS、JS 從近端拿，下載也更快，等於同時幫到 TTFB 與資源下載這兩段時間。

對主要服務台灣使用者的網站，CDN 能讓節點與快取拉近本地訪客，TTFB 會比較穩定；如果網站有海外訪客，效果會更明顯，因為遠端使用者原本的往返成本最高。

不過 CDN 不是萬靈丹。它擅長處理可以快取的靜態資源，對會員中心、購物車、即時庫存這類每次都得即時運算的動態頁面，幫助有限，這類頁面的 TTFB 還是得回到伺服器端的快取與最佳化去解。把 CDN 當成前面幾段診斷的補強，而不是拿它取代前面該做的功課。

改完之後，怎麼確認 LCP 真的達標？

做完前面幾段，最後要回到資料上驗收，而不是憑感覺。PageSpeed Insights 上半部通常是真實使用者資料，來自 Chrome UX Report（CrUX）；下半部才是 Lighthouse 的單次模擬測試。前者是 Google 判斷排名時真正依據的資料，每天彙整前 28 天的使用者體驗，需要累積一段時間才會反映改善；後者改完立刻能看到變化，適合拿來快速驗證修法有沒有方向對。兩者用途不同，不該混在一起看。

還有一個常被忽略的細節，如果某個頁面的流量不夠，PageSpeed Insights 抓不到足夠的真實使用者資料，就會退回顯示整個網域彙整後的數字。這時候不能直接斷言那一頁已經達標，只能說整個網域大致落在這個範圍，重點頁面流量夠了以後，還是要回頭看那一頁自己的資料。

驗收時記得手機與桌機分開看，優先看手機。也別急著在改完當下就緊盯 CrUX 有沒有變化，先讓 Lighthouse 確認修改方向是對的，真實使用者資料通常要等上一段時間才會跟上。

LCP 從來不是靠壓一次圖片就能解決的事，而是一條從伺服器吐出第一個位元組、到主要內容真正畫上畫面的完整時間鏈，四段各自有各自的預算，也各自有各自的修法。下次打開 PageSpeed Insights 看到紅字，先別急著換圖，而是先問自己，這條鏈到底卡在哪一段。