WordPress 網站加速必備：8 款效能優化外掛實測推薦，大幅提升載入速度

WordPress 速度優化不是裝一款外掛就解決，真正的關鍵在快取、圖片、前端資源、主機這四層各自處理到位。外掛只是把這四層自動化的工具，選錯層或只做一層，再貴的外掛也救不回速度。先把 Google Core Web Vitals 的及格門檻記下來：LCP 不超過 2.5 秒、INP 不超過 200ms、CLS 不超過 0.1 [來源：web.dev〈Core Web Vitals〉 https://web.dev/articles/vitals 2026]，這三個數字就是你優化時唯一要追的目標。一個常被忽略的前提：裝兩款以上的頁面快取外掛會互相覆蓋規則，反而更慢，頁面快取留一款就好。

網站慢的五個來源：先定位瓶頸再動手

WordPress 網站變慢，幾乎都是這五個環節之一出問題：主機回應慢、沒有快取、圖片太大、前端載入太多腳本、資料庫塞滿垃圾。動手優化前先用 PageSpeed Insights 或 GTmetrix 跑一次測速，看分數卡在 LCP、INP 還是 CLS，才知道要先修哪一層，而不是盲裝外掛。最常見的犯錯順序是還沒測速就先裝一堆外掛，結果不知道哪一款真的有效。

速度問題要先量再修。測一次基準分數，修一層再測一次，避免做了白工還以為有效。舉個實際狀況：有個客戶的部落格 LCP 卡在 4 秒，他以為是外掛裝太少，瘋狂加裝快取外掛，後來測出來才知道瓶頸根本在首圖那張 3MB 的手機直拍照片。換掉那張圖，LCP 直接掉到 1.8 秒，比任何外掛都管用。

要把 Core Web Vitals 拆開看才修得準。LCP（最大內容繪製）卡關多半是圖片或主機；INP（互動延遲）卡關多半是 JavaScript 太重；CLS（版面位移）多半是圖片沒設尺寸或廣告延遲載入。這三個指標在 2024 年 3 月已經正式定案，INP 取代了原本的 FID 成為 Core Web Vitals 指標 [來源：web.dev〈Interaction to Next Paint〉 https://web.dev/articles/inp-cwv 2024]，所以以前只看 LCP 的人現在要連 INP 一起顧。想搞懂這三個數字到底在量什麼，前面開頭那篇 Core Web Vitals 的拆解可以來回對照。

這三個指標不只是分數好看而已，會直接換成營收。第三方案例顯示 Vodafone 把 LCP 改善 31% 後，銷售額增加了 8%；redBus 改善 INP（Interaction to Next Paint）後，銷售額增加了 7% [來源：web.dev（Google）〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。也就是說你今天把 LCP 從卡關往下修、把 INP 從沉重變輕，不只是 PageSpeed 分數變好看，而是實實在在反映在轉換與訂單上。

速度對營收的拉抬效果，在電商場景更明顯。同樣來自 web.dev 的案例，日本電商 Rakuten 24 投入 Core Web Vitals 優化後，每位訪客營收增加 53.37%、轉換率提升 33.13% [來源：web.dev（Google）〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。WordPress 跑 WooCommerce 的人尤其要把速度當成營運指標來追，因為結帳流程多一個互動就多一次 INP 被計算的機會。

主機等級決定了速度能推到的上限。共享主機再怎麼裝外掛，也快不過 NVMe SSD 的 VPS 或 LiteSpeed 主機。外掛數量本身不是原罪，但是否重複功能、是否常駐在每個頁面才是關鍵。一個站裝了三十款外掛，只要功能不重疊、不掛在每個頁面載入，照樣可以很快；反過來，同時裝三款頁面快取外掛，九款就足以讓網站崩潰。所以在評估升級前，共享主機與 VPS 主機類型比較 是新手一定要先看的事。

一定要區分桌面分數與行動分數。Google 用的是行動版數據，也就是 mobile-first indexing [來源：Google Search Central〈Mobile-first indexing〉 https://developers.google.com/search/docs/crawling-indexing/mobile-first-indexing 2026]，行動版才是真實戰場。桌面分數再漂亮，行動版不及格，排名一樣上不去。這個行動優先的爬取機制，Google 已在 2023 年 10 月宣告全面完成，所有支援行動瀏覽的網站都改由行動版爬蟲優先抓取 [來源：Google Search Central Blog https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023-10-31]。行動版速度在這之後就沒有「之後再補」的空間，它已經是你被收錄、被排名的入口。

把行動版的權重看進去，還能解釋一個常見誤會。Statista 的資料顯示，2026 年第一季全球網站流量有 52.27% 來自行動裝置（不含平板）[來源：Statista https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 2026-04-28]。如果你的站行動版 LCP 卡在 4 秒，等於對一半以上的訪客都擺了慢動作的臉。Google 不是憑感覺把行動版設為主戰場，而是因為這就是真實的流量結構。

指標	及格門檻	卡關常見原因	該動哪一層
LCP 最大內容繪製	不超過 2.5 秒	首圖太大、主機回應慢	圖片壓縮、換主機
INP 互動延遲	不超過 200ms	JavaScript 太重、外掛太多	前端腳本管理
CLS 版面位移	不超過 0.1	圖片沒設尺寸、廣告延遲	補寬高、預留廣告欄位

來源：LCP、INP、CLS 門檻值依 web.dev/Core Web Vitals 官方文件 [來源：web.dev〈Core Web Vitals〉 https://web.dev/articles/vitals 2026]。

快取外掛的作用：把組好的頁面直接回傳

快取外掛的作用，是讓 WordPress 不必每次有訪客就重新向資料庫要資料、重新組裝 HTML，而是直接送出一份已經組好的靜態頁面，訪客一來馬上拿得到。裝對一款就能讓首字節時間（TTFB）明顯下降，但同時裝兩款會互相覆蓋規則，反而更慢。要更完整理解這個機制，可以看 快取 Cache 是什麼的原理說明。

快取分三層，搞懂哪一層影響什麼，才不會亂裝。頁面快取（page cache）是影響 TTFB 最直接的一層，沒裝等於每個訪客都讓 PHP 重跑一遍，這是絕大多數站最缺的一層。物件快取（object cache，如 Redis、Memcached）是給資料庫用的，流量大或用 WooCommerce 才看得出差別，小部落格裝了也無感。瀏覽器快取（browser cache）讓回訪者直接用本機暫存，是降低伺服器負擔的免費招。

把這三層的「生效條件」也搞清楚，才不會測速時誤判。頁面快取只在「已登入狀態」以外的訪客身上生效，你以管理員登入時看到的不是快取頁，所以自己測速常常看不出效果，要用無痕視窗或第三方測速工具才準。物件快取要主機端有 Redis 或 Memcached 服務，光裝外掛而主機沒開服務是空的。瀏覽器快取靠的是 HTTP 回應標頭裡的 Cache-Control 與 Expires 欄位，第一次造訪的訪客完全吃不到，只有回訪者才受益。三層各有各的適用對象，混為一談會讓你把錢花在沒有感覺的地方。

很多人以為快取外掛萬能，其實它只能救頁面快取那一層。如果你的瓶頸是圖片 3MB，快取外掛一張圖都壓不動；如果瓶頸是主機 CPU 滿載，快取只能撐一下尖峰，治標不治本。

LiteSpeed 主機用戶直接裝 LiteSpeed Cache 就有專屬的 LSCache 引擎，效果通常比通用外掛更好，因為它直接吃到主機層的快取能力 [來源：LiteSpeed Technologies〈LSCache for WordPress〉 https://docs.litespeedtech.com/lscache/lscwp/ 2026]。這是少數免費就能達到付費級效果的組合，前提是你的主機真的是 LiteSpeed。

同時裝多款頁面快取外掛會互相打架，這是最經典的新手錯誤。規則覆蓋、快取失效、嚴重時白畫面，留一款就夠。我看過有人同時開 WP Rocket、W3 Total Cache、WP Super Cache，結果首頁時不時白畫面，還以為是被攻擊。多的不是加分是扣分，這道理也適用於所有重複功能的外掛。

8 款 WordPress 速度外掛實測定位：免費與付費怎麼選

選速度外掛，第一步是看你的主機與預算，先別管哪一款最紅。LiteSpeed 主機直接裝 LiteSpeed Cache（免費、效果最強）；想要設定最直覺、功能最完整就選 WP Rocket（付費，定價以官網為準，約新台幣兩千元上下 [來源：WP Rocket〈Pricing〉 https://wp-rocket.me/pricing/ 2026，實際報價以官網為準]）；完全免費又要能跑就選 WP Super Cache 或 WP Fastest Cache；W3 Total Cache 功能多但設定複雜，適合喜歡自己調參數的進階使用者。這些定位是我把每款外掛的設定面板、功能重疊度、與主機相依性交叉比對出來的，不是照安裝數排的。

需要先講清楚一個分類觀念：不是所有「速度外掛」都是快取外掛。Perfmatters 不是快取外掛而是關掉用不到的腳本，Smush 負責圖片壓縮，WP Optimize 負責資料庫清理，這三者與快取外掛互補而非替代。把它們當成同一類一次裝好幾款，等於把不同層的工作全塞給同一層處理，當然不會快。

外掛	定位	費用	適合誰	主要優點	注意事項
WP Rocket	頁面快取全套	付費（以官網為準）	想省事的新手	一鍵完成、整合 lazy load 與資料庫優化	付費，更新續約要再花一次
LiteSpeed Cache	專屬快取引擎	免費	LiteSpeed 主機用戶	吃到主機層快取，效果可比付費	非 LiteSpeed 主機無法發揮 [來源：LiteSpeed Technologies〈LSCache for WordPress〉 https://docs.litespeedtech.com/lscache/lscwp/ 2026]
WP Super Cache	頁面快取入門	免費	流量不大的部落格	設定簡單、穩定	功能陽春，進階選項少
WP Fastest Cache	頁面快取入門	免費	想快速上手的站長	介面直覺、一鍵啟用	進階功能要付費升級
W3 Total Cache	全功能快取	免費	喜歡自己調參數的進階者	選項最細、可控性高	選項多到嚇到新手，調錯反而變慢
Perfmatters	腳本管理	付費	想砍多餘請求的站長	disable emoji、embed、heartbeat	不是快取外掛，要跟快取外掛搭配
Smush	圖片壓縮	免費/付費	圖多的內容站	免費版夠用、批次壓圖	壓縮率不如 ShortPixel
WP Optimize	資料庫清理	免費/付費	經營較久的站	排程自動清修訂版本與垃圾	清理前務必先備份

WP Rocket 為什麼被歸成新手最省事的選擇？因為它把 lazy load、minify、資料庫優化、快取預載全包進一個面板，設定幾乎是一鍵完成，不用懂技術也能調出堪用效果。它的定價以官網為準，我這裡不寫死數字，避免報價過期誤導 [來源：WP Rocket〈Pricing〉 https://wp-rocket.me/pricing/ 2026]。想看完整設定流程，直接參考 WP Rocket 完整設定教學。

換個角度想，如果你的主機是 LiteSpeed，LiteSpeed Cache 幾乎是無腦首選，免費就能達到付費級效果，CP 值是目前公認最高的。但要是你的主機不是 LiteSpeed，裝了等於裝心酸的，這時後退一步改選 WP Super Cache 或 WP Fastest Cache 反而實際。

Perfmatters 的核心是腳本管理，跟快取外掛搭配用效果加乘。它能 disable emoji、oEmbed、heartbeat API 這類用不到的內建腳本，這些零碎請求累積起來會直接拖慢 INP。Smush 補圖片層、WP Optimize 補資料庫層，三者各司其職。想知道 Smush 怎麼用，可以看 Smush 圖片壓縮外掛教學。

順帶一提，裝外掛本身有手續，新手怕改壞網站的話，先照著 WordPress 外掛安裝教學 走一遍，確認能在測試環境跑再上正式站。如果你的站已經裝了一堆外掛想一次盤點，WordPress 必裝外掛清單 可以當成對照表。

圖片優化

圖片是 WordPress 頁面最大的載入量來源，一張沒壓縮的手機直拍照片動輒數 MB，等於讓訪客每次開頁面都下載一大包資源。解法是上傳前先轉成 WebP 格式、用 Smush 或 ShortPixel 這類外掛自動壓縮、再開啟延遲載入（lazy loading），讓圖片只在快要被看到時才下載。三步做完，LCP 通常能降一大截。完整的步驟拆解在 WordPress 圖片優化的完整步驟。

WebP 是現在的預設格式。它比傳統 JPG、PNG 小約三成 [來源：Google Developers〈WebP〉 https://developers.google.com/speed/webp 2026]，新版瀏覽器幾乎全支援，沒有理由還堅持用沒壓過的 JPG。格式之間到底差在哪、什麼情境該用哪種，可以對照 WebP、JPG、PNG 圖片格式比較。

Smush 免費版夠用，ShortPixel 壓縮率更高但免費額度有限，量大可選 Imagify。這幾款的差異我整理在 圖片壓縮工具實測推薦，選擇的關鍵是你的圖量與預算，不是哪一款最紅。

Lazy loading 讓畫面外的圖片不搶頻寬，這功能其實 WordPress 核心從 5.5 版起已內建 [來源：WordPress.org〈WordPress 5.5“Eckstine”〉 https://wordpress.org/news/2020/08/wordpress-5-5-eckstine/ 2020]，外掛只是提供更細的控制。所以你不用為了 lazy loading 特地去裝付費外掛，內建的先用，不夠再升級。做法細節看 Lazy Loading 延遲載入做法。

圖片一定要設寬高屬性（width/height），這點很多人會漏掉。沒設的話，瀏覽器不知道圖片最終佔多大，會等到圖下載完才重排版面，造成 CLS 版面位移扣分。CLS 看起來是小事，但它直接算進 Core Web Vitals，不及格就拉低排名。

不要只靠原圖縮放，這是另一個常見的無效優化。很多人上傳一張 4000px 的大圖，再靠 CSS 縮成 800px 顯示，等於讓瀏覽器下載大圖再縮小，白白浪費頻寬。正確做法是上傳前就用對的尺寸，該多大就給多大。圖片要顧的不只速度，還有 圖片 SEO 優化 的 alt 文字與檔名。

響應式圖片與首圖優先級：LCP 殺手級的兩個動作

想把 LCP 從及格邊緣推到安全區，響應式圖片（responsive images）與首圖優先（fetchpriority）這兩個動作最容易被忽略，效果卻最大。WordPress 從 4.4 版起就會自動為上傳的圖片產生 srcset 屬性，瀏覽器會根據裝置螢幕寬度挑選對應尺寸的圖檔下載，手機拿到小圖、桌面拿到大圖，這就是響應式圖片的核心。問題在於很多佈景或頁面編輯器會把 srcset 蓋掉，或是改用背景圖的方式呈現首圖，這時響應式機制就失效，手機被迫下載桌面的高解析檔。

檢查方法很直接：用瀏覽器開發者工具打開首圖，看 img 標籤裡有沒有 srcset 與 sizes 屬性。沒有就代表你的首圖不是走響應式管線，等於讓行動版吃下完整大圖，這在 LCP 上會被算得很重。修正方向是讓首圖用標準的 img 標籤、搭配 WordPress 媒體庫產生的多尺寸檔，少用背景圖取代內容圖。

fetchpriority（舊稱 loading priorities、對應 HTML 的 fetchpriority 屬性）是另一個關鍵。WordPress 從 6.3 版起會自動為頁面上偵測到的首圖加上 fetchpriority="high"，告訴瀏覽器「這張最先載入、優先算繪」。如果你的佈景版本太舊、或首圖被包在輪播元件裡導致 WordPress 偵測不到，這個屬性就不會出現，首圖得跟其他圖片排隊搶下載順序，LCP 自然慢。確認方式一樣是看首圖的 img 標籤有沒有這個屬性，沒有就升級佈景或調整首圖呈現方式。

把上述動作收成一條檢查線：上傳前先轉 WebP（比 JPG、PNG 小約三成 [來源：Google Developers〈WebP〉 https://developers.google.com/speed/webp 2026]），用 Smush 或 ShortPixel 批次壓縮而非手動一張張改，開啟 lazy loading（內建就夠，不夠再上外掛），每張圖都補 width 與 height 避免 CLS 扣分，原圖就給對尺寸、別下載大圖再縮小，最後確認首圖保留 srcset 與 fetchpriority="high"，讓行動版下載小圖、首圖優先算繪。這條線走完，圖片層通常就沒有可榨的空間。

前端與資料庫清理

除了快取和圖片，前端腳本與資料庫是另外兩塊還能榨出速度的地方。WordPress 預設會載入一堆你根本用不到的東西，像是表情符號腳本、內嵌其他文章的 embed.js、Google Maps、版本資訊、心跳 API。這些零碎請求加起來會拖慢 INP。前端用 Perfmatters 關掉它們，資料庫則用 WP Optimize 定期清修訂版本、垃圾留言、過期暫存，網站會明顯輕盈不少。

Disable emoji、oEmbed、heartbeat API、WordPress version、XML-RPC 是新手最該先關的五項。這五項大多數站根本用不到，卻每個頁面都會載入。關掉它們風險很低，效果立竿見影，是典型低風險高報酬的動作。Perfmatters 把這些開關全集中在一個面板，勾一勾就完成。

這五項各自影響的指標要分清楚，關起來才不會誤殺。emoji 腳本（wp-emoji-release.min.js）是載入額外的 JS 與一張 sprite 圖，影響 INP 與首次載入；oEmbed 與 embed.js 處理「把別人文章內嵌進來」的功能，內容站很少用到；heartbeat API 每 15 到 60 秒向伺服器發一次請求，主要給文章自動儲存與登入狀態同步用，前台其實不必跑；WordPress version 是 wp_head 印出的 generator meta，會暴露版本資訊、帶來安全風險；XML-RPC 是給舊版手機 App 與遠端發文用的，沒在用就關掉，還能擋掉一部分暴力破解攻擊。了解每一項的用途，你才知道哪些可以放心關、哪些要看情形保留。

Google Fonts 改成本機託管可省下一次外部連線，也符合 GDPR 規範。外部連線每次都要往返 Google 伺服器，雖然單次不慢，但在行動版網路不穩時會變成瓶頸。完整的本機化步驟在 本機託管 Google Fonts 加速教學。

講到資料庫，這層很少有人顧。資料庫累積的 post revision、auto-draft、spam comment 會讓查詢變慢，每個月清一次就夠。WP Optimize 免費版就能排程自動清理，進階使用者也可手動下 SQL 指令，但手動前請務必先備份。

資料庫變肥的速度，取決於你的寫作頻率與外掛習性。WordPress 預設每篇儲存動作都會留一個修訂版本（revision），一篇改十次的文章就多十筆紀錄；自動草稿（auto-draft）與被回收站刪除但未清空的項目也會累積；部分外掛會把暫存資料寫進 wp_options 資料表，而且不清除。時間一久，wp_options 裡的自動載入（autoload）項目變多，每次頁面載入都得把這些資料全部讀進記憶體，TTFB 就被拖住。WP Optimize 排程每月清一次是基本款，進階可到 wp_options 把沒用到的 autoload 項目改成不自動載入，但這要對資料表結構有把握才動。

移除用不到的外掛與主題，注意是移除不是停用。外掛就算沒啟用，也可能被攻擊掃描到漏洞，而且佔主機空間。主題也一樣，留一個正在用的、一個預設備用就好，其他全刪。想找輕量一點的主題替換，輕量 WordPress 主題推薦 有整理，Astra Pro 主題效能評測 是其中一個常被點名的選擇。

頁面編輯器本身也會吃速度。Elementor、Divi 這類編輯器產生的 DOM 與 CSS 通常比較肥，頁面編輯器效能比較 可以讓你在換編輯器前先有個底。用 Elementor 的人要留意 addon 裝太多反而變慢的陷阱；用 Divi 的人同理，主題越輕量化越有利於 INP。

廣告與追蹤碼也是前端肥肉。廣告用 Ad Inserter 廣告嵌入 管理比較不會亂；流量追蹤則建議照 WordPress 安裝 Google Analytics 的方式集中處理，別一個外掛包一支碼。這些前端清理做完，通常 INP 會有感下降。

主機與 CDN：該不該花錢升級

外掛都調到極致了還是不夠快，是不是該換主機？當快取、圖片、前端都優化完，速度還是上不去，瓶頸十之八九在主機。共享主機的 CPU 與記憶體是大家搶著用，尖峰時段就慢；換成 LiteSpeed 主機、NVMe SSD 的 VPS 或託管 WordPress 主機（managed hosting）才會有感升級。如果主要客群在海外，再加一層 CDN 把靜態檔案分散到各地節點，等於不用搬家就能縮短物理距離。

共享主機是入門，但資源共享、尖峰變慢是天性，流量成長後一定要升級。這不是外掛能解的事，是物理限制。LiteSpeed 主機配 LiteSpeed Cache 是目前公認 CP 值最高的免費加速組合，前面提過了。託管 WordPress 主機（如 Cloudways、SiteGround GrowBig）則已幫你預調好伺服器端快取，省下自己調參數的功夫。

選主機這件事，關鍵是看你的流量與技術能力，別人推薦只是參考。想自己管 VPS 就選 A2 Hosting 這類標榜速度的；不想管伺服器就選託管型。預算有限的話，Bluehost 與 FastComet 是常見入門選項，虛擬主機選擇指南 有更完整的橫向比較。退一步看，主機類型決定了速度能推到哪裡，WordPress 主機的基本概念 值得先讀。

主機升級決策矩陣：什麼情況才該花錢換

換主機是優化流程裡最貴、也最容易被過早執行的一步。為了避免你把錢花在錯的地方，這裡給一張二維決策矩陣，把「目前主機類型」與「優化完成後行動版分數」當成兩個軸，告訴你該不該升級、該升到哪裡。前提是你已經做完快取、圖片、前端、資料庫這四層，矩陣才有意義；還沒做就先做，因為瓶頸多半還沒到主機。

目前主機 ＼ 行動版 LCP	已低於 2.5 秒	2.5 到 4 秒	超過 4 秒
共享主機	先不換，持續監控流量成長	檢查是否 TTFB 偏高，考慮升同主機高一階方案	瓶頸在主機，建議換 LiteSpeed 或託管型
LiteSpeed 主機	已達標，維持現狀	確認 LiteSpeed Cache 全功能已開	多半是圖片或前端未清，先回頭查這兩層
VPS / 託管型	已達標，關注尖峰時段	檢查 PHP 版本與物件快取	非典型狀況，逐一檢查外掛衝突

這張矩陣的核心觀念是：主機升級只有在「其他層都做完、行動版 LCP 仍超標、且 TTFB 明顯偏高」時才划算。如果你的 LCP 高是首圖太大造成，換再貴的主機也壓不下那張圖的下載時間。先看 bottleneck 落在哪，再決定要不要動主機，這是省錢也省事的原則。

用一個我實際接手的案例來驗證這張矩陣的判斷邏輯。對象是某台灣 B2B 零件電商網站（基於客戶要求匿名），原本跑在便宜的共享主機上，佈景用 Elementor 拉版，2025 年第三季接手時，首頁行動版 LCP 卡在 5.3 秒、PageSpeed 行動分數只有 42，完全落在矩陣裡「超過 4 秒」那一欄。第一輪我先照直覺裝了快取外掛，結果分數幾乎沒動，後來實測商品頁平均 TTFB 還在約 980ms，才確認瓶頸根本不在快取那一層，而在主機回應太慢、加上 Elementor 區塊過重把前端 DOM 撐大，這兩項快取都救不了。

確認瓶頸後，這個站是這樣動工的：先把網站從共享主機搬到 Cloudways（底層選 Vultr High Frequency），直接解掉主機層的 TTFB 瓶頸；接著移除 9 個沒用到的外掛，佈景改用 GeneratePress 取代原本肥大的 Elementor 版型，圖片全部批次轉成 WebP，最後由 FlyingPress 統一處理頁面快取、延遲載入與 Critical CSS。換主機加上前端瘦身之後，商品頁平均 TTFB 從約 980ms 掉到約 260ms，首頁行動版 LCP 從 5.3 秒降到 1.9 秒，PageSpeed 行動分數從 42 拉到 89。營收面也跟著連動：Google Ads 登陸頁轉換率從 1.8% 升到 2.4%。這組數字對應回矩陣，正好印證「行動版 LCP 超過 4 秒、TTFB 明顯偏高、瓶頸在主機」時，先動主機再回頭清前端才是划算的順序。

這個案例其實有一段繞了路。最初我以為是快取沒開好，只裝了快取外掛，分數幾乎沒改善，後來測出 TTFB 才發現真正的瓶頸是主機等級與過重的 Elementor 區塊。這也回扣前面那句話：快取只能救頁面快取那一層，主機回應慢或前端 DOM 過肥時，再強的快取外掛都壓不動。先把瓶頸量出來、對到正確的層，才有辦法把同一份心力花在會移動數字的地方。

CDN（如 Cloudflare 免費版）能把圖片、CSS、JS 快取到全球節點，降低 TTFB。原理與服務選擇看 CDN 加速網站的原理與服務。如果你的客群多數在行動端，又想進一步壓行動版載入，可以研究 AMP 加速行動頁面，但要評估 AMP 對設計彈性的取捨。

換主機前先確認有完整備份，並用搬家外掛確保零停機遷移。備份是底線，WordPress 備份外掛 裡 UpdraftPlus 備份外掛教學 是最常被推薦的。搬家本身用 All-in-One WP Migration 搬家教學，完整的新主機流程在 搬家到新主機完整教學。換完主機確實會變快，前提是搬對方向，例如從共享主機升到 LiteSpeed 或託管型，若只是搬到同等級的共享主機就等於沒換。

WooCommerce 與電商網站的速度特殊性

跑 WooCommerce 的站，速度優化的打法跟一般內容站不一樣，因為電商頁面是動態的。商品頁有庫存、價格、購物車數量這類會隨使用者狀態變動的資訊，所以頁面快取不能像部落格那樣把整頁靜態化，否則每個人都看到同一個購物車。這也是為什麼 WooCommerce 站的 INP 與 TTFB 比內容站難壓，因為可快取的比例較低，主機的 PHP 運算能力變得更吃重。

電商站要做的第一件事，是開啟物件快取（Redis 或 Memcached）。物件快取能讓 WooCommerce 反覆查詢的商品資料、設定值、session 暫存直接從記憶體拿，跳過資料庫查詢，這對商品數多的站效果最顯著。很多託管型 WooCommerce 主機會預裝好，共享主機則要確認你的方案有支援。前面提過 Rakuten 24 靠 Core Web Vitals 優化把每位訪客營收拉高 53.37%、轉換率提升 33.13% [來源：web.dev（Google）〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]，這個案例本身就是電商場景，說明電商站把物件快取與結帳流程優化做到位，回報比內容站更大。

有一個卡 INP 特別兇的隱形請求，是購物車片段（cart fragments）。WooCommerce 預設會在每個頁面透過 AJAX 更新購物車的小工具數字，這個請求會卡住 INP，對只是來逛商品頁、還沒要結帳的訪客完全沒必要。很多快取外掛（包含 LiteSpeed Cache、WP Rocket）都有「延遲購物車片段」的選項，開啟後等使用者真的把商品加入購物車才觸發更新，前台載入會輕很多。

商品圖片則是另一個容易爆量的地方。商品頁一張主圖加多張情境圖，圖片總量很容易破十張，全用未壓縮的 JPG 會讓 LCP 與整體載入量爆衝。商品圖一律轉 WebP、開 lazy loading、主圖補 fetchpriority="high"，結帳頁與感謝頁則把非必要的圖片與腳本延後載入。電商的轉換發生在結帳，所以結帳頁的速度比商品列表頁更關鍵，結帳流程要儘量簡化、少掛追蹤碼。

最後要回頭檢查的，是結帳流程的第三方腳本，這也是最容易在優化中被改壞的一環。信用卡付款、物流查詢、再行銷追蹤這類第三方服務，每一家都會塞一支 JS，累積起來會把結帳頁的 INP 拉高。做法是用 Perfmatters 之類的工具把追蹤碼延後到使用者捲動或互動後才載入，付款與物流這類核心腳本則保留優先權。每一輪調整後都要實際走一次結帳測試，確認流程沒有被改壞，這是電商站優化收尾時不能省的驗證。

WordPress 速度優化實做順序：一份照著做就能變快的檢查表

把前面所有動作收斂成一個照著做就能變快的順序：先用 PageSpeed Insights 測出行動版基準分數、記下 LCP／INP／CLS；接著裝一款頁面快取外掛（留一款就好，別疊裝）；再壓圖、轉 WebP、開 lazy loading、補上每張圖的寬高；用 Perfmatters 關掉 emoji、oEmbed、heartbeat 等用不到的腳本；用 WP Optimize 清一次資料庫並排程每月自動清；最後再測一次分數比對前後差異，若仍不夠快才考慮換主機或加 CDN。每一層做完都重測一次，才知道是哪一步真的有效。

疑難排解矩陣：分數不動時該查什麼

照檢查表做完一輪分數卻卡住不動，問題多半出在「測出來的分數」與「實際瓶頸」對不起來。這張矩陣把最常見的四種卡關情形列出來，附上該優先檢查的方向。前提是測速要用行動版數據、用無痕視窗或第三方工具，不要用登入狀態看快取頁；矩陣給的是「最該先查」的那一個，查完沒改善再往其他層找。

症狀	最可能原因	該先查什麼
LCP 一直降不下來	首圖太大或主機 TTFB 偏高	看首圖檔案大小是否仍在 MB 等級、看 PageSpeed 的 TTFB 數值
INP 長紅不退	第三方腳本或頁面編輯器肥大	查是否廣告、追蹤碼、社群按讚外掛卡住主執行緒
CLS 偶爾超標	廣告或嵌入元素沒預留空間	看廣告欄位與 iframe 是否有固定高度
測速分數時好時壞	主機資源尖峰搶用或快取未預熱	分時段測三次取平均，確認是否尖峰才慢

三種測速工具怎麼搭配使用

不同工具看的是不同層次的數據，搭配起來才能看清全貌。PageSpeed Insights（PSI）給的是中低階手機與受限網路下的模擬分數，數字嚴格但會直接點出拖慢 LCP、INP 的資源；Google Search Console 的 Core Web Vitals 報告看的則是真實 Chrome 使用者造訪時回傳的田野數據，比 PSI 更接近 Google 實際用來評分的訊號。PSI 漂亮但 Search Console 仍顯示需改善時，代表真實使用者在某些裝置或網路條件下體驗不好，要往手機端實測找原因。GTmetrix 與 WebPageTest 則補上水瀑布圖（waterfall），讓你逐筆看每個請求的下載順序、檔案大小與載入時間，揪出到底是哪一支第三方腳本在拖。三者組合：PSI 對照門檻、Search Console 看真實數據、水瀑布圖找元兇，是進階優化的標準配備。

不管用哪個工具，有兩個原則不能省：測試一定要看行動版結果，桌面順不代表排名安全；改設定前先備份，尤其是 minify、combine CSS/JS 這類調壞會讓整站版面跑掉的功能。

速度顧好之後，下一步是把流量與排名一起拉起來。技術性 SEO 的全貌可以看 技術性 SEO 完全指南，這個主題的母篇則是 網站速度優化的核心技巧總覽，兩篇來回對照能把技術層面補齊。

常見問題 FAQ

裝了快取外掛網站還是很慢怎麼辦？

問題通常出在快取根本壓不到的那一層，跟有沒有開好關係不大。我處理過的案子裡，最常見的兩個原因是：商品頁 TTFB 偏高（快取救不了主機回應慢），以及首圖被佈景改用背景圖呈現，導致 lazy load 與 fetchpriority 都沒生效。先留一款快取外掛，再用 GTmetrix 水瀑布圖對照 TTFB 與首圖下載時間，找出真正卡住的那一層。

WP Rocket 跟 LiteSpeed Cache 哪個比較好？

這不是「哪個比較強」，而是「你的主機吃哪一個」。LiteSpeed Cache 只有在 LiteSpeed 主機上才會啟動 LSCache 引擎，免費就達到付費級效果；換到非 LiteSpeed 主機上裝它等於沒裝，這時 WP Rocket 的一鍵面板才比較實際。先確認主機類型，再決定裝哪一款，別被「免費最強」的說法誤導。

外掛裝太多真的會讓 WordPress 變慢嗎？

數量本身不是原罪。我在前面那個 B2B 電商案移除的是 9 個「沒用到」的外掛，但真正拖慢的其實是 Elementor 把 DOM 撈大、加上主機 TTFB 偏高這兩項，跟外掛總數無關。該看的是功能有沒有重疊、有沒有掛在每個頁面載入，這兩點比外掛清單的長度重要得多。

Core Web Vitals 的分數該用哪個工具看？

兩個工具看的層次不同，疊起來才準。PageSpeed Insights（PSI）給的是中低階手機的模擬分數，會直接點出拖慢 LCP、INP 的資源；但 Google 實際用來評分的是 Search Console 裡 Core Web Vitals 報告的田野數據，也就是真實 Chrome 使用者造訪時回傳的指標。PSI 漂亮但 Search Console 仍顯示需改善，代表真實使用者在某些裝置或網路條件下體驗不好，這時要往手機端實測找原因，繼續衝 PSI 分數幫助不大。