wp-performance

wp-performance 技能概覽

wp-performance 的用途

wp-performance 技能可協助你從後端診斷並改善 WordPress 效能，而且不需要仰賴瀏覽器介面。它特別適合用在「這個站點很慢」要一路追到可量測修正的情境，尤其是 WordPress 6.9+ 環境中的 Performance Optimization 工作。

誰適合安裝

如果你在處理慢速的前台請求、管理頁面、REST 路由或 WP-Cron 活動，並且希望有一套帶引導的剖析、診斷與安全驗證流程，就適合安裝 wp-performance 技能。當你可以使用 WP-CLI、logs 與直接的 HTTP requests，但沒有完整的瀏覽器除錯環境時，它尤其有用。

最擅長處理哪些情境

wp-performance 技能最強的地方，是以量測為先的初步排查，以及針對資料庫查詢、autoloaded options、object caching、cron 與遠端 HTTP calls 的後端修正。它也會引導你用對工具，包括 wp profile、wp doctor、透過 REST headers 觀察的 Query Monitor，以及可用時的 Server-Timing。

如何使用 wp-performance 技能

正確安裝並設定範圍

在 WordPress/agent-skills collection 裡執行 wp-performance install 流程，使用 skill slug wp-performance，然後在提出分析需求前先確認目標站點的情境。這個技能在你提供 WordPress root 的 --path=<path> 時效果最好；若是 multisite 或有路由的安裝，則也請加上 --url=<url>，指定你要評估的精確站點或 endpoint。

提供它真正需要的輸入

一個夠強的 wp-performance usage 提示，應該包含症狀、範圍與環境。例如：「Staging site，禁止寫入，已登入的管理後台很慢，請用 wp-performance 分析主要查詢路徑，並先提出安全的唯讀檢查。」這會比單純說「site is slow」好得多，因為它清楚告訴技能要量測什麼，以及有哪些限制。

先讀對的檔案

先從 SKILL.md 開始，接著依症狀閱讀 references/measurement.md、references/database.md、references/autoload-options.md、references/object-cache.md、references/cron.md 與 references/http-api.md。如果你需要無頭版 Query Monitor 或以命令驅動的檢查，也請一併查看 references/query-monitor-headless.md、references/wp-cli-profile.md、references/wp-cli-doctor.md，以及 scripts/perf_inspect.mjs，抓取 workflow 提示。

採用以量測為先的工作流程

最佳的 wp-performance guide 流程是：先建立 baseline、測試一個可重現的 URL 或 REST route、檢查成本最高的層級，然後在做完針對性變更後驗證結果。每次測試都保持相同情境，拿多次樣本比較，不要只看一次尖峰；除非你明確允許，否則不要要求破壞性操作。

wp-performance 技能常見問題

wp-performance 只適合後端代理嗎？

是。這個技能是為只用後端方式進行調查而設計的，工具包含 WP-CLI、headers、logs 與 HTTP requests。如果你需要瀏覽器互動、視覺化 waterfall 分析，或 click-path 測試，wp-performance 就不是主要工具。

它和一般提示詞有什麼不同？

一般提示詞可能只會叫你「優化 WordPress」，但 wp-performance 提供的是有約束的工作流程，包含量測、保護措施，以及 WordPress 專屬的故障領域。這點很重要，因為修正方式取決於瓶頸是 DB queries、autoload 膨脹、cron，還是遠端 HTTP calls。

對初學者友善嗎？

可以，只要你能描述症狀並提供安裝情境。這個技能對初學者有幫助，因為它會縮小第一輪要檢查的範圍；但你仍然需要提供清楚的目標 URL 或 route，並說明是否允許寫入、安裝外掛或清除快取。

什麼情況下不該用它？

如果問題和 WordPress 執行無關，例如 CDN routing、DNS failure，或純前端 JavaScript 瓶頸，就不要用 wp-performance。當你無法存取伺服器、不能執行 WP-CLI，也沒有辦法檢查 HTTP responses 或 logs 時，它也不適合。

如何改進 wp-performance 技能

提供更強的起始證據

最有用的輸入，是一個具體目標加上一種症狀模式：https://example.com/wp-json/...、「只有登入的編輯者會慢」、「TTFB 每 5 分鐘暴增」，或「登入後管理頁面卡住」。這能幫助 wp-performance 選擇正確的量測路徑，而不是猜測。

告訴它允許做哪一類變更

如果你希望先做安全的第一輪檢查，就直接說清楚。例如：「只做唯讀診斷」、「不要清快取」，或「只能在 staging 變更 options」。這會讓 wp-performance skill 更好用，因為流程可以避開高風險檢查，並維持在你的操作限制之內。

不只問診斷，也要問修正路徑

最好的 wp-performance usage 結果，來自你同時要求瓶頸與下一步驗證方式。例如：「找出最慢的層級、指出最可能的原因，並提供精確的後續 command 或 request 來確認改善。」這樣輸出才會真正可執行。

針對第一份報告持續迭代

如果第一次結果指向 queries，就把慢的 table、hook 或 route 回饋給它，要求更精準的 query plan。如果它指向 autoloaded options、object cache、cron 或 HTTP API calls，就要求最小風險的修正方式，以及變更前後的量測計畫。這正是 wp-performance 技能在 Performance Optimization 工作中最有價值的地方。