把同一個頁面丟進 PageSpeed Insights，行動裝置分數 42，桌機 91。這種落差我看過太多次了。大多數人的反應是「行動裝置網速比較慢嘛」，然後開始壓縮圖片。這個方向沒錯，但資料告訴我們，它解決的問題比你想像的小很多。真正讓行動裝置 LCP 難壓的原因，藏在四段時間裡的另外兩個。這篇文章用 Chrome CrUX 的實地資料來解釋行動裝置 LCP 為什麼跟桌機差這麼多，然後走到可以直接複製的修法。
行動裝置 LCP 為什麼比桌機慢？數據告訴你答案
直覺上以為行動裝置 LCP 慢是因為手機下載圖片比電腦慢很多。但 Google Chrome 團隊在 2024 年分析了 CrUX 實地資料後，結論讓人意外：LCP 表現不佳的來源，行動裝置圖片載入時間只比電腦慢約 20%，而且圖片下載在整段 LCP 裡佔比不到 10%。
真正的差距在 TTFB 和資源載入延遲。以下是 LCP 表現「不佳」的網站，四段時間的中位數比較：
| LCP 子段 | 說明 | LCP 不佳（p75 中位數） | 主要差異來源 |
|---|---|---|---|
| TTFB | 第一個 HTML byte 抵達的時間 | 2,270 ms | 行動網路延遲、無 CDN edge node |
| 資源載入延遲 | TTFB 到瀏覽器開始載入 LCP 資源的時間 | 1,290 ms | 依附請求鏈（CSS background、lazy loading 誤用） |
| 資源載入時間 | LCP 圖片/資源的實際下載時間 | 350 ms | 圖片大小（行動比桌機慢約 20%，非 4 倍） |
| 算繪延遲 | 資源載入完成到元素畫出來的時間 | 360 ms | 行動裝置 CPU 較弱，layout + paint 更慢 |
TTFB 加資源載入延遲，兩段加起來佔了行動裝置 LCP 不佳案例的 70% 以上。圖片壓縮只動到 350ms 那段，而且已經是最短的一段。這不是說圖片優化不重要，而是說你的時間可能應該先投在 TTFB 和依附請求鏈上。
如果你的 TTFB 已經低於 800ms，可以直接跳到本文後面看 srcset 和 LCP 元素判斷。如果 TTFB 還在 1.5s 以上，TTFB 優化完整指南是更緊迫的第一步。
CPU 速度是行動裝置 LCP 的隱形殺手
算繪延遲（Render Delay）在行動裝置上比桌機更容易惡化，原因是 CPU 速度差距。Lighthouse 的行動裝置模擬預設用 4 倍 CPU 節流（throttle），代表用高階 MacBook 跑 Lighthouse 模擬行動裝置時，CPU 效能被故意壓成 1/4。
但這還不是最壞的情況。
當使用者用中低階 Android 手機持續瀏覽頁面，裝置內部溫度上升，觸發熱節流（thermal throttling）。CPU 和 GPU 降頻後，本來 200ms 就能完成的 layout + paint，可能拉到 500ms 以上。這種情況在 Lighthouse 模擬裡看不到，只有用真實裝置測才能捕捉到。
算繪延遲的常見原因：
- LCP 元素套用了 CSS 動畫或 transition，瀏覽器等動畫準備好才標記為「繪製完成」
- 大量 JavaScript 在主執行緒上阻塞，LCP 資源載入完成了但繪製還在排隊
- 使用
background-image作為 LCP 元素，瀏覽器無法提前發現它，必須等到 CSSOM 建立後才開始載入 - 字型使用
font-display: block導致文字 LCP 被延遲算繪（FOIT）
在 Lighthouse 報告裡，如果你的 LCP sub-part 裡算繪延遲超過 200ms，優先排查上述四個原因。行動裝置的 CPU 壓力讓每一毫秒的排隊時間都比桌機更痛。
行動裝置的 LCP 元素可能跟桌機不一樣
在桌機上，LCP 元素通常是橫幅 hero image。但在 375px 的手機螢幕上，同一個頁面的可視區域完全不同。有幾種情況會讓行動裝置的 LCP 元素跟桌機不一致：
- 桌機版 hero image 在手機版被隱藏（
display: none），瀏覽器改找下一個最大元素 - 手機版字型較大，導致某段文字變成 LCP 元素而非圖片
- 響應式版本換了完全不同的首圖（用 CSS background-image 切換），導致依附請求鏈更長
確認行動裝置 LCP 元素的方法：
- 打開 Chrome DevTools，點 Toggle device toolbar（Ctrl+Shift+M）
- 選 Moto G Power 或 iPhone 12 等手機尺寸
- Lighthouse 面板勾選 Mobile 模式，跑一次
- 在 Performance Insights 面板找到 LCP 標記，hover 確認是哪個元素
如果發現行動裝置 LCP 元素不是你以為的那個，整個優化方向就要跟著調整。這一步不做，後面的修法可能都打錯靶。相關的詳細診斷流程可以參考 LCP 元素識別指南。
怎麼量到真實的行動裝置 LCP？
Lighthouse 的行動裝置模擬是 lab data，跑在你的開發機上。它有用，但不等於真實用戶在手機上看到的數字。要拿到接近真實的行動裝置 LCP，有兩個方法：
方法一：WebPageTest 的行動裝置設定檔
WebPageTest 提供 Motorola G4（模擬中階 Android）+ 行動網路節流的預設設定。步驟：
- 前往 WebPageTest
- 「Test Location」選擇離你目標用戶最近的地點（例如 Japan/Singapore for TW sites）
- 「Browser」選 Chrome on Moto G4
- 展開「Advanced」，確認 connection 設 Slow 4G（12 Mbps download, 3 Mbps upload, 150ms RTT）
- 跑完後在 Web Vitals 區塊找 LCP，點開 filmstrip 確認 LCP 元素
方法二：PageSpeed Insights 的 CrUX 資料
PageSpeed Insights 同時顯示 lab data（Lighthouse）和 field data（CrUX）。看欄位資料時，注意幾個地方：
- PSI 預設顯示「Origin data」，是整個網域所有 URL 的合併資料
- 切換到 URL level 才看得到這個頁面的 LCP 資料
- PSI 現在預設顯示行動裝置的 CrUX 資料（因為 Google 以行動裝置為主評估）
- 如果 CrUX 樣本量不足（「未達門檻」），表示這個 URL 的行動裝置流量還不夠讓 Chrome 收集到足夠資料
想同時看行動裝置和桌機 LCP 的對比，可以用 Chrome CrUX API 或直接看 Search Console 的「Core Web Vitals」報告，裡面有行動裝置和桌機分開的通過率。
行動裝置首屏圖片的 srcset 實作與 LCP 改善
行動裝置圖片下載雖然只佔 LCP 的一小部分，但如果你的 hero image 在行動裝置上下載的是桌機用的 1920px 大圖，這 350ms 是可以壓掉一半的。正確的做法是 srcset + sizes，讓瀏覽器根據實際視窗寬度選擇最小的可用尺寸。
一個 blog hero image 的完整寫法：
<img
src="hero-800.webp"
srcset="
hero-400.webp 400w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-1600.webp 1600w
"
sizes="
(max-width: 768px) 100vw,
(max-width: 1200px) 80vw,
1200px
"
fetchpriority="high"
alt="行動裝置 LCP 優化示意圖"
width="1200"
height="630"
>幾個常見錯誤：
sizes寫錯或不寫，瀏覽器預設以 100vw 計算，等同於永遠選最大那張srcset只提供兩個尺寸，導致行動裝置在兩者之間挑到較大的那個- 同時加了
loading="lazy"和fetchpriority="high"，兩個屬性互相矛盾，瀏覽器行為不確定；hero image 要用 eager loading（預設）加 fetchpriority="high"
在一個 Next.js 部落格頁面的實測，把 hero image 從單一 1920px JPEG 改成上面的 srcset 組合後：
| 指標 | 修改前 | 修改後 | 變化 |
|---|---|---|---|
| 行動裝置 LCP | 4.1s | 1.9s | -2.2s |
| LCP 圖片大小 | 420 KB (1920px JPEG) | 89 KB (400px WebP) | -79% |
| 資源載入時間（Slow 4G 測試） | ~680ms | ~145ms | -535ms |
這個案例 LCP 壓了 2.2s，是因為原本的圖片大到連 350ms 都撐不住。如果你的 hero image 已經是 WebP 且在 200KB 以下，圖片那段的改善空間就有限了，還是回去看 TTFB 和依附請求鏈。
關於 fetchpriority="high" 的正確設定與診斷流程可以看另一篇更詳細的說明。
iOS 和 Android 的 LCP 測量差異
在台灣，iOS（iPhone + Safari）的市佔比相當高，但 Chrome CrUX 的行動裝置 LCP 資料主要來自 Android Chrome，iOS 用戶的 LCP 數據有結構性缺口。
Chrome CrUX 的行動裝置資料，主要來自 Android Chrome。 iOS 上的 Chrome 使用 WKWebView（Apple 的 WebKit 引擎），不是 Blink，因此不完整支援 Largest Contentful Paint API（PerformanceObserver 的 largest-contentful-paint 條目）。CrUX 主要依賴 Android Chrome 用戶資料。
實際影響：
- 如果你的台灣用戶有 50% 在用 iPhone，你在 CrUX 看到的「行動裝置 LCP」代表性是有缺口的
- Safari on iOS 的 LCP 計算可能跟 Chrome 有差異，特別是 background-image 和 SVG 元素的處理
- 要測 iOS 的 LCP，目前最可靠的方式是用 web-vitals JavaScript library，它會嘗試在 iOS 上模擬 LCP 測量
如果你的目標是「讓行動裝置 CrUX LCP 進入 Good 區間」，優化 Android Chrome 的體驗是優先。如果你有大量 iOS 用戶且想追蹤他們的實際體驗，需要搭配 RUM（Real User Monitoring）工具，例如 web-vitals library + GA4，不能只看 PSI。
CDN 選擇對行動裝置 TTFB 的影響，特別是 edge node 覆蓋台灣的問題，可以參考 CDN 改善 LCP 的機制與實測。
行動裝置 LCP 優化檢查清單
行動裝置 LCP 問題通常是 TTFB 慢、依附請求鏈長、LCP 圖片未優化三個原因疊加。以下清單把行動裝置特有的修法按優先順序整理，從最高影響開始排查。
| 優先級 | 檢查項目 | 工具 | 目標值 |
|---|---|---|---|
| P0 | 確認行動裝置 TTFB < 800ms | PSI / WebPageTest | < 800ms |
| P0 | 確認行動裝置 LCP 元素是哪個（用 DevTools mobile mode） | Lighthouse Mobile | 已識別 |
| P1 | LCP 元素有 fetchpriority="high"，沒有 loading="lazy" | HTML 程式碼審查 | 通過 |
| P1 | hero image 有 srcset + sizes，行動裝置取 < 150KB 的版本 | DevTools Network / srcset 實作 | < 150KB |
| P1 | LCP 元素不是 CSS background-image（改用 <img>） | HTML 審查 | 通過 |
| P2 | LCP 元素沒有 CSS animation / transition 干擾算繪 | DevTools Performance | 通過 |
| P2 | 用 WebPageTest Moto G4 + Slow 4G 測試，確認真實行動裝置 LCP | WebPageTest | LCP < 2.5s |
這份清單是針對行動裝置特有的問題。完整的 LCP 修法（包含 TTFB 的六段診斷、CDN 設定、render-blocking 消除），可以回到 LCP 優化實戰：四段時間模型幫你找到瓶頸 的主文。
行動裝置 LCP 的問題常常不是一個原因，而是幾個原因疊加。TTFB 慢 + hero image 太大 + 缺少 fetchpriority，三個加在一起很容易讓行動裝置 LCP 超過 4s。拆開來看，每個改動可能只差 0.5s，但加在一起就可以從「需要改善」進到「良好」。