前言
WordPress 站點一變慢，很多人的第一反應都是先裝快取外掛、先看主機規格，或直接懷疑資料庫。但如果你根本還不知道慢在哪一段，這些動作常常只是在亂猜。
我自己很常用的一個第一輪排查工具，其實不是瀏覽器外掛，也不是監控面板，而是 WP-CLI。
原因很簡單：它夠快、夠直接，而且很適合先把問題切開。你可以先看 WordPress 載入流程到底卡在 bootstrap、main_query 還是 template，再決定下一步是查外掛、查 hook、查排程，還是回頭看資料庫。
這篇文章整理的是我自己用 WP-CLI 做 WordPress 效能測試時最常走的流程。如果你手上的站點有 WooCommerce、WPML、Redis、頁面編輯器，或登入狀態下特別慢，這套方式很適合先拿來定位問題。
先講結論：WP-CLI 適合拿來做第一輪定位
WP-CLI 很適合回答這幾個問題：
- WordPress 慢的是啟動階段，還是查詢與模板階段
- 哪個 hook 特別重
- 是不是某些外掛在初始化時就拖慢整站
- WP-Cron 是否剛好在首訪時插隊執行
但它也有邊界。WP-CLI 看到的是 WordPress 在 CLI 脈絡下的載入成本，不等於瀏覽器真的打進來的完整前台請求。所以我會把它當成「先抓方向」的工具，而不是最後的唯一結論。
第一步：先確認你的 WP-CLI 狀態
開始前，先確認主機上真的有 WP-CLI，而且版本正常：
wp cli version wp cli info如果你平常是多站管理，這一步也很重要。因為後面你看到的所有結果，都取決於你目前站在正確的 WordPress 根目錄，或有沒有帶對 --path / --url。
wp profile 不是內建指令，要先安裝
很多人以為 wp profile 是 WP-CLI 內建，其實不是。它是額外安裝的套件，官方文件寫得很清楚，要先透過 wp package install 裝上 wp-cli/profile-command。
wp package install wp-cli/profile-command裝完之後，可以先確認是否已經可用：
wp profile --help如果這一步就出錯，先不要急著測站點，先把你的 WP-CLI 套件環境整理乾淨。
第二步：先看整個載入流程慢在哪裡
我最常先跑的是這條：
wp profile stage --fields=stage,time,cache_ratio官方文件提供的輸出會把 WordPress 載入流程切成三段：
bootstrapmain_querytemplate
這三段非常好用，因為你不用一開始就鑽進慢查詢或 Nginx 設定裡。先看哪一段最重，很多事情就清楚了。
如果 bootstrap 特別慢
通常代表問題比較偏：
- 外掛太多
- 某些外掛在初始化時做了太多事
- 語言外掛、會員外掛、WooCommerce 相關 hook 太重
如果 main_query 特別慢
通常就要開始懷疑：
- 查詢本身太重
- WPML 或 WooCommerce 把 query 複雜度拉高
- 資料庫索引或 object cache 沒有跟上
如果 template 特別慢
那通常比較像：
- 佈景主題或 builder 組頁太重
- 動態區塊太多
- 一些 template-level 的函式每次都重跑
第三步：往下挖是哪個 hook 拖慢
當你發現某一段特別慢，下一步就不是繼續猜，而是把那一段拆開。
例如官方文件裡直接示範了這條：
wp profile stage bootstrap --fields=hook,time,cache_ratio --spotlight這個結果很有價值，因為它會直接列出每個 hook 花了多少時間。像 plugins_loaded、after_setup_theme、init、wp_loaded，到底是誰在拖慢站，你會看得很清楚。
如果你的站有 WooCommerce、WPML、會員系統或很多自訂功能，問題常常不是 WordPress 核心，而是某個 hook 被掛了太多 callback。
第四步：用 wp profile hook 直接看 hooks
除了從 stage 往下拆，wp profile 也提供了 hook 子指令，官方文件把它定義成用來觀察 WordPress hooks 的關鍵效能指標。
wp profile hook --fields=hook,time,cache_ratio --spotlight我會把這個指令當成第二層放大鏡。當你已經知道整站慢在初始化附近，這時候就很適合用它去看哪些 hooks 值得優先懷疑。
如果你看到 init、template_redirect、wp_loaded 這類 hook 特別重，通常就可以開始回頭檢查：
- 是不是某個外掛每次 request 都打 API
- 是不是某段自訂程式把大量查詢塞進 hook 裡
- 是不是 WooCommerce 或 WPML 的流程在登入狀態被放大
第五步：切換不同條件重測，結果才有比較價值
只跑一次不太有意義。真正有用的是你能不能把條件切開來看。
我很常搭配這些參數交叉比對：
wp profile stage --url=https://example.com/product/foo/ wp profile stage --url=https://example.com/my-account/ --user=admin wp profile stage --skip-plugins wp profile stage --skip-themes這幾個參數很實用：
--url：指定要模擬哪個 URL，對多站或特定頁面很重要--user：用特定使用者脈絡載入 WordPress--skip-plugins：先排除外掛因素--skip-themes：先排除主題因素
例如你可以先跑一次完整環境，再跑一次 --skip-plugins。如果時間直接少掉一大截，問題就八九不離十在外掛層。
同理，如果關掉 theme 後速度好很多，那就該往佈景主題、page builder 或 template 組裝方向查。
第六步：不要漏看 WP-Cron
很多 WordPress 站的慢，不是慢在每次都發生，而是慢在「剛好」撞到某個排程。這種情況最容易讓人誤判，因為你第二次測可能又正常了。
這時候 WP-CLI 很適合先查排程：
wp cron test wp cron event list --fields=hook,next_run --format=table wp cron event run --due-now官方文件裡有列出 wp cron event list 和 wp cron event run --due-now 的用法，這兩條對排查很實際。
如果你發現：
- 大量排程擠在同一時間
- 某些外掛的 cron hook 特別頻繁
- 一跑
--due-now就卡很久
那就很可能代表你的首訪延遲不是前台模板問題，而是背景任務在插隊。
第七步：我會怎麼做一輪實際排查
如果今天是一個 WooCommerce 或 WPML 站點丟到我手上，我通常會這樣跑：
- 先用
wp profile stage看是bootstrap、main_query還是template最重 - 如果是
bootstrap，再跑wp profile stage bootstrap --spotlight - 再用
--skip-plugins或--skip-themes快速切割責任範圍 - 如果結果忽快忽慢，就立刻補查
wp cron event list和wp cron event run --due-now - 最後才回頭看 Query Monitor、慢查詢 log、Redis 命中率或 PHP-FPM 指標
這樣做的好處是你不會一開始就陷進太多工具裡。先用 WP-CLI 把問題縮到合理範圍，再往下挖，效率通常高很多。
WP-CLI 測得出什麼，測不出什麼
這段我覺得一定要先講清楚，不然很容易誤用。
WP-CLI 很擅長觀察 WordPress 的載入與執行成本，但它不是瀏覽器，也不是完整壓測工具。所以它比較適合：
- 抓 WordPress 初始化成本
- 找慢 hook
- 排查 WP-Cron
- 快速比較 plugin / theme 是否是主要原因
但如果你要驗證的問題是：
- Cloudflare 邊緣快取是否命中
- Nginx 與 FastCGI 行為
- 瀏覽器端 JS、CSS、圖片與 API 請求
- 真實登入 cookie 下的完整 TTFB 與前台體感
那你還是要搭配瀏覽器 DevTools、伺服器監控、甚至真實使用流程一起看。
這組指令很適合先存下來
wp cli info wp package install wp-cli/profile-command wp profile stage --fields=stage,time,cache_ratio wp profile stage bootstrap --fields=hook,time,cache_ratio --spotlight wp profile hook --fields=hook,time,cache_ratio --spotlight wp profile stage --url=https://example.com/my-account/ --user=admin wp profile stage --skip-plugins wp profile stage --skip-themes wp cron test wp cron event list --fields=hook,next_run --format=table wp cron event run --due-now結語
我很喜歡 WP-CLI 的地方，就是它不會讓你一開始就掉進過度複雜的監控視角裡。很多時候你需要的不是更多圖表，而是一個夠快的工具，先把「慢在哪裡」問清楚。
對 WordPress 效能排查來說，wp profile 和 wp cron 這兩組工具就很夠用了。先把慢點定位出來，再決定要不要往 OPcache、Redis、PHP-FPM、慢查詢或 fragment cache 深挖，整個排查流程會乾淨很多。
如果你平常是用 CLI 管多個 WordPress 站，我會很建議把這套流程固定下來。因為真正省時間的，不是一次把所有工具都打開，而是你能不能在前十分鐘就縮小問題範圍。
延伸閱讀：
