Chrome DevTools MCPを使ってWeb performanceを分析する。Core Web Vitals（LCP、INP、CLS）とFCP、TBT、Speed Indexを計測し、render-blocking resources、network dependency chains、layout shifts、cache、accessibilityの問題を特定する。表示速度の監査・計測・デバッグ・最適化、Lighthouse scoreの改善で使用する。既定スタックの必須スキルではないoptional群であり、要件で明示された場合、またはapp-orchestratorがv1前の計測として指示した場合のみロードする。事前学習の知識より最新の公式ドキュメントを優先する。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
本ファイルは cloudflare/skills（Apache-2.0）を基に改変しています。詳細は リポジトリルートの ATTRIBUTION.md を参照。
Web performanceの計測名、閾値、tooling APIsは更新される。具体値や推奨を示す前に、事前学習の知識ではなく最新の公式情報を取得する。
Cloudflare製品ではないためcloudflare-docs MCPは使わず、次のWebページを第一手段にする(列構成はキット共通)。
| 取得先 | 取得方法 | 使う場面 |
|---|---|---|
| web.dev | https://web.dev/articles/vitals を取得 | Core Web Vitalsの閾値と定義 |
| Chrome DevTools docs | https://developer.chrome.com/docs/devtools/performance を取得 | Tooling APIsとtrace analysis |
| Lighthouse scoring | https://developer.chrome.com/docs/lighthouse/performance/performance-scoring を取得 | score weightsとmetric thresholds |
監査開始前に必ず行う。 navigate_pageまたはperformance_start_traceを呼び出す。利用できなければchrome-devtools MCP serverが未登録なので、計測したように報告せず、エージェントが登録を代行する(利用者にコマンドを打たせない。方針はapp-orchestratorのMCP接続原則と同じ)。登録後にclientを再起動し、上記toolを再確認してから監査へ進む。
# Claude Code(user scope。作業フォルダに依らず使える)
claude mcp add chrome-devtools --scope user -- npx -y chrome-devtools-mcp@latest
# Codex
codex mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
claude / codex コマンドが無い環境では登録をスキップし、計測を未実施として残課題に1行残す。
hero.png (450KB)をWebPへ圧縮」と示す。| 目的 | Tool Call |
|---|---|
| ページを開く | navigate_page(url: "...") |
| traceを開始する | performance_start_trace(autoStop: true, reload: true) |
| insightを分析する | performance_analyze_insight(insightSetId: "...", insightName: "...") |
| requests一覧を取得する | list_network_requests(resourceTypes: ["Script", "Stylesheet", ...]) |
| request詳細を取得する | get_network_request(reqid: <id>) |
| accessibility snapshotを取得する | take_snapshot(verbose: true) |
次のchecklistで進捗を管理する。
監査の進捗:
- [ ] 手順 1: Performance traceを取得
- [ ] 手順 2: Core Web Vitalsを分析（CLSの原因を含む）
- [ ] 手順 3: Networkを分析
- [ ] 手順 4: Accessibility snapshotを取得
- [ ] 手順 5: Codebaseを分析（第三者siteは省略）
対象URLを開く。
navigate_page(url: "<target-url>")
reload付きでperformance traceを開始し、cold-load metricsを取得する。
performance_start_trace(autoStop: true, reload: true)
trace完了を待って結果を取得する。
トラブル時:
navigate_pageでページが正常に開いたか確認するperformance_analyze_insightで主要metricsを取得する。
注意: insight namesはChrome DevToolsのversionで変わることがある。動作しない場合は、trace responseのinsightSetIdから利用可能なinsightsを確認する。
主なinsight names:
| Metric | Insight Name | 確認内容 |
|---|---|---|
| LCP | LCPBreakdown | TTFB、resource load、render delayの内訳 |
| CLS | CLSCulprits | layout shiftsを起こす要素（寸法のない画像、後から挿入されるcontent、font swap） |
| Render Blocking | RenderBlocking | first paintを妨げるCSS / JS |
| Document Latency | DocumentLatency | server response timeの問題 |
| Network Dependencies | NetworkRequestsDepGraph | critical resourcesを遅らせるrequest chains |
例:
performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")
主要閾値（good / needs-improvement / poor）:
下記は早見表であり、報告時は上記公式sourceの最新値を確認し、確認日を付ける。
全network requestsを取得し、改善候補を特定する。
list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])
確認項目:
<head>内でasync / defer / media attributesのないJS / CSSCache-Control、ETag、Last-Modified headersrequestの詳細は次で確認する。
get_network_request(reqid: <id>)
accessibility tree snapshotを取得する。
take_snapshot(verbose: true)
主な検出対象:
第三者siteでcodebaseへアクセスできない場合は省略する。 その場合は未実施として最終報告に明記する。
codebaseを読み、改善すべき実装箇所を特定する。
設定ファイルからstackを特定する。
| Tool | Config files |
|---|---|
| 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を使うbuild scripts |
| Parcel | .parcelrc, package.jsonのparcel field |
| 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のframework dependenciesとbuild scriptsも確認する。
mode: 'production'、package.jsonのsideEffects、usedExportsを確認するtreeshake optionsを確認するindex.jsのre-exports）、一括importされた大きなutility libraries（lodash、moment）content config）を確認する@babel/preset-env targetsとuseBuiltIns設定を確認するcore-js importsのサイズを確認するbrowserslist configが必要以上に広い環境を対象にしていないか確認するterser、esbuild、swcのminificationを確認する取得したtrace / insights / network requestsとcodebaseを相互照合し、推測のみの項目は確定事実と分ける。traceが取得できない、対象URLが開けない、codebaseへアクセスできない場合は、その範囲の断定を停止して未検証と明記する。
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。