web-perf

Web パフォーマンス監査

Chrome DevTools MCP ツールを使用して、Web ページのパフォーマンスを監査します。このスキルでは、Core Web Vitals、ネットワークの最適化、アクセシビリティに関する大まかな問題に焦点を当てます。

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