很多人打開 PageSpeed Insights，看到電腦版分數漂亮就放心了，卻沒注意到同一頁切到「行動裝置」分頁時分數掉了三、四十分。這不是工具出錯，而是 WordPress 行動版速度優化本來就是一個獨立的戰場。Google 採用行動優先索引，真正拿去評估排名的是手機版本，而手機的處理器、網路、螢幕條件全都比桌機嚴苛得多。

桌機測出來的好成績，常常只是把問題藏起來。中階 Android 手機在 4G 連線下載入同一頁，CPU 解析 JavaScript 的速度可能只有桌機的幾分之一，render-blocking 的資源一多，使用者就盯著一片空白等好幾秒。

這篇不談「裝個外掛一鍵加速」那套，而是把行動版兩個最關鍵的體驗指標拆開講：最大內容繪製（LCP）為什麼在手機上特別慢，互動延遲（INP）又為什麼是行動裝置的重災區，以及每一項該照什麼順序動手、改完怎麼確認真的變快。

為什麼同一個網站桌機很快、手機卻慢

差異的根源是硬體與網路，不是你的錯覺。桌機通常是有線或穩定 Wi-Fi、處理器強、記憶體充足；手機則是行動網路（4G／5G 都會有訊號抖動與延遲）、處理器運算力弱、記憶體有限。同一份 JavaScript，桌機跑起來不費力，到了中階手機就會卡住主執行緒，畫面遲遲沒反應。

「響應式」不等於「行動版很快」，這是最常見的誤解。響應式設計只保證版面會隨螢幕縮放，它不會自動幫你壓縮圖片、不會自動拿掉沒用到的程式碼。一個 WooCommerce 商品頁在手機上看起來排版正常，但如果它載入的是桌機尺寸的大圖、跑著一堆複雜動畫，照樣慢。

行動版變慢的典型原因可以歸成幾類：

• 載入太多、太早：一次塞進大量 JavaScript、沒用到的 CSS、好幾支第三方腳本，瀏覽器還沒畫出主要內容就先被卡住。
• 圖片給錯尺寸：把 2500px 的桌機主視覺原封不動丟給 390px 寬的手機螢幕，頻寬白白浪費。
• 伺服器回應慢：首位元組時間（TTFB）過高，後面所有優化都救不回來。
• 版面跳動：圖片沒設寬高、字型晚到，內容載入時東西亂跳，使用者剛要點按鈕就被擠走。

把這幾類對號入座，後面的改善就有方向，而不是亂槍打鳥。

手機端要盯的三個體驗指標與量測方式

先記住目標數字，後面才知道改到哪裡算過關。Google 的核心網頁指標（Core Web Vitals）有三個門檻，都以真實使用者資料的第 75 百分位來判定：最大內容繪製（LCP）要在 2.5 秒以內、互動至下次繪製（INP）要在 200 毫秒以內、累計版面配置位移（CLS）要在 0.1 以內。

這三個指標各自對應一種體感。LCP 是「最大那塊內容（通常是主視覺圖或大標題）多久才出現」；INP 量的是「使用者點了按鈕或選單之後，畫面多久才有反應」，它取整段瀏覽期間最慢那幾次互動，比舊的首次輸入延遲（FID）更貼近真實；CLS 則是「東西載入時有沒有亂跳」。

量測手機速度最容易踩的坑，是只看實驗室資料（lab data）。實驗室資料是 Lighthouse 或 GTmetrix 在受控環境模擬一次載入的結果；真正影響排名的是現場資料（field data），也就是 Chrome 使用者體驗報告（CrUX）蒐集的真實裝置、真實網路數據。一個頁面在實驗室拿 90 分，現場資料卻可能因為真實用戶手機較慢、網路較差而不及格。

實務上的量測流程建議這樣跑：

• PageSpeed Insights：同時給實驗室分數與 CrUX 現場資料，務必切到「行動裝置」分頁，並且測重要的內頁，不要只測首頁。
• GTmetrix：用它的瀑布圖看哪個資源在擋載入，測試設定挑中階 Android 裝置與行動網路節流。
• Chrome DevTools：在 Performance 面板把 CPU 設成 4 倍降速、網路設成「Fast 4G」，模擬真實手機條件，再看哪些是超過 50 毫秒的長任務（Long Task）。
• 多地點測試：若客群在台灣，盡量用支援台灣節點的工具（例如 WebPageTest、SpeedVitals 部分方案）測，才看得到實際的延遲。

分數本身不是重點，報告裡的「診斷」「改進項目」與現場資料才是動手的依據。

手機 LCP 偏慢的常見原因與改善順序

