行動電商核心優化：在不換主機下修好 LCP、INP、CLS 的實作路線

行動電商核心優化：在不換主機下修好 LCP、INP、CLS 的實作路線

先結論：不必先換主機，先量頁面、優化主視覺圖片與第三方腳本，能在兩週內把 LCP/INP/CLS 大幅改善。 （本文以反例推理先列出常見錯誤做法，再逐項反駁並給出替代方案。）

看似合理但會失準的起手：先換主機或一刀切延後載入

許多人第一直覺是「主機慢」或「把所有資源都延後載入」，這兩種作法看起來合理：主機快了整站就快、資源延後載入可以減少初次阻塞。但實務常見反例顯示：主機延遲（TTFB）往往不是瓶頸，且把第一屏重要資源延後會讓 LCP 更差；把所有腳本一律推遲也會造成同意管理或必要功能缺失，反而提高 CLS。

反證要點：
– 如果 TTFB 在幾百毫秒範圍（例如 340 ms）且瀑布圖顯示最大資源是大圖檔，問題通常在圖片而非主機。
– 對於首屏主要內容，把主視覺設為 lazy/load=lazy 會延遲最大內容繪製（LCP）。
– 全部腳本延後（包括同意管理平台）會導致版面變動與 CLS 惡化。

替代策略總覽（優先級不可打亂）：先量、修 LCP（圖片）、再修 INP（腳本互動）、最後修 CLS（版面穩定）。

量測的正確起手式（第一天：先量，不要先改）

步驟：
1. 用 PageSpeed Insights 跑行動版，記下 LCP、INP、CLS 三個數字。
2. 開 Chrome DevTools 的 Network 面板，模擬 4G，重新載入並看瀑布圖。
3. 找出「最大內容」的資源（通常是主視覺圖），以及列出所有第三方外掛與腳本請求。

實務觀察（原案例）：在瀑布圖首屏看到一張 3.2MB 的 PNG，且 TTFB 為 340 ms，顯示主機不是主要瓶頸。

提示：實驗室分數（PageSpeed/PSI）是模擬，真正的判斷依據應以真實使用者資料（Search Console 的核心網頁指標報表，28 天滾動）為準；兩者差距大時，優先聽真實使用者。手機與桌機要分開看，多數問題出在手機端。

修 LCP（第二到第四天）：針對最大內容圖優先處理

錯誤做法：把所有圖片都設定成 loading=lazy，包括首屏主視覺。

為何錯：主視覺是最大內容繪製（LCP）的關鍵，延後載入會直接拉高 LCP。

正確步驟（範例來源於原案例）：
– 把主視覺 PNG 轉成 WebP（或 AVIF），並限定寬度上限為 1600 px；範例中檔案從 3.2MB 下降到 180KB。
– 對首屏主視覺加上 fetchpriority=”high”，並用 指定預載。
– 首屏以外的圖片全部加 loading=”lazy”；首屏不要 lazy。
– 將字型檔改成 woff2，並加入 font-display: swap，避免字體阻塞 LCP。

預期改善（原案例數據）：LCP 從 4.8 秒降到 2.1 秒（後續進一步優化可降至約 1.9 秒）。

注意與限制：圖片壓縮品質不要壓得太低（建議品質 75–80），避免影響商品色彩準確性與退貨率。

修 INP（第五到第八天）：把注意力放回使用者互動被阻塞的腳本

錯誤做法：把所有第三方腳本全部刪或全部延後不分主次。

為何錯：有些第三方（如必要的追蹤或廣告像素）雖然耗時，但對業務或合規仍有價值；直接刪除會引發內部衝突。相反，一刀切可能漏掉真正影響互動性的腳本優先級。

診斷與處理流程：
1. 列出所有第三方腳本（例如原案例載入了 11 支：聊天外掛、兩套熱區工具、三個廣告像素、問卷彈窗、評論外掛等）。
2. 每一支問：上個月有人看過它的報表嗎？誰在用？如果沒人在用就移除。
3. 把聊天外掛改為「使用者捲動到 30%」才載入，或以 click-to-load 方式延後。
4. 將廣告像素統一放入 Google 標籤管理（GTM）並用觸發條件延後。
5. 關閉非必要的視覺特效（例如主題附帶的滑動特效），可直接節省數百毫秒。

原案例成效：INP 由 420 ms 降到 140 ms（包含移除四支未使用腳本、延後載入、關閉特效等）。

實務建議：在移除前先溝通（別直接刪掉行銷部在用的追蹤碼），以免引發內部流程衝突。

修 CLS（第九到第十天）：穩定版面比動畫更重要

錯誤做法：把同意管理平台或廣告位設為晚載入，沒有保留高度和尺寸。

為何錯：當內容後載入導致畫面移動，使用者會誤觸、體驗受損，CLS 加分。某些延後策略會使 CLS 惡化。

修法清單：
– 所有 img 元素補上 width 與 height 屬性，讓瀏覽器預留版位。
– 廣告或嵌入區塊以 CSS 設定最小高度（min-height）或固定高度，避免未載入前推擠。
– 字體換載造成行高變動時，調整後備字體的 size-adjust 讓文字高度接近主字型。
– 將公告列改為固定高度，避免用動畫展開導致移位。

原案例結果：CLS 從 0.31 降到 0.04。

兩週完成後的驗收與數據追蹤

