WordPress 網站變慢？活用 WP-CLI 找出問題

WordPress 網站變慢的原因有很多，但大部分文章給的建議都是「裝個快取外掛」「換個好一點的主機」，這些建議沒有錯，但就像醫生還沒做檢查就開藥——你不知道病因在哪，怎麼確定這個藥有用？

我們最近幫一位客戶做了一次完整的網站效能健檢，從找到問題到修復完成，全程用的是 WordPress 內建的命令列工具 WP-CLI。這篇文章記錄整個過程，希望能讓你對效能檢查的實際流程有更具體的認識。

客戶說：「網站最近越來越慢」

這位客戶經營一個中型內容網站，用 WordPress 架設，裝了大約 40 個外掛，文章數量超過一萬篇。最近他發現不管是前台瀏覽還是後台編輯，頁面都要等好幾秒才出來。

他試過裝快取外掛、壓縮圖片，甚至換了主機方案，但改善有限，後來找到我們，希望能徹底查出問題在哪。

什麼是 WP-CLI？為什麼我們用它做檢查

WP-CLI 是 WordPress 的命令列工具。簡單來說，它讓你可以「用打字的方式」操作 WordPress，不需要打開瀏覽器登入後台。

為什麼效能檢查要用命令列？因為瀏覽器本身就會消耗資源、產生干擾。用命令列直接跟伺服器溝通，測出來的數據最乾淨、最準確，而且很多深層的檢查項目，在後台介面裡根本看不到。

第一步：看看伺服器的基本體質

第一件事不是看 WordPress，而是看整台伺服器的狀態——記憶體夠不夠、處理器忙不忙、硬碟滿不滿。

客戶的伺服器是 8GB 記憶體的雲端主機，看起來不差。但一查才發現，記憶體只剩 1.2GB，而且已經開始借用硬碟空間來運作（技術上叫 Swap）。硬碟速度比記憶體慢幾十倍，這就像你的電腦記憶體不夠，開始狂跑虛擬記憶體一樣——當然會卡。

更關鍵的是，這台主機上同時跑了 8 個 WordPress 網站，但真正有在用的只有 2 個。其他 6 個是很久以前測試用的，沒關掉也沒刪掉，白白佔著資源。

第二步：檢查快取有沒有在運作

快取的概念很簡單：把已經算過的結果存起來，下次要用直接拿，不用再算一遍。

WordPress 有兩種主要的快取：

1. 資料庫快取：把資料庫查詢的結果存在記憶體裡。WordPress 每顯示一個頁面，可能要查幾十次資料庫，如果結果都能從記憶體直接拿，速度差很多。
2. 頁面快取：把整個頁面的最終結果存起來。下次有人看同一頁，直接把存好的結果丟出去，連 PHP 都不用跑。

我們用 WP-CLI 一查，發現兩個都沒開：

$ wp redis status
Status: Not connected

Redis（資料庫快取的引擎）已經有裝在伺服器上，但 WordPress 沒有連上去。等於冰箱買了、插頭沒插。

修正： 用 WP-CLI 一行指令裝好外掛並啟用連線。

$ wp plugin install redis-cache --activate
$ wp redis enable
Status: Connected

啟用之後，WordPress 的快取命中率立刻衝到 96%——代表 96% 的資料庫查詢都不用真的去查，直接從記憶體拿。

第三步：這個網站到底裝了多少外掛？

$ wp plugin list --status=active --format=count
42

42 個啟用中的外掛。這個數字本身不算離譜，但問題不在數量，而在這些外掛做了多少事。

WordPress 的運作方式是這樣的：每次有人瀏覽頁面，WordPress 會依序通知所有外掛「嘿，有人來了，你要不要做點什麼？」。外掛越多，被通知的對象越多，每個外掛回應的時間加起來就是你的等待時間。

我們寫了一段分析程式，算出每個外掛掛了多少個「通知接收器」：

外掛	接收器數量
WooCommerce（電商）	1,918 個
WPForms Lite（表單）	1,518 個
ACF Pro（自訂欄位）	990 個
Elementor（頁面編輯器）	567 個
Polylang（多語系）	538 個

第一名的 WooCommerce 不意外——電商本來就複雜。但第二名的 WPForms Lite 掛了 1,518 個接收器，而這個網站根本沒有在用它（已經有另一個表單外掛 Contact Form 7 了）。

一個沒在用的外掛，每次頁面載入都默默做了 1,518 件事。

第四步：量化每個環節花了多少時間

WP-CLI 有個進階工具叫 wp profile，可以精確計時 WordPress 載入過程中每個環節花了多久：

$ wp profile stage --context=admin

stage       time      query_time  query_count  cache_ratio
bootstrap   3.73s     0.11s       52           96.19%

一個後台頁面要花 3.73 秒才能載入完成。拆開來看：