LCP 慢通常不是單一原因，而是一條鏈卡住了。改善時照「從伺服器往前端」的順序處理，效益最高、最不會白工。

第一步、先看伺服器回應（TTFB）。 沒有任何前端優化能補救一台慢伺服器。健康的 TTFB 在 CDN 邊緣節點大約落在 100 到 300 毫秒之間，超過 600 毫秒就代表伺服器端有問題。對 WordPress 來說，最直接的解法是開啟頁面快取，把預先產生好的靜態 HTML 直接吐給訪客，而不是每次都重新組一次頁面；資料庫查詢頻繁的動態頁，再加上物件快取（Redis 或 Memcached）。台灣客群建議選有台灣機房或鄰近節點的主機，地理距離直接反映在延遲上。

第二步、確認手機版的 LCP 元素是哪一個，再優先載入它。 手機與桌機的 LCP 元素常常不一樣，因為版面重排後，最大那塊內容可能換成另一張圖或一段標題。找到它之後，最高效益的單一動作就是替主視覺圖加上預先載入：在文件 head 放 preload 連結並標記 fetchpriority="high"，告訴瀏覽器「這張先抓，別等整份 HTML 解析完」。這一招在許多實測中能讓 LCP 改善數百毫秒。

第三步、絕對不要對主視覺圖做延遲載入。 這是手機 LCP 最常見的殺手。把 loading="lazy" 加到首屏的主圖上，等於要瀏覽器晚一點才去抓最重要的視覺，中階手機上常因此把 LCP 拖過 4 秒。延遲載入只用在首屏以下、使用者要捲動才看得到的圖。

第四步、處理擋畫面的 CSS 與字型。 把首屏需要的關鍵 CSS 抽出來直接內嵌進 head，其餘樣式表延後載入，省掉一次擋渲染的請求。字型則用 font-display: swap 並預先載入關鍵字型檔，避免文字遲遲不出現、或載入後又跳一次版。

把這四步照順序走完，LCP 通常就能從紅色區間拉回綠色，而且每一步都能在 PageSpeed Insights 的診斷裡看到對應項目被標記為通過。

圖片在行動版該怎麼處理才不拖速度

圖片幾乎是行動版頁面最重的部分，也是最快見效的優化點。重點不只是「壓縮」，而是一整套針對手機的決策。

改用新世代格式。 WebP 在同等畫質下大約比 JPEG 小 25% 到 35%，AVIF 往往能再省到一半左右，現行的手機瀏覽器都支援。WordPress 端可用 Imagify、ShortPixel、EWWW 這類外掛在伺服器層自動轉檔，不必手動處理每張圖。

用 srcset 與 sizes 讓瀏覽器挑對尺寸。 把一張 1400px 寬的圖丟給 390px 的手機螢幕，是純粹的頻寬浪費。設好 srcset，瀏覽器會依裝置自動選最合適的尺寸。主視覺尤其要準備一張專給手機的版本，桌機 2500px 的大圖在手機上大約 860px 就夠了。

每張圖都標明確的寬高。 給 width 與 height 屬性，瀏覽器在圖片載入前就能預留正確的版面空間，避免內容載入時亂跳，這是壓低 CLS 的關鍵，在窄畫面尤其明顯。

延遲載入只用在首屏以下。 對使用者第一眼看不到的圖加上 loading="lazy"，把它們的下載延到捲動接近時才發生，初始頁面重量會明顯下降。但首屏的主圖絕不延遲載入，這點和前一節呼應。

照這套處理完，一張原本拖慢手機載入的桌機大圖，會被換成尺寸正確、格式精簡、該晚載入才晚載入的版本，整頁的初始重量往往能砍掉一大截。

互動延遲在手機上特別嚴重的原因與壓低做法

INP 量的是「使用者做了一個動作（點擊、輸入），到畫面有反應」這段時間，它在手機上特別容易爆掉。原因很單純：手機 CPU 解析 JavaScript 的速度遠不如桌機，肥大的 JS 包與擋住主執行緒的腳本會直接把反應拖慢。據統計，INP 是目前最多網站沒達標的核心指標。

INP 可以拆成三個階段來理解：輸入延遲（瀏覽器正忙著跑別的任務，使用者一點下去得排隊）、處理時間（事件回呼跑多久）、呈現延遲（算完之後多久才畫出下一幀）。三段裡最常出問題的是輸入延遲，元兇就是長任務。

壓低 INP 可以從這幾個方向動手：

