web-perf

Web パフォーマンス監査

Web パフォーマンスの指標、しきい値、ツールの API に関する知識は古くなっている可能性があります。具体的な数値や推奨事項を示す場合は、事前学習よりも情報の取得を優先してください。

情報の取得元

情報源	取得方法	用途
web.dev	https://web.dev/articles/vitals	Core Web Vitals のしきい値、定義
Chrome DevTools のドキュメント	https://developer.chrome.com/docs/devtools/performance	ツールの API、トレース分析
Lighthouse のスコアリング	https://developer.chrome.com/docs/lighthouse/performance/performance-scoring	スコアの重み付け、指標のしきい値

最初に：利用可能な MCP ツールを確認する

作業を始める前に、利用可能なブラウザーおよびパフォーマンス関連のツールを確認してください。依頼された監査に利用できる機能を使用してください。トレースツールが利用できない場合は、可能な範囲で情報源やネットワークの分析を続け、収集できなかった測定項目を明記してください。

ユーザーが Chrome DevTools MCP のセットアップを希望している場合は、そのインストールガイドを参照し、最新のパッケージバージョンを使用してください。セットアップがユーザーの許可範囲内にある場合に限り、MCP の設定を変更してください。そうでない場合は、先に確認してください。command と args を使用するクライアント向けのサーバーエントリーの例は次のとおりです。

"chrome-devtools": {
  "command": "npx",
  "args": ["-y", "chrome-devtools-mcp@latest"]
}

主なガイドライン

• 断定的に伝える：ネットワークリクエスト、DOM、またはコードベースを確認して主張を検証し、そのうえで調査結果を明確に伝えてください。
• 推奨する前に確認する：削除を提案する前に、使われていないことを確認してください。
• 影響を数値化する：分析から得られた削減見込みを使用してください。影響が 0ms の変更を優先しないでください。
• 問題でないものは省く：レンダリングを妨げるリソースの推定影響が 0ms であれば、その旨を記載するだけにして、対応は勧めないでください。
• 具体的に伝える：「画像を最適化する」ではなく、「hero.png（450KB）を WebP に圧縮する」と伝えてください。
• 優先順位を徹底する：LCP が 200ms で CLS が 0 のサイトはすでに優秀です。そのように伝えてください。

クイックリファレンス

タスク	ツール呼び出し
ページを読み込む	navigate_page(url: "...")
トレースを開始する	performance_start_trace(autoStop: true, reload: true)
分析情報を調べる	performance_analyze_insight(insightSetId: "...", insightName: "...")
リクエスト一覧を取得する	list_network_requests(resourceTypes: ["Script", "Stylesheet", ...])
リクエストの詳細を取得する	get_network_request(reqid: <id>)
A11y スナップショットを取得する	take_snapshot(verbose: true)

ワークフロー

進捗を記録するため、このチェックリストをコピーしてください。

Audit Progress:
- [ ] Phase 1: Performance trace (navigate + record)
- [ ] Phase 2: Core Web Vitals analysis (includes CLS culprits)
- [ ] Phase 3: Network analysis
- [ ] Phase 4: Accessibility snapshot
- [ ] Phase 5: Codebase analysis (skip if third-party site)

フェーズ 1：パフォーマンストレース

1. 対象の URL に移動します。

   navigate_page(url: "<target-url>")
   

2. 再読み込みを伴うパフォーマンストレースを開始して、初回読み込み時の指標を記録します。

   performance_start_trace(autoStop: true, reload: true)
   

3. トレースが完了するまで待ってから、結果を取得します。

トラブルシューティング：

• トレースの結果が空、または失敗した場合は、まず navigate_page でページが正しく読み込まれたことを確認してください
• 分析情報の名前が一致しない場合は、トレースの応答を調べて、利用可能な分析情報を一覧表示してください

フェーズ 2：Core Web Vitals の分析

performance_analyze_insight を使用して、主要な指標を抽出します。

注： インサイト名は Chrome DevTools のバージョンによって異なる場合があります。インサイト名が機能しない場合は、トレースのレスポンスに含まれる insightSetId を確認して、利用可能なインサイトを特定してください。

一般的なインサイト名：

指標	インサイト名	確認する内容
LCP	LCPBreakdown	最大コンテンツの描画までの時間。TTFB、リソースの読み込み、レンダリング遅延の内訳
CLS	CLSCulprits	レイアウトシフトの原因となる要素（寸法が指定されていない画像、挿入されたコンテンツ、フォントの切り替わり）
レンダリングブロック	RenderBlocking	初回描画をブロックする CSS／JS
ドキュメントの遅延	DocumentLatency	サーバーの応答時間に関する問題
ネットワーク依存関係	NetworkRequestsDepGraph	重要なリソースを遅延させているリクエストチェーン

