wp-performance

WP パフォーマンス（バックエンドのみ）

使用する場面

次のような場合にこのスキルを使用します。

• 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 --all（警告とエラーのみ表示するには --spotlight を追加）
• または、パフォーマンスに重点を置いた実行ではチェック項目を指定します：wp doctor check autoload-options-size constant-savequeries-falsy constant-wp-debug-falsy

チェック名も --all も指定せずに 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 パターンを修正し、インデックスを改善し、コストの高いメタクエリを避けます。
  • 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（Largest Contentful Paint）が大幅に改善されます。

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

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

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

検証

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

障害パターン／デバッグ

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

エスカレーション

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