web-perf

Web パフォーマンスの調査

対象ページ、報告された症状、関連するデバイス条件を特定します。監査の依頼では、調査結果を報告します。最適化または修正の依頼では、対応可能な変更を実施し、依頼された範囲内でその効果を検証します。

エビデンスの確認方法を選択する

利用可能なブラウザーおよびプロファイリングツールを確認してから使用します。利用可能な場合は Chrome DevTools のトレースを優先し、トレースとネットワークの調査については references/devtools.md を参照してください。例示されたパラメーターが現在のバージョンに適合すると決めつけず、インストール済みツールのスキーマを使用してください。

その MCP サーバーを利用できない場合は、既存のトレースまたは Lighthouse のアーティファクト、別の利用可能なプロファイラー、あるいは関連するソースコードを使用します。それらの情報源で可能な分析を完了し、測定できなかった内容を明記してください。プロファイリングツールがないことを理由に、ソースコードの調査を中断したり、MCP のインストールを強行したりしてはいけません。

診断する

結果に関係するページ／ビルド、ビューポート、デバイスまたはエミュレーション、ネットワーク／CPU のスロットリング、キャッシュ状態、操作を記録します。再読み込みしただけでは、コールドキャッシュであることは確認できません。モバイルとデスクトップの観察結果は分けて記録してください。

フィールドで測定する Core Web Vitals と、ラボでの測定値を区別します。読み込みのみのトレースでは INP は確認できません。TBT は診断用のラボ指標であり、INP の代わりにはなりません。評価を割り当てる際は現行の指標定義を使用し、測定できなかった指標は「利用不可」と記載してください。

トレースのインサイトから、リクエスト、要素、またはソースの該当箇所までボトルネックを追跡します。関連する LCP の各フェーズ、レイアウトシフトの要因、長時間タスク、リソースの検出遅延、キャッシュヘッダーを調査してください。特にサードパーティーのスクリプトや、後の操作でのみ使用されるリソースを削除するよう推奨する場合は、その所有者と用途を確認してください。推定削減量がゼロであることは、重大な問題の証拠ではありませんが、1 回のトレースだけでは、あるリソースが決して役に立たないとは証明できません。

検証して報告する

観察されたユーザーへの影響と確信度に基づいて、調査結果に優先順位を付けます。測定値、ツールによる推定値、未測定の仮説を区別し、重複するインサイトから得られる削減量を足し合わせて見積もらないでください。

修正を行う場合は、同等の条件下で対象の挙動を比較します。ばらつきが大きい場合や、主張する改善の規模に応じて、測定を繰り返してください。未解決のリグレッションリスクまたはプロジェクトのゲートがある場合に限り、テスト範囲を広げてから完了してください。

測定した症状、根拠のある原因、具体的な修正または推奨事項、関連する検証上の制約を報告します。比較に役立つ測定値が複数ある場合は、指標の表を追加してください。パフォーマンスに関する依頼を、アクセシビリティやコードベース全体の監査まで必須とする範囲に広げないでください。