Shopify 網站變慢時，直接刪 App、換 Theme 或做 Headless 都太早。先確認哪個市場、裝置、頁型和指標退步，再找出真正的載入路徑。首頁 Lighthouse 分數只是一次實驗室測量，不能代表所有顧客和商品頁。
速度診斷需要固定版本與日期。活動素材、第三方服務和流量組成都會變，沒有基準就無法證明修正有效。
先看真實使用者資料
Shopify Web Performance Dashboard 與 Chrome UX Report 可提供 field data，依頁面和裝置觀察 LCP、INP、CLS。先找出退步開始的時間、影響比例和主要 template。若商店流量太少，再用 Lighthouse 或 WebPageTest 補充線索，但要使用相同裝置、地點和網路條件比較。
不要只看總分。LCP 反映主要內容出現速度，INP 關注互動回應，CLS 處理版面移動，三者需要不同修法。
找出 LCP 元素和四段時間
在瀏覽器 Performance 或 Lighthouse 查看 LCP 是主圖、標題、商品圖片還是其他內容。再把時間拆成 TTFB、資源載入延遲、下載時間和元素渲染延遲。不同段落對應不同處理方式。
主圖很小卻很晚才開始下載，問題可能是 JavaScript 或 CSS 延遲發現；檔案本身很大，則需調整格式、尺寸與 srcset。Above-the-fold 圖片不應 lazy load，低於首屏的圖片才適合延遲載入。
檢查 Theme JavaScript 與 CSS
找 parser-blocking script、長任務、未使用程式和重複 library。Shopify 的 Theme 效能指南建議主要功能優先使用 HTML、CSS 和原生瀏覽器能力，並以 progressive enhancement 加入 JavaScript。
大量 CSS 也會延遲渲染。依 template 或 section 拆分必要樣式，使用 Theme Check 找跨檔依賴和遠端資源。不要為了分數任意延遲購物車或變體等關鍵功能。
逐一量測 App 和第三方標籤
評論、聊天、推薦、A/B 測試、廣告 Pixel 和 tag manager 都可能加入 network request 與 main-thread 工作。用 request initiator 和 script URL 對應供應商，再在副本或受控環境做停用比較。完整盤點可沿用 Shopify App audit。
同意管理也會影響載入時機。不能為了速度繞過 consent；應讓非必要標籤在合法同意後載入，並移除重複事件與無人使用的供應商。
圖片、字型和影片常被低估
使用 Shopify CDN、image_url 和 image_tag 產生 responsive images，設定正確 sizes，避免手機下載桌面大圖。限制首屏輪播和自動播放影片，並為影片提供 poster。字型只載入需要的字重與字元，設定合理 fallback 以降低版面位移。
素材流程要有規格。每次活動都上傳未壓縮圖片，單次修正很快又會失效。
一次改一組原因並驗證
先處理影響大、風險低的項目，例如過大 LCP 圖片、重複 script 和未使用 App，再重跑相同測試。記錄變更前後的 URL、版本、環境和指標。正式發布後等待足夠 field data，確認真實使用者也改善。
設定效能預算和發布護欄
為首頁、集合與商品頁設定 JavaScript、圖片、第三方請求和 Core Web Vitals 的基準範圍。新增大型素材或 App 時，在 Theme preview 做同條件比較；超出護欄就要求壓縮、延遲非必要功能或重新評估需求。護欄應依商店實際資料調整，不需要追求一個通用滿分。
把檢查放進每次重要發布，而非等顧客抱怨才重做診斷。Theme 更新、大促、追蹤工具和推薦功能都是常見變更點，保留版本標記後，field data 退步時才能對應到事件。
用商業分群避免誤判
分別看行動與桌面、主要市場、入口頁和新舊裝置。整體平均改善可能掩蓋高營收市場退步；某地區網路較慢，也可能更容易暴露過大的資源。診斷結果應連回受影響旅程，再排修正優先級。
速度改善不能破壞可用性、追蹤或收入流程。每次發布都跑商品選擇、購物車與付款 smoke test。若問題來自明確的 Theme 或 App，可以局部修正；只有當架構限制持續阻擋已量化需求時，才重新評估 Headless Shopify。