• 拆開長任務。 任何執行超過 50 毫秒的 JavaScript 任務都算長任務，會把主執行緒卡住。把大任務切成小塊，讓出主執行緒，使用者的點擊才能插隊被處理。現代瀏覽器可用 scheduler.yield() 主動讓出執行權；若要相容舊瀏覽器，退而用 setTimeout 把任務切段也有效。
• 延後、甚至延遲執行非關鍵 JavaScript。 不需要在畫面渲染前跑的腳本加上 defer；彼此獨立的用 async。更進一步，可以把某些腳本延遲到「使用者第一次互動之後」才執行（許多效能外掛有「延遲 JS 執行」這個選項），首屏完全不被它們占用主執行緒。
• 嚴格管控第三方腳本。 分析工具、聊天小工具、廣告與追蹤像素是手機主執行緒阻塞的大宗。逐一檢視每一支第三方標籤，不直接支撐轉換的就延後或移除。
• 移除沒用到的程式碼。 不在頁面上的程式碼就不會擋它。清掉沒用到的 JavaScript 與 CSS，主執行緒能更早空出來。
• 避免版面抖動（layout thrashing）。 程式若在迴圈裡反覆強迫瀏覽器重算樣式與版面，會拖慢呈現。把 DOM 的讀取與寫入分批處理，減少重排與重繪。

值得留意的是，過度肥大的 DOM（常見於拖拉式頁面建構器堆出來的大量巢狀 div）在手機上會同時傷 INP 與捲動流暢度，記憶體吃緊時甚至讓瀏覽器當掉。這類結構性問題，靠加外掛補不回來，得從版面本身瘦身。

佈景主題、外掛與主機怎麼影響行動版速度

很多行動版的慢，其實在你選主題、裝外掛、挑主機的當下就決定了。

佈景主題挑輕量的。 重型多功能主題與肥大的頁面建構器，會疊上一層層的 div 包裝與額外腳本，手機瀏覽器要花更久計算版面。GeneratePress、Kadence、Blocksy、Astra 這類主打效能的輕量主題，在核心網頁指標上通常表現得比重型主題好。頁首頁尾建議用主題內建編輯器處理，內文用區塊編輯器，少依賴第三方建構器。

外掛不是裝越多越好。 每裝一個外掛，往往就多一份樣式表與腳本，而且即使某外掛只在一個頁面用得到，它的程式碼常常每頁都載入。對手機使用者來說這就是純粹的負重，吃流量又卡主執行緒。定期檢視外掛清單，把功能重疊或久未使用的停用、移除。同時注意，多個「加速外掛」一起裝容易彼此衝突，反而把版面或腳本搞壞，挑一套全功能的、設定清楚比較穩。

主機是地基。 WordPress 是吃資源的系統，廉價的共享主機在尖峰時段 TTFB 容易偏高，再多前端優化也補不了慢伺服器。預算允許就往 VPS 或代管型主機走，並且優先選機房離目標客群近的方案。客群在台灣，就挑有台灣或鄰近節點的主機，別讓封包繞一大圈。搭配 CDN 把靜態資源放到離使用者更近的邊緣節點，對行動使用者、尤其是離原始伺服器較遠的訪客，延遲能明顯下降。

這一層的決策成本最低、影響最大，卻最容易被跳過去直接折騰前端。

改完之後，怎麼確認手機真的變快了

優化不是改完就結束，得驗證、而且要持續盯。最容易自欺的，是只看自己手機開起來「感覺很快」——你的手機很可能已經把網站快取住了，新訪客沒有這個優勢。

驗證要回到現場資料。改完先用 PageSpeed Insights 的行動裝置分頁看診斷項目有沒有轉成通過，但真正的判準是 CrUX 現場資料，因為那反映的是真實用戶在各種裝置與網路下的體驗，也是 Google 拿來排名的依據。現場資料有蒐集與更新的延遲，通常要等上一段時間才會反映改動，別改完當天就急著下結論。

驗證時掌握幾個原則：測多個頁面而不是只測首頁，批次測才看得出哪一頁在拖整站後腿，往往是塞了大圖、重表單或沒處理的主視覺；務必在行動裝置與節流網路下測，桌機快線測出來的好成績會把問題藏起來；每次更新外掛、換主題、加上新的行銷腳本之後都重測一次，因為效能很容易在這些動作後悄悄回退。

把核心網頁指標納入定期監測，設定一個「效能預算」當紅線，才能讓網站維持在快的狀態，而不是優化完一次就慢慢腐化。行動版速度從來不是一次性的專案，而是一套要長期維護的系統。對 WordPress 站來說，先把伺服器與主視覺圖這兩個地基顧好，再依序處理圖片、JavaScript 與版面結構，手機端的 LCP 與互動延遲就能穩定壓在綠色區間，後續只需要在每次改動後回測，守住成果。