先講一句得罪工程師的話：大多數電商站的速度優化之所以沒效，是因為根本沒找到兇手就開始動刀。大家習慣打開 PageSpeed Insights，看到那個分數是紅的就開始亂改——壓圖、裝快取外掛、換主機——改完分數從 52 跳到 78，開心收工。可是實際用手機開商品頁，主圖還是慢半拍才浮出來，點「加入購物車」還是要等一下才有反應。
為什麼？因為 PageSpeed 那個總分是「實驗室分數」，是 Google 用一台模擬中階手機、模擬 4G 網路跑出來的成績，跟你真實客人拿 iPhone 走在路上開你的站，是兩回事。分數是給你看爽的，真正決定 SEO 排名與轉換的，是真實使用者的 CWV 數據。這篇文章不重複「速度為什麼重要」那套（那個我們另一篇 電商網站速度與 Core Web Vitals 講過了），這裡只教一件事：怎麼像法醫驗屍一樣，把慢的原因一項一項揪出來、一項一項修掉。
速度斷案四迴圈：別治頭痛醫頭
我們在 ECPRO 電商博士編輯部拆解過上萬個站的效能報告，整理出一套可重複的流程，內部叫它「速度斷案四迴圈」。四個字：立案、驗屍、動刀、結案。任何一次速度優化都跑這個圈，跑完一圈再跑下一圈，永遠不要跳步。
- 立案（量測）：分清楚實驗室數據和真實數據，確認你要修的是真問題還是假問題。
- 驗屍（歸因）：找出「那一個」拖慢頁面的兇手元素，不是一堆籠統建議。
- 動刀（修復）：針對這個兇手，用對應手法逐項修。
- 結案（回測）：改完馬上重測同一頁，確認這一刀有效，才收工進下一圈。
這套流程最反直覺、也最關鍵的一點是：你一次只能修一個兇手，改完立刻回測，否則你永遠不知道剛剛那三小時到底哪個動作有用。我看過太多團隊一個下午改十項，分數確實動了，但沒人說得出是哪一項起作用，下次遇到同樣狀況只能再瞎改一次。
立案：先分清楚你在看哪一種數據
斷案第一步不是修，是搞清楚「證據來源」。CWV 有兩套數據，很多人一輩子都搞混：
| 比較項 | 實驗室數據（Lab） | 真實使用者數據（Field / CrUX） |
|---|---|---|
| 來源工具 | Lighthouse、PageSpeed 上半部 | CrUX 報告、PageSpeed 下半部、GSC |
| 怎麼來的 | 模擬一台手機跑一次 | 過去 28 天真實 Chrome 用戶回傳 |
| INP 有沒有 | 沒有（Lab 只有替代指標 TBT） | 有，這才是真的 INP |
| Google 排名看哪個 | 不看 | 看這個 |
| 適合拿來做什麼 | debug、找兇手 | 判斷有沒有真的過關 |
結論很簡單：判斷「過沒過關」看 Field 數據，找「兇手在哪」用 Lab 工具。兩者角色不同，不能互換。舉個常見的坑（範例）：某服飾站 Lighthouse 跑 92 分很得意，可是 Search Console 的核心網頁指標報告顯示「行動裝置有 63% 網址未達標」，因為真實客人多半在捷運上用不穩的網路開站，Lab 那台模擬手機根本測不到這種情況。
立案階段要做的事：
1. 到 PageSpeed Insights 輸入首頁、分類頁、商品頁、購物車四個代表頁，只看「下半部真實使用者體驗」那塊有沒有紅色。
2. 到 Search Console 開「核心網頁指標」報告，看它幫你把「未達標網址」分成哪幾群——通常同一個範本的頁面會一起爛，這就幫你鎖定要修哪個範本。
3. 把手機和桌機分開看。台灣電商流量手機普遍七成以上，手機沒過關等於沒過關，桌機再漂亮都不算數。
驗屍：把那一個兇手揪出來
這是整套流程最值錢、也最多人跳過的一步。多數人量完數據就直接照 PageSpeed 那串「改善建議」逐條做，但那些建議是通用清單，不等於你這頁真正的瓶頸。真正的驗屍要動用瀏覽器內建工具。
驗 LCP：先問「最大那塊是誰」
LCP（最大內容繪製）慢，第一件事不是壓圖，是先確認「你頁面上被判定為 LCP 的那個元素到底是哪一個」。打開 Chrome DevTools → Performance 面板 → 錄一次載入，時間軸上會直接標出 LCP 的那個節點，滑鼠移上去會反白頁面上對應的元素。九成的人以為兇手是主圖，實際驗下去常常是一段還沒載完的自訂字體，或一個被 JS 撐到很晚才塞進來的橫幅。
找到 LCP 元素後，再看它的載入瀑布圖（DevTools Network 或 WebPageTest 的 waterfall），把它的時間拆成四段來歸因：
- TTFB（伺服器回應）：從點下去到收到第一個位元組。這段肥，兇手在後端／主機／快取，壓圖沒用。
- 資源載入延遲：瀏覽器多久之後才「發現」要載這張圖。這段肥，通常是圖被寫在 CSS 背景或靠 JS 才插入，瀏覽器太晚知道。
- 資源載入時間：圖本身下載花多久。這段肥才是真的「圖太大」，這時壓圖才對症。
- 渲染延遲：載完到畫出來之間。這段肥常是被 render-blocking 的 CSS / JS 卡住。
（估算）一張 2.4MB 的商品主圖轉成 WebP 大約掉到 300–500KB，在 4G 下第三段可能省下 1 秒以上；但如果你的 LCP 慢是卡在第一段 TTFB 1.8 秒，壓圖壓到死也只是原地踏步。驗屍的意義就是不讓你把力氣花在沒有出血的地方。
驗 INP：抓那一次卡頓的長任務
INP（互動到下次繪製）取代了舊的 FID，它量的是使用者每次點擊、輸入之後，畫面多久才有反應，Google 抓的是整場 session 裡偏慢的那幾次。要驗它，用 DevTools Performance 面板錄下「真的去點那個按鈕」的過程，時間軸上出現紅色三角形標記的就是「長任務（Long Task，超過 50 毫秒的 JS 執行）」——那就是卡住主執行緒、讓你點下去沒反應的兇手。
電商站 INP 的兇手排行榜（實測觀察）：第三方追蹤碼在你點擊時同步跑一堆事件、肥大的前端框架 hydration、每次互動都重算整個購物車的低效 JS。INP 不是網路問題，是你的 JavaScript 太貪心，一次做太多事把主執行緒佔死了。
驗 CLS：錄影慢動作看誰在跳
CLS（累積版面位移）最好驗——DevTools Performance 面板錄載入時，勾選「Layout Shifts」軌道，它會把每一次位移用紅框框出來，並告訴你是哪個元素在跳。常見兇手：沒設寬高的圖片、晚到的廣告位、字體從備援跳成正式字體那一下、以及「載入中」骨架和真內容尺寸對不上。
動刀：對症逐項修復對照表
驗屍找到兇手之後，動刀就有標準答案了。這張表把「症狀 → 兇手 → 該下哪一刀」對起來，照著修不會亂槍打鳥。
| 壞掉的指標 | 驗屍找到的兇手 | 對應動刀 |
|---|---|---|
| LCP（第一段肥） | TTFB 高，伺服器慢 | 開 CDN、頁面快取、升級主機、啟用 brotli 壓縮 |
| LCP（第二段肥） | 圖太晚被發現 | LCP 圖加 fetchpriority="high"、用 preload、別對首屏圖 lazy load |
| LCP（第三段肥） | 圖檔真的太大 | 轉 WebP／AVIF、依 srcset 給對應尺寸、拿掉首屏自動輪播 |
| LCP（第四段肥） | CSS／JS 擋渲染 | 關鍵 CSS 內聯、非關鍵 JS 加 defer、字體 preconnect |
| INP 高 | 長任務卡主執行緒 | 拆分長任務、第三方碼延遲初始化、減少互動時的重算 |
| CLS 高 | 元素沒預留空間 | 圖片影片都給 width/height 或 aspect-ratio、廣告位先留高、font-display: swap |
幾個台灣電商最常踩、又最好修的實務點，特別拉出來講：
- 首屏主圖千萬別 lazy load：很多外掛「貼心地」對全站圖片一律 lazy，結果連 LCP 那張都延後，適得其反。首屏主視覺要
loading="eager"甚至 preload，首屏以下的才 lazy。 - 中文字體一定要子集化：一套完整中文字體動輒 3–5MB，等於在頁面上綁一顆炸彈。只保留實際用到的字重，做 subset，或乾脆用系統字體堆疊（例如「PingFang TC」開頭那串），LCP 和 CLS 一起受惠。
- 第三方碼用「互動後再載」：客服 widget、聊天機器人、評論外掛不必開頁就載。改成使用者捲動或點擊後才初始化，INP 立刻好轉。若你正在選對話式客服，挑方案時把「支援延遲載入」列進必要條件，可參考我們整理的 聊天機器人選型工具。
- 用 GTM 統一管標籤，並定期清屍：追蹤碼散落各處是 INP 的慢性病。集中到 GTM，每季盤點一次，把停用活動的像素、重複的分析碼砍掉。
結案：改一項、測一項，別偷懶
動完一刀，立刻回到同一頁重跑 Lab 工具，確認那個兇手的時間段真的縮短了，再進下一圈。這裡有個大家常忽略的時間差：Lab 數據改完馬上看得到，但決定 SEO 的 Field 數據要等 28 天滾動視窗慢慢反映。所以修完別急著宣布勝利，Search Console 的核心網頁指標報告通常要兩三週後才會由紅轉綠。
破一個常見迷思：「分數 100 分」不是目標，「Field 數據三項都在良好區間」才是。為了衝 Lighthouse 那最後幾分去做過度優化（例如把該有的功能都砍了），常常是撿了芝麻丟了西瓜。你要的是真實客人開得順、下得了單，不是一張漂亮的成績單截圖。
想先知道自己站上掛了哪些會拖慢速度的技術與外掛、用的是哪家主機與 CDN，可以用我們的 技術檢測工具 掃一次，先有全貌再開始跑四迴圈。名詞看不懂就查 電商術語表，更多實戰案例都在 ECPRO 部落格。
劃重點
- 優化前先分清楚 Lab 與 Field 數據：找兇手用 Lab，判斷過關看 Field；Google 排名只認 Field。
- 跑「速度斷案四迴圈」：立案（量測）→ 驗屍（歸因）→ 動刀（修復）→ 結案（回測），一次只修一個兇手。
- LCP 別急著壓圖，先用瀑布圖把時間拆成四段，哪一段肥就修哪一段，才不會白做工。
- INP 是 JavaScript 病不是網路病，抓長任務、把第三方碼改成互動後再載。
- CLS 靠「事先預留空間」根治：圖片影片給寬高、廣告位先留高、字體用 swap。
- 目標是 Field 三項都在良好區間，不是 Lighthouse 100 分；改完等兩三週再看 Search Console。
常見問題
Q1：PageSpeed 分數 90 分以上，為什麼 Search Console 還說我沒過關？
因為兩者看的數據不同。PageSpeed 上半部的分數是實驗室模擬，Search Console 看的是過去 28 天真實使用者的 CrUX 數據。真實客人的網路和裝置千百種，比模擬環境更嚴苛，所以 Lab 高分、Field 未達標很常見。以 Field 為準。
Q2：我一次把圖片、腳本、字體全改了，分數有進步，這樣不行嗎？
能上就好但你學不到東西。全改一起上，你無法得知是哪個動作真正有效、哪個其實沒用甚至反效果，下次遇到問題只能再賭一次。一次修一個兇手、改完回測，才能累積出「什麼手法對什麼症狀有效」的判斷力。
Q3：LCP 一直過不了，我圖都壓到很小了還是慢？
代表兇手不在「圖太大」這一段。用 DevTools 或 WebPageTest 看 LCP 元素的瀑布圖，如果慢在 TTFB（伺服器回應）或渲染延遲（被 CSS/JS 擋住），壓圖再多都沒用，要去修後端快取或解除 render-blocking 資源。
Q4：INP 該怎麼修，是不是換主機就好？
不是，INP 幾乎和主機無關，它是前端 JavaScript 的問題。你的頁面在使用者點擊時跑了太多同步的 JS（常見是第三方追蹤碼、框架 hydration、購物車重算），把主執行緒佔滿導致畫面沒反應。解法是拆分長任務、把非必要腳本延遲到互動後載入。
Q5：手機和桌機的 CWV 差很多，我該優先顧哪個？
顧手機。台灣電商流量手機普遍佔七成以上，Google 也以行動版為主要索引依據。桌機分數再漂亮，只要行動版未達標，SEO 和轉換都拿不到分。所有量測與驗屍都以手機情境為主戰場。