wp-performance

WP Performance（バックエンドのみ）

使用する場面

以下の場合にこのスキルを使用します。

• WordPress のサイト／ページ／エンドポイントが遅い場合（フロントエンドの TTFB、管理画面、REST、WP-Cron）
• プロファイリング計画とツールの推奨（WP-CLI profile/doctor、Query Monitor、Xdebug/XHProf、APM）が必要な場合
• DB クエリ、自動読み込みオプション、オブジェクトキャッシュ、cron タスク、リモート HTTP 呼び出しを最適化する場合

このスキルでは、エージェントがブラウザー UI を使用できないことを前提としています。WP-CLI、ログ、HTTP リクエストを優先してください。

必要な入力

• 環境と安全性：dev/staging/prod、制限事項（書き込み不可、プラグインのインストール不可など）。
• インストール先を指定する方法：
  • WordPress ルート --path=<path>
  • （マルチサイト／サイトの指定）--url=<url>
• パフォーマンスの症状と範囲：
  • 対象の URL／REST ルート／管理画面
  • 発生するタイミング（常時か断続的か、ログイン時かログアウト時か）

手順

0) ガードレール：最初に計測し、リスクの高い操作は避ける

1. 書き込み操作（プラグインのインストール、設定の変更、キャッシュのフラッシュ）を実行してよいか確認します。
2. 再現可能な対象（URL または REST ルート）を選び、ベースラインを記録します。
   • 可能であれば curl で TTFB／所要時間を計測します。
   • 利用可能であれば、WP-CLI のプロファイリングを実行します。

参照：

• references/measurement.md

1) バックエンドのみのパフォーマンスレポートを生成する（再現性あり）

実行：

• node skills/wp-performance/scripts/perf_inspect.mjs --path=<path> [--url=<url>]

以下を検出します。

• WP-CLI の利用可否とコアのバージョン
• wp doctor／wp profile の利用可否
• 自動読み込みオプションのサイズ（可能な場合）
• オブジェクトキャッシュのドロップインの有無

2) すぐに効果のある改善：詳細なプロファイリングの前に診断を実行する

WP-CLI を利用できる場合は、次を優先します。

• wp doctor check

本番環境でよくある設定上の問題（自動読み込みの肥大化、SAVEQUERIES/WP_DEBUG、プラグイン数、更新）を検出できます。

参照：

• references/wp-cli-doctor.md

3) 詳細なプロファイリング（ブラウザー不要）

次の順序を推奨します。

1. wp profile stage で、どこに時間がかかっているかを確認します（bootstrap/main_query/template）。
2. wp profile hook（必要に応じて --url= を指定）で、時間のかかるフック／コールバックを特定します。
3. wp profile eval で、対象を絞ったコードパスを調べます。

参照：

• references/wp-cli-profile.md

4) Query Monitor（バックエンドのみでの使用）

Query Monitor は通常 UI で操作しますが、REST API のレスポンスヘッダーと _envelope レスポンスを使えば、ヘッドレス環境でも利用できます。

• 認証します（nonce または Application Password）。
• REST レスポンスをリクエストし、ヘッダー（x-qm-*）や ?_envelope 使用時の qm プロパティを確認します。

参照：

• references/query-monitor-headless.md

5) カテゴリー別に修正する（主要なボトルネックを選ぶ）

プロファイルの出力を参考に、主要なボトルネックのカテゴリーを1つ選びます。

• DB クエリ → クエリ数を減らし、N+1 パターンを修正し、インデックスを改善して、コストの高い meta クエリを避けます。
  • references/database.md
• 自動読み込みオプション → サイズの大きい自動読み込みオプションを特定し、大きなデータの自動読み込みを停止します。
  • references/autoload-options.md
• オブジェクトキャッシュのミス → キャッシュを導入するか、キャッシュキー／グループの使い方を修正します。適切な場合は永続オブジェクトキャッシュを追加します。
  • references/object-cache.md
• リモート HTTP 呼び出し → タイムアウト、キャッシュ、バッチ処理を追加し、すべてのリクエストでリモート API を呼び出すのを避けます。
  • references/http-api.md
• Cron → 期限到来によるスパイクを抑え、イベントの重複を解消し、負荷の高いタスクをリクエスト処理の外に移します。
  • references/cron.md

6) 検証する（同じ計測を繰り返す）

• 同じ wp profile／wp doctor／REST リクエストを再実行します。
• パフォーマンスの変化と、動作に変更がないことを確認します。
• 修正にリスクがある場合は、可能であればフィーチャーフラグを使用するか、段階的にロールアウトします。

WordPress 6.9 のパフォーマンス改善

プロファイリングの際は、以下の 6.9 の変更点にご注意ください。

クラシックテーマ向けのオンデマンド CSS：

• クラシックテーマでもオンデマンド CSS 読み込みが可能になりました（以前はブロックテーマのみが対象でした）。
• ページで実際に使用されているブロックのスタイルのみを読み込むため、CSS のペイロードが 30～65% 削減されます。
• クラシックテーマをプロファイリングしている場合、この改善はすでに反映されているはずです。

レンダリングをブロックするリソースがないブロックテーマ：

• カスタムスタイルシートを定義していないブロックテーマ（Twenty Twenty-Three／Four など）は、レンダリングをブロックする CSS がゼロの状態で読み込めるようになりました。
• スタイルはグローバルスタイル（theme.json）と個別のブロックスタイルから取得され、すべてインライン化されます。
• これにより、LCP（最大コンテンツ描画）が大幅に改善されます。

インライン CSS の上限を引き上げ：

• 小さなスタイルシートをインライン化するしきい値が引き上げられ、レンダリングをブロックするリソースが減少しました。

参考：https://make.wordpress.org/core/2025/11/18/wordpress-6-9-frontend-performance-field-guide/

検証

• ベースラインと変更後の数値を取得します（同じ環境、同じ URL／ルート）。
• 該当する場合、wp doctor check に問題がない（または改善している）ことを確認します。
• ログに新たな PHP エラーや警告がないことを確認します。
• 正常性を保つためにキャッシュのフラッシュが不要であることを確認します（キャッシュのフラッシュは最終手段にしてください）。

失敗時の対処／デバッグ

• コードを変更しても「変化がない」場合：
  • 別の URL／サイトを計測している（--url の不一致）、キャッシュに結果が隠されている、またはオペコードキャッシュが古い可能性があります。
• プロファイリングデータにばらつきがある場合：
  • バックグラウンドタスクを停止し、キャッシュをウォームアップした状態でテストを行い、複数回計測してください。
• SAVEQUERIES／Query Monitor によってオーバーヘッドが発生する場合：
  • 明示的に承認されていない限り、本番環境では実行しないでください。

エスカレーション

• 本番環境で明示的な承認を得ていない場合、以下の操作は行わないでください：
  • トラフィック発生中にプラグインをインストールする、SAVEQUERIES を有効にする、負荷テストを実施する、またはキャッシュをフラッシュする。
• システムレベルのプロファイリング（APM、PHP プロファイラー拡張機能）が必要な場合は、運用チーム／ホスティング事業者と調整してください。