範例對照（修復前→修復後，來自原案例）：
– LCP：4.8s → 1.9s（門檻：2.5s 以內）
– INP：420 ms → 140 ms（門檻：200 ms 以內）
– CLS：0.31 → 0.04（門檻：0.1 以內）
– 行動版 PSI 分數：34 → 88（目標 75 以上）
– 跳出率：71% → 43%
– 首頁到加入購物車轉換率：1.6% → 2.3%

注意：Search Console 使用的是 28 天滾動資料，今日修好需等待約 3–4 週才能完全反映在後台報表；因此修復後應於每月一號例行量測並記錄三個指標，任何一項越線就開工單。

修完後的三個常見誤修與避免法

  1. 全部圖片都 lazy：首屏要優先載入，非首屏可 lazy。
  2. 壓縮過頭：品質降到 50 以下會影響商品色彩，建議保留 75–80。
  3. 全部腳本延後包含同意窗：同意窗若晚出現會導致 CLS 惡化，應保留必要載入或以佔位方式處理。

長期維護規則（避免速度倒退）

建議三條規則寫入網站維護手冊並嚴格執行：
1. 新圖片上傳前先壓縮，超過 1600 px 的一律縮小；首屏圖片採用 WebP/AVIF。
2. 新增第三方腳本前詢問：此工具帶來的價值是否大於 0.3 秒？答不出就不要裝。
3. 每月一號跑一次 PageSpeed Insights，把 LCP/INP/CLS 記入同一張表；連續兩個月退步就開會。

原案例補充：兩週內完成主要修復，第二個月再做三件事來鞏固：批次轉檔 437 張圖（容量從 186 MB 降到 62 MB）、重新排序/延後第三方腳本、字型改為自架以減少網域查詢。這些操作使首屏渲染時間再降低約 0.4 秒。

測量資料的選擇與邊界說明

  • 實驗室工具（PSI、Lighthouse）能模擬優化效果，但不能取代現場真實使用者資料。
  • Search Console 的「網站使用體驗核心指標報表」使用 28 天滾動資料，修復後需等一個滾動週期才能看到完整效果。
  • 手機與桌機應分開報告，多數電商瓶頸在手機端。

本文資料邊界：文章數字源自作者團隊實務紀錄與某客戶案例，具體改善幅度會因網站結構、使用者族群與行銷活動不同而異，請以自家實測為準。

限制與例外情況

  • 若主機 TTFB 遠高於數百毫秒（例如超過 1 秒以上）且瀑布圖顯示多數資源延遲，才應考慮主機升級或 CDN。
  • 若商業訴求需要在首屏載入特定第三方功能（例如合法合規的驗證），則需在優化計畫中保留該功能並尋找次優解（如非同步或 placeholder）。

常見問題（FAQ）

Q1：網站剛換到更快主機，還需要做圖片與腳本優化嗎？
A1：通常仍需要。主機改善能降低 TTFB，但 LCP 常受「最大內容資源」大小與格式影響，圖片與第三方腳本優化仍是必要步驟。

Q2：PageSpeed Insights 分數很高，為何 Search Console 的核心指標還是紅？
A2：PSI 是實驗室模擬，Search Console 用真實使用者 28 天資料。若兩者差距大，優先以真實資料為準，特別注意訪客裝置分佈（是否有大量舊手機）。

Q3：要多久才看得到修復效果？
A3：實驗室分數可立即看到；Search Console 的完整反映約需 3–4 週（28 天滾動）。修完後不要頻繁重改，記下修復日期以便比較。

Q4：我們可以把所有字型存放在外部 CDN 嗎？
A4：外部 CDN 能加速，但每多一個字型來源就多一次 DNS/TCP 查詢。自架字型並精簡字型組合（例如從四款降到兩款）常能實際加速首屏渲染。

Q5：哪些指標最先查？
A5：先查 LCP（首屏最大圖）、再查 INP（第三方腳本）、最後查 CLS（未設定寬高或延後載入的版位）。這三項能覆蓋約 80% 問題來源。

自助檢查清單（便於交付或內部溝通）

  1. 用 PSI 記下 LCP/INP/CLS（三項）。
  2. DevTools Network：過濾第三方請求並排序，找出最大圖檔和第三方腳本清單。
  3. 圖片動作：轉 WebP/AVIF、首屏 preload + fetchpriority、其他 lazy、補 width/height。
  4. 腳本動作：列清單→詢問使用頻率→移除沒人在用的→延後非必要腳本→GTM 統一管理廣告像素。
  5. CLS 動作：設定廣告與嵌入的最小高度、字體 fallback 微調、移除會引發高度變動的動畫。

下一步（內連參考）

若你想要把上述流程套用到自家網站，可從下列入口開始了解或預約：
– 服務介紹：顧問與技術執行 https://guanchengmartech.com/services/
– 成功案例概覽 https://guanchengmartech.com/cases/
– 預約諮詢或留下需求 https://guanchengmartech.com/contact/
– 常見問題與工具說明 https://guanchengmartech.com/faq/
– 關於團隊與專業背景 https://guanchengmartech.com/about/

本文屬實務指引，採反例推理（先說會誤導的做法，再逐項反駁並提出替代方案），旨在協助以行動為主的電商優先找出 LCP/INP/CLS 的真正瓶頸並建立長期監控機制。請以自身數據為準，執行前務必在測試環境驗證變動對商品顯示與功能的影響。

延伸閱讀：