例：

performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")

主な閾値（良好／改善が必要／不良）：

• TTFB：< 800ms ／ < 1.8s ／ > 1.8s
• FCP：< 1.8s ／ < 3s ／ > 3s
• LCP：< 2.5s ／ < 4s ／ > 4s
• INP：< 200ms ／ < 500ms ／ > 500ms
• TBT：< 200ms ／ < 600ms ／ > 600ms
• CLS：< 0.1 ／ < 0.25 ／ > 0.25
• Speed Index：< 3.4s ／ < 5.8s ／ > 5.8s

フェーズ 3：ネットワーク分析

最適化の機会を特定するため、すべてのネットワークリクエストを一覧表示します：

list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])

確認する項目：

1. レンダリングをブロックするリソース：async／defer／media 属性のない、<head> 内の JS／CSS
2. ネットワークチェーン：ほかのリソースの読み込み完了を待つため、発見が遅れるリソース（例：CSS のインポート、JS で読み込まれるフォント）
3. プリロードの不足：重要なリソース（フォント、ヒーロー画像、主要なスクリプト）がプリロードされていない
4. キャッシュの問題：Cache-Control、ETag、Last-Modified ヘッダーがない、または設定が不十分
5. 大きなペイロード：圧縮されていない、またはサイズが大きすぎる JS／CSS バンドル
6. 未使用のプリコネクト：指摘された場合は、そのオリジンへのリクエストが1件でもあったか確認してください。リクエストが0件なら、未使用であることが確実なため、削除を推奨します。リクエストはあるものの読み込みが遅い場合、プリコネクトには依然として価値がある可能性があります。

リクエストの詳細情報：

get_network_request(reqid: <id>)

フェーズ 4：アクセシビリティのスナップショット

アクセシビリティツリーのスナップショットを取得します：

take_snapshot(verbose: true)

主な不足項目を指摘します：

• ARIA ID の欠落または重複
• コントラスト比が低い要素（WCAG AA の基準を確認：通常のテキストは 4.5:1、大きなテキストは 3:1）
• フォーカストラップ、またはフォーカスインジケーターの欠落
• アクセシブルな名前のないインタラクティブ要素

フェーズ 5：コードベースの分析

コードベースにアクセスできないサードパーティーのサイトを監査する場合はスキップしてください。

改善できる箇所を把握するため、コードベースを分析します。

フレームワークとバンドラーの検出

設定ファイルを検索して、技術スタックを特定します：

ツール	設定ファイル
Webpack	webpack.config.js、webpack.*.js
Vite	vite.config.js、vite.config.ts
Rollup	rollup.config.js、rollup.config.mjs
esbuild	esbuild.config.js、esbuild を使うビルドスクリプト
Parcel	.parcelrc、package.json（parcel フィールド）
Next.js	next.config.js、next.config.mjs
Nuxt	nuxt.config.js、nuxt.config.ts
SvelteKit	svelte.config.js
Astro	astro.config.mjs

また、フレームワークの依存関係とビルドスクリプトについて、package.json も確認します。

ツリーシェイキングとデッドコード

• Webpack：mode: 'production'、package.json の sideEffects、usedExports 最適化を確認します
• Vite／Rollup：ツリーシェイキングはデフォルトで有効です。treeshake オプションを確認します
• 確認する項目：バレルファイル（index.js による再エクスポート）、ユーティリティライブラリ全体の一括インポート（lodash、moment）

未使用の JS／CSS

• CSS-in-JS と静的 CSS 抽出のどちらを使用しているか確認します
• PurgeCSS／UnCSS の設定（Tailwind の content 設定）を確認します
• 動的インポートと先行読み込みを特定します

ポリフィル

• @babel/preset-env のターゲットと useBuiltIns の設定を確認します
• core-js のインポート（サイズが大きすぎることがよくあります）を確認します
• browserslist の設定で、対象範囲が広すぎないか確認します

圧縮とミニファイ

• terser、esbuild、または swc によるミニファイを確認します
• ビルド出力またはサーバー設定で gzip／brotli 圧縮を確認します
• 本番ビルドのソースマップを確認します（外部ファイルにするか、無効にする必要があります）

出力形式

以下の形式で調査結果を提示します。

1. Core Web Vitals の概要 - 指標、値、評価（良好／改善が必要／不良）を記載した表
2. 主な問題 - 推定される影響度（高／中／低）を添えた、優先順位付きの問題リスト
3. 推奨事項 - コードスニペットや設定変更を含む、具体的で実行可能な修正案
4. コードベースの調査結果 - 検出したフレームワーク／バンドラー、最適化の機会（コードベースにアクセスできない場合は省略）