SKILL ARTICLE / web-perf
web-perfで計測から直す順番を決める
推測ではなく、ブラウザーの計測から改善順を決める。
Chrome DevTools MCPでページのトレース、ネットワーク、アクセシビリティツリーを調べ、計測結果に結び付いた改善候補を優先順に整理するCloudflare公式Skillです。
OVERVIEW → CAN DO → BUILD
知ったことをSkillづくりに活かす
性能改善の一般論を先に当てはめず、トレースとネットワーク要求から影響のある対象を絞り、コードへ結び付く提案だけを優先する。
計測値と対象リソースを根拠に、直す項目と見送る項目を分けられる。
web-perfは最初にChrome DevTools MCPの操作を試し、利用できなければ停止します。自分たちのSkillでも、必要な権限、コマンド、接続先を冒頭で機械的に確かめ、代替できない前提が欠...
01 / OVERVIEW
Skillの概要
Cloudflareのweb-perfは、Chrome DevTools MCPを使ってWebページの表示性能を調べる公式Skillです。最初にMCPの操作が利用できるかを確認し、使えない場合は監査を始めません。利用できる場合は、ページを再読み込みしてパフォーマンストレースを取り、Core Web Vitals、レンダリングを妨げるリソース、通信の依存関係、キャッシュ、大きな転送データなどを順に確認します。
公式Skillは、数値の基準やツールのAPIが変わり得るため、web.dev、Chrome DevTools、Lighthouseの現行公式資料を取り直してから使う方針です。改善案を出す前にも、ネットワークリクエスト、DOM、またはコードで原因候補を確認し、推定短縮時間が0ミリ秒の項目を優先しないよう求めています。
この記事では、Cloudflare公式リポジトリのcommit `30553f89ae1ef1e3c2917cd09d72dac992bb4e9a` を2026年8月7日に確認しました。web-perf本文に関する直近のcommitは2026年4月1日で、リポジトリのプラグインversionは1.0.0です。公開READMEはOpenAI Codexを含むAgent Skills対応クライアントを対象にしていますが、このSkillの実行にはChrome DevTools MCPが別途必要です。
02 / CAN DO
できるようになること
URLを渡すと、まず再読み込み時のトレースを取り、LCPやCLSなどの計測値と、遅延に関係するリソースや通信経路を対応付けて調べられます。続いてネットワーク要求とアクセシビリティツリーを確認し、コードへアクセスできる場合だけフレームワークやビルド設定も読みます。
結果は、主要指標の表、影響順の問題一覧、具体的な改善案、必要に応じたコード側の所見という形で整理されます。「画像を最適化する」のような一般論ではなく、対象リソースと確認できた影響を添えて次の作業を決めやすくするSkillです。
ただし、1回のブラウザートレースは実利用者全体の体験を表すものではありません。ログイン状態、端末、回線、キャッシュ状態などで結果は変わります。また、アクセシビリティツリーの確認は完全なアクセシビリティ監査ではなく、本番トラフィックの監視や変更後の効果測定も別の作業です。
活かしやすい場面
- 表示が遅いページの原因候補を絞る
- リリース前後の主要な性能差を調べる
- 一般的な改善案を計測結果に結び付ける
使う前に確認したい場面
- 単発トレースだけで実利用者全体の体験を断定する作業
- アクセシビリティ適合を自動で保証する監査
- 権限確認なしでログイン後や非公開ページを調べる作業
03 / BUILD
自分たちのSkill作成に活かせること
文章やコードをそのまままねるのではなく、自分たちのSkillに取り入れたい判断基準や工程の分け方を整理しました。
前提ツールがなければ作業を始めない
web-perfは最初にChrome DevTools MCPの操作を試し、利用できなければ停止します。自分たちのSkillでも、必要な権限、コマンド、接続先を冒頭で機械的に確かめ、代替できない前提が欠けているときは推測で先へ進まない構成にできます。
観測、原因候補、提案を段階で分ける
トレース、指標別の分析、ネットワーク、コードという順番を置くことで、一般的な改善策を先に並べずに済みます。自分たちのSkillでも、まず観測事実を固定し、次に原因候補を絞り、最後に提案へ変換すると、どの証拠から提案が生まれたかを追いやすくなります。
変わりやすい数値は現行資料へ取りに行く
Skill本文には指標の目安がありますが、同時に現行の公式資料を優先するよう明記されています。自分たちのSkillでは、安定した調査手順と、更新される基準値・API名を分け、後者には確認先と確認時点を残すと古い知識による断定を減らせます。
04 / WORKFLOW
実際に使うときの流れ
- 01
前提を確認
対象URL、計測条件、閲覧権限、Chrome DevTools MCPの利用可否を確かめる。
- 02
トレースを取得
再読み込み時の計測から主要指標と利用できるinsightを記録する。
- 03
原因候補を照合
ネットワーク、DOM、アクセシビリティツリー、利用可能ならコードを確認する。
- 04
優先順位を決定
確認できた影響と対象を添え、着手する項目と見送る項目を分ける。
05 / TRY
試すときに使える依頼文
最初は、結果を自分で確かめやすい題材に使ってみてください。Skillがどこまで判断できるのか、どこで人の確認が必要なのかがわかります。
この公開URLを読取専用で監査してください。最初にChrome DevTools MCPの利用可否と計測条件を確認し、再読み込み時のトレース、Core Web Vitals、ネットワーク要求を調べてください。コードへアクセスできる場合だけ対象ファイルを照合し、各提案に計測値、対象リソースまたはファイル、確認方法を付けてください。推定効果が0の項目は優先せず、変更は行わないでください。単発計測の限界と追加確認が必要な点も分けてください。06 / INSTALL
導入方法を確認する
コマンドや配置方法は更新されることがあります。実行する前に、公開元の最新READMEとライセンスを確認してください。
npx skills add https://github.com/cloudflare/skills --skill web-perf --agent codex --copy --yes07 / WATCHOUTS
人が確認するところ
- ログイン後や非公開ページでは、計測前に閲覧権限と記録される通信内容を確認してください。
- 単発のラボ計測を実利用者全体の結果として扱わず、必要に応じて別条件や実利用者データで確認してください。
- アクセシビリティツリーの所見だけで適合を断定せず、キーボード操作や支援技術を含む追加確認を行ってください。