wp-performance

wp-performance の概要

wp-performance で何ができるか

wp-performance は、ブラウザ UI に頼らずに WordPress のパフォーマンスをバックエンド側から調査・改善するための skill です。「このサイトが遅い」という状態から、実測に基づく修正へ進むための実践的な道筋を用意しており、とくに WordPress 6.9+ 環境での Performance Optimization 作業に向いています。

どんな人にインストール向きか

フロントエンドの遅いリクエスト、管理画面、REST ルート、WP-Cron の動作を調べていて、プロファイリング、診断、安全な検証まで含めたガイド付きの流れがほしいなら、wp-performance skill を使うべきです。WP-CLI、ログ、直接の HTTP リクエストは使えるが、ブラウザベースのデバッグセッションまでは使えない、という状況で特に役立ちます。

何に最も強いか

wp-performance skill の強みは、まず計測してから切り分けるトリアージと、データベースクエリ、autoload された options、object cache、cron、外部 HTTP 呼び出しに対するバックエンド修正です。さらに、wp profile、wp doctor、REST ヘッダー経由の Query Monitor、利用可能なら Server-Timing といった、用途に合ったツールへ自然に誘導してくれます。

wp-performance skill の使い方

正しくインストールして対象範囲を決める

WordPress/agent-skills コレクションで wp-performance install の流れを実行し、skill slug に wp-performance を指定したうえで、分析を依頼する前に対象サイトのコンテキストを必ず確認してください。WordPress ルートには --path=<path> を指定するのが最適です。さらに、マルチサイトやルーティングされた環境では、評価したい正確なサイトやエンドポイントを示すために --url=<url> も指定します。

skill が本当に必要とする入力を渡す

良い wp-performance usage プロンプトには、症状、範囲、環境の3点が入っているべきです。たとえば、「ステージングサイト、書き込み不可、ログイン後の管理ダッシュボードが遅い。wp-performance を使ってメインのクエリ経路をプロファイルし、まずは安全な読み取り専用の確認を提案してほしい」のように書きます。単に「サイトが遅い」だけでは不十分で、何を計測すべきか、どんな制約があるかが skill に伝わりません。

先に読むべきファイルを見極める

まず 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 も見て、ワークフローのヒントをつかみます。

計測起点のワークフローを使う

最も有効な wp-performance guide の流れは、ベースラインを取り、再現性のある1つの URL または REST ルートをテストし、最もコストの高い層を調べ、狙った変更のあとで再確認することです。実行ごとに条件を固定し、1回のスパイクではなく複数サンプルを比較し、明示的に許可していない限り破壊的な操作は依頼しないようにします。

wp-performance skill の FAQ

wp-performance はバックエンド専用ですか？

はい。この skill は、WP-CLI、ヘッダー、ログ、HTTP リクエストを使ったバックエンド主体の調査向けに設計されています。ブラウザ操作、視覚的な waterfall 分析、クリック経路のテストが必要なら、wp-performance は主役としては適していません。

汎用プロンプトとどう違いますか？

汎用プロンプトは「WordPress を最適化して」と指示するだけで終わりがちですが、wp-performance は計測、ガードレール、WordPress 固有の障害領域に絞った制約付きワークフローを持っています。ボトルネックが DB クエリなのか、autoload の肥大化なのか、cron なのか、外部 HTTP 呼び出しなのかで修正方法が変わるため、ここが重要です。

初心者でも使いやすいですか？

はい。症状を説明し、インストール時のコンテキストを渡せるなら使いやすいです。最初に確認すべき項目が絞られるので初心者にも向いていますが、明確な対象 URL や route の指定、さらに書き込み、プラグインのインストール、キャッシュの flush が許可されているかどうかは、やはり自分で伝える必要があります。

使わないほうがよいのはどんなときですか？

CDN のルーティング、DNS 障害、純粋なフロントエンド JavaScript のボトルネックなど、WordPress の実行そのものと無関係な問題には wp-performance を使わないでください。また、サーバーにアクセスできない、WP-CLI を実行できない、HTTP レスポンスやログを確認する手段がない場合も、この skill にはあまり向きません。

wp-performance skill をどう改善するか

最初の証拠をもっと具体的にする

最も役立つ入力は、具体的な対象と症状パターンをセットで示すことです。たとえば https://example.com/wp-json/...、「ログイン済みの editor だけ遅い」、「TTFB が5分ごとに跳ね上がる」、「ログイン後に管理画面が止まる」 などです。こうした情報があると、wp-performance は推測ではなく、適切な計測経路を選びやすくなります。

どんな変更が許可されるかを伝える

安全な初回診断にしたいなら、それを明示してください。たとえば「読み取り専用の診断のみ」「cache flush はしない」「staging のみ、options は変更可」といった指定です。これにより wp-performance skill は危険な確認を避け、運用上の制約の中で動けます。

診断だけでなく修正への道筋も求める

最も質の高い wp-performance usage の結果は、ボトルネックだけでなく次の検証手順まで求めたときに得られます。たとえば「最も遅い層を特定し、原因の可能性が高いものを挙げ、改善を確認するための正確な次のコマンドまたはリクエストも示してほしい」と依頼します。これで出力がすぐ実行できる形になります。

最初のレポートを起点に反復する

最初の結果がクエリを示しているなら、遅い table、hook、route を返して、より絞った query plan を求めてください。autoload された options、object cache、cron、HTTP API 呼び出しが原因なら、最小限で安全な修正と、変更前後を比較する計測計画を依頼します。ここでこそ、wp-performance skill は Performance Optimization 作業で最も価値を発揮します。