• 資料庫查詢：只花了 0.11 秒（佔 3%）——感謝 Redis，這部分已經很快了
• 外掛程式碼執行：花了 2.5 秒（佔 67%）——問題在這裡
• 其他 PHP 處理：花了約 1.1 秒（佔 30%）

有趣的是，126,830 個通知接收器在每次載入頁面時全部被觸發一次，光跑完這些就要 2.5 秒。

進一步追蹤哪些環節最慢：

環節	接收器數量	耗時
初始化（init）	306 個	687ms
載入 API 端口	111 個	604ms
外掛載入	76 個	315ms
後台初始化	179 個	215ms

光「初始化」和「載入 API 端口」兩個環節就吃掉 1.3 秒。這些都是 WooCommerce、Elementor、Polylang 等大型外掛在做的事。

第五步：用 Lighthouse 看前台的實際表現

除了伺服器端的檢查，我們也用 Google 的 Lighthouse 工具看了前台的載入狀況：

指標	數值	說明
效能評分	48/100	不及格
首次繪製	4.7 秒	使用者等太久才看到東西
最大內容繪製	15 秒	主要內容 15 秒才完成

Lighthouse 指出最大的前端問題是「太多 CSS 和 JavaScript 擋住了頁面顯示」——這也是外掛過多的副作用，每個外掛都往頁面裡塞自己的樣式和程式碼。

第六步：健康檢查

最後，我們跑了 WP-CLI 的健康檢查工具，做一次全面掃描：

$ wp doctor check --all

檢查項目	狀態
WordPress 核心檔案完整性	✅ 通過
自動載入資料大小	✅ 正常（98KB）
排程任務數量	✅ 正常
18 個外掛有更新可用	⚠️ 需要更新
上傳目錄中有 PHP 檔案	⚠️ 安全風險
多個外掛會清空快取	⚠️ 可能導致效能波動

18 個外掛沒更新，代表可能有安全漏洞和效能問題。上傳目錄裡出現 PHP 檔案更是危險信號——正常情況下，上傳目錄只會有圖片和文件。

修復成果

根據檢查結果，我們做了以下修正：

1. 啟用 Redis 資料庫快取 — 96% 的查詢直接從記憶體取得
2. 啟用 Nginx 頁面快取 — 前台頁面由伺服器直接回傳，不跑 PHP
3. 停用沒在用的外掛 — 從 42 個降到 36 個
4. 更新過期的外掛 — 18 個外掛更新到最新版

效果呢？

指標	修復前	修復後	改善幅度
前台內頁回應時間	4.0 秒	0.67 秒	-83%
前台首頁回應時間	4.0 秒	2.2 秒	-45%
API 回應時間	3.8 秒	1.9 秒	-50%
WordPress 啟動時間	2.7 秒	1.8 秒	-33%

內頁從 4 秒降到 0.67 秒，使用者體驗完全不同。

你的 WordPress 網站也有類似問題嗎？

根據我們的經驗，大部分 WordPress 網站慢的原因都不是主機太差，而是：

• 快取沒設定好（裝了但沒連上）
• 外掛裝太多（尤其是裝了沒在用的）
• 很久沒做維護（外掛沒更新、資料庫沒清理）

這些問題用一般的方式很難發現。你不會在後台看到「你的 Redis 沒連上」的提示，也不會有人告訴你「WPForms Lite 每次載入做了 1,518 件事但沒一件是你需要的」。

如果你的網站也有類似的狀況，不妨試著用 WP-CLI 跑一輪檢查，或是找有經驗的人幫忙看看，通常比自己亂猜、亂裝外掛來得有效率。

常見問題

WordPress 網站變慢一定是主機的問題嗎？

不一定。我們遇到最多的情況是快取沒設定好、外掛太多、或是資料庫需要清理。這些問題換再好的主機也解決不了，要從 WordPress 本身下手才有用。

裝快取外掛就能解決速度問題嗎？

快取外掛確實有幫助，但它只是其中一環。如果你的網站有 40 個外掛每次載入都在做事，快取只能減少重複的工作，不能消除外掛本身的負擔。更重要的是，很多人裝了快取外掛卻沒有正確設定，等於白裝。

檢查完之後需要重新架站嗎？

大部分情況不用。像這次的案例，我們只是啟用了已經裝好但沒連上的快取、停用了沒在用的外掛，就有明顯的改善。除非網站的架構本身有根本性的問題，否則通常調整設定就夠了。

自己可以用 WP-CLI 做檢查嗎？

可以，WP-CLI 是免費的開源工具，只要你有伺服器的 SSH 權限就能使用。這篇文章提到的指令都可以直接跑，不過判讀結果和決定怎麼修，需要一些 WordPress 底層運作的經驗。

---

有類似的需求，或想進一步討論？歡迎聯絡我們，或加入我們的 LINE 官方帳號聊聊你的專案。