改版後 LCP 主圖怎麼抽樣：對得到檔案，不保證分數
文章摘要
改版後抽樣首屏主圖的檔案路徑、尺寸與是否被 CSS 背景吃掉。抽樣通過只代表主圖對得到，不能保證 Lighthouse 分數、Core Web Vitals 或排名。
改版後 LCP 主圖怎麼抽樣：對得到檔案，不保證分數
作者：平白設計編輯部｜發布與最後查證：2026-08-26｜適用：台灣（中華民國）｜技術資訊，不保證搜尋排名
網站剛上線或完成重大改版時，團隊最常問的問題就是：「為什麼 Lighthouse 跑出來的 LCP 時間還是不理想？」很多時候我們花了很多力氣優化圖片格式、壓縮檔案大小，卻忽略了最基礎的「身分確認」問題。這篇文章要談的不是如何把分數衝到綠色區間，而是更底層的檢查邏輯：你以為的首屏主圖，真的是瀏覽器眼裡的那張嗎？
我們必須釐清一個觀念：抽樣檢查通過，只代表開發團隊交付的檔案路徑、格式與載入策略符合設計預期，也就是俗稱的「對得到檔案」。這並不保證 Lighthouse 的分數會變好看，也不代表 Core Web Vitals 的真實使用者數據一定會達標。但在進入複雜的效能調校之前，確保我們正在優化的對象是正確的，是所有工作的起點。
先抽哪一張主圖
LCP（Largest Contentful Paint）的判定機制非常動態，它會隨著視窗寬度、裝置像素比以及網路環境而改變。因此，在進行抽樣檢查時，千萬不能只盯著設計師提供的桌面版高解析度稿看。首要任務是確認在不同斷點（Breakpoints）下，瀏覽器實際渲染出的 DOM 元素，是否為我們預期中那張負責吸引目光的主圖。
這裡有一個常見的陷阱：許多視覺效果華麗的首屏區塊，是使用 CSS background-image 來實作的。雖然這樣做在排版上很有彈性，但從瀏覽器載入優先級的角度來看，背景圖片被判定為 LCP 候選元素的機率與權重，通常低於直接使用 <img> 標籤嵌入的圖片。
建議從兩個極端視角入手進行檢查：一是行動版（例如 375px 寬），二是桌面版（例如 1440px 寬）。打開瀏覽器的開發者工具，檢視位於 viewport 上方的最大內容區塊。如果你發現行動版載入的竟然是與桌面版相同的高解析度大圖，即便檔案路徑完全正確，這張圖也會因為體積過大而拖慢 LCP。
每一列要記什麼
建立抽樣表格時，如果只記錄圖片的 URL，那這份資料的價值非常有限。為了讓後續的效能除錯有據可依，我們需要記錄更多影響載入行為的關鍵屬性。這些數據能幫助開發者快速判斷，目前的瓶頸是出在資源本身的大小，還是渲染順序的配置錯誤。請務必區分圖片是透過 HTML 標籤直接嵌入，還是由 JavaScript 動態注入，這兩者的處理邏輯截然不同。
以下表格整理了我們在內部審查時建議追蹤的欄位。這些項目看起來瑣碎，但當 LCP 表現不佳時，它們就是排除法的第一步。特別是 Preload 狀態與響應式來源這兩項，往往是決定圖片能否在第一時間被瀏覽器抓取的关键。
| 檢查項目 | 說明與注意事項 |
|---|---|
| 元素選擇器 | 例如 .hero-banner img 或 #main-visual，用於精確定位 DOM 節點，避免選錯對象。 |
| 最終檔案 URL | 確認是否指向 CDN 的正確版本，避免因瀏覽器快取而誤判為舊圖或測試圖。 |
| 圖片格式 | 檢查副檔名或伺服器回傳的 Content-Type，如 WebP、AVIF 或傳統 JPEG/PNG。 |
| 載入方式 | 區分為 <img> 標籤、CSS background-image 或 JS 動態生成，優先級不同。 |
| Preload 狀態 | 檢查 <head> 中是否有對應的 rel="preload" 宣告，以及 as 屬性是否正確。 |
| 響應式來源 | 確認 srcset 或 picture 標籤是否根據螢幕密度與寬度提供合適尺寸的檔案。 |
記錄這些屬性的目的，是為了在後續效能調校時能有明確的著力點。若發現關鍵主圖缺少 preload 提示，或被錯誤地標記為 loading="lazy"，這些都是可以在不更動視覺設計的前提下，立即修正的技術債務。然而，請記住，修正這些項目僅是打好基礎建設，不代表最終的效能指標就會自動變得優異。
驗完仍不能推論的事
即使所有主圖的檔案路徑正確、格式現代且具備 preload，我們仍無法保證 Lighthouse 的分數會變成全綠。LCP 本質上是一個「時間」指標，它受到伺服器回應速度（TTFB）、資源下載頻寬以及主執行緒阻塞情況的多重影響。
此外，Core Web Vitals 的評分依據主要是真實使用者監控（RUM）數據，而非單一的實驗室測試結果。不同使用者的裝置效能、網路穩定度與地理位置都會導致數據出現巨大差異。一台最新的旗艦手機與一台五年前的入門機，在處理同一張圖片時的解碼時間可能相差數倍。
我們也不應將此檢查結果作為對客戶承諾具體分數的依據。效能優化是一個持續的過程，而非一次性的交貨項目。當我們說「檔案對得到」時，意思是我們排除了人為配置錯誤的可能性，但這只是漫長優化之路的第一步。真正的挑戰在於如何在複雜的真實網路環境中，保持穩定的載入體驗。
常見問題
為什麼我的主圖已經加了 preload，LCP 還是很久？
Preload 僅能讓瀏覽器更早開始請求資源，但若伺服器回應緩慢或圖片檔案本身過大，下載時間依然會很長。此外，若 CSS 或 JavaScript 阻塞了渲染樹的建構，瀏覽器即使下載完圖片也無法立即繪製，這會延遲 LCP 的時間點。請檢查是否有大量的同步腳本阻擋了主執行緒。
CSS 背景圖片適合做 LCP 元素嗎？
通常不建議。CSS 背景圖片的載入優先級較低，且難以透過 fetchpriority 等屬性直接控制。若希望某張圖片成為 LCP 候選者，使用 <img> 標籤並搭配適當的 srcset 會是更穩定且易於優化的做法。如果必須使用背景圖，請確保沒有其他更高優先級的資源競爭頻寬。
抽樣通過後，我需要多久重新檢查一次？
建議在每次重大改版或上線新的行銷活動頁面後重新抽樣。由於 CMS 內容更新或第三方腳本插入可能意外改變 DOM 結構，定期確認能確保 LCP 候選元素未發生非預期的漂移。若網站架構穩定，可隨每季度的效能健檢一同進行。
延伸閱讀
先做網站健檢，再決定優化方向
不承諾保證排名。由屏柏企業 SEO 顧問與網頁工程師方士軒 mars 協助您評估網站速度、行動版可用性、SEO 關鍵字結構與內容層級問題。