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 ツールを確認する

作業を始める前に実行してください。 navigate_page または performance_start_trace の呼び出しを試してください。利用できない場合は、作業を中止してください。chrome-devtools MCP サーバーが設定されていません。

ユーザーに MCP 設定へ以下を追加するよう依頼してください。

"chrome-devtools": {
  "type": "local",
  "command": ["npx", "-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>)
アクセシビリティスナップショットを取得する	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 の概要 - 指標、値、評価（good／needs-improvement／poor）を含む表
2. 主な問題 - 推定される影響（high／medium／low）を付記した、優先順位付きの問題リスト
3. 推奨事項 - コードスニペットまたは設定変更を含む、具体的で実行可能な修正案
4. コードベースの調査結果 - 検出したフレームワーク／バンドラー、最適化の機会（コードベースにアクセスできない場合は省略）