web-perf

web-perf の概要

web-perf でできること

web-perf skill は、スクリーンショットや Lighthouse のスコアだけで推測するのではなく、Chrome DevTools MCP を使ってページ速度を監査し、改善するための skill です。Core Web Vitals、trace ベースの診断、ネットワークウォーターフォール、レンダーブロック、レイアウトシフト、キャッシュ、そして関連するアクセシビリティ／パフォーマンス課題に重点を置いています。

どんな人に向いているか

実際のサイトについて実用的なパフォーマンス調査をしたいなら、この web-perf skill を使うべきです。特に、なぜページが重く感じるのか、なぜ指標が悪化したのか、どのリソースが読み込みを妨げているのかを説明したい場面に向いています。証拠を重視する Performance Optimization の作業との相性が非常に良く、一般論よりも根拠のある判断が求められるときに力を発揮します。

何が違うのか

web-perf の最大の価値は、古い思い込みではなく、現行のドキュメントや DevTools データをその場で取得することに寄っている点です。そのため、正確な指標定義、trace の読み解き、現在のツールの挙動に依存する判断に強いです。一方で、広い意味での SEO 監査や、パフォーマンストレースを必要としないデザイン批評にはあまり向いていません。

web-perf skill の使い方

環境をインストールして動作確認する

まず skills manager から web-perf install のフローを実行し、その後で分析を依頼する前に Chrome DevTools MCP server が実際に利用可能か確認してください。この skill は DevTools へのアクセスを前提にしています。MCP tools が見つからないなら、結果を作り出そうとせず、そこでワークフローを止めるべきです。

パフォーマンス向けのプロンプトを与える

よい web-perf usage プロンプトには、ページ名、症状、そして agent が再現や確認に必要な文脈が含まれています。たとえば、「最新リリース後の LCP 悪化について、モバイル版のホームページを監査して。ブロッキング CSS、ヒーロー画像の配信、trace の証拠に注目して」といった形です。「このサイトを速くして」よりも、何を測り、どこを見るべきかが明確になるので有効です。

先に読むべきファイルを確認する

まず SKILL.md を読み、その後で取得元、tool のチェック、分析手順を説明している repo 参照の docs に進んでください。この repo には追加の helper フォルダはないため、主要な判断ポイントは skill file 自体にあります。特に、MCP tools の検証、retrieval の優先、仮定ではなく trace の証拠を使うよう指示している section に注意してください。

質問に合うワークフローを使う

診断なら、trace に基づく root cause と短い修正候補リストを依頼してください。最適化なら、網羅的なチェックリストではなく、見込みの大きい改善点から先に出してもらうのがよいです。リグレッションの追跡なら、変更前後の差分、URL、デバイス種別、そして LCP・INP・CLS のどれを重視するかを伝えてください。入力が具体的であるほど、モデルはどの web-perf guide の経路を取るべきかを推測せずに済みます。

web-perf skill FAQ

web-perf は Lighthouse 風の監査専用ですか？

いいえ。Lighthouse 関連の作業にも役立ちますが、より強い用途は DevTools MCP を使った trace ベースのデバッグです。つまり、指標が変わったことだけでなく、なぜ変わったのかを理解する助けになります。

Chrome DevTools に詳しくないと使えませんか？

必ずしもそうではありません。問題を明確に説明できる人なら、初心者でも十分役立ちます。trace の専門家である必要はありませんが、どのページ、どのデバイス、どの症状が重要かを伝えられる程度の文脈は必要です。

どんなときに web-perf を使わないべきですか？

一般的なフロントエンドのリファクタリング、見た目中心のデザインレビュー、あるいは実行時の証拠に依存しない回答が欲しいときには使わないでください。確認したいページを用意できない場合や、DevTools MCP が使えない場合も、この skill は実行できません。

通常のプロンプトより何が優れているのですか？

通常のプロンプトは、たいてい抽象度が高いまま終わります。web-perf skill は、最新ドキュメントの参照、明示的な tool チェック、そしてレンダーブロック、依存関係の連鎖、レイアウトシフトの発生源、キャッシュ挙動といった測定可能な原因へと話を寄せるので、より実行可能です。そのため、単発のチャット指示よりも Performance Optimization に向いています。

web-perf skill の改善方法

曖昧な目標ではなく、追跡可能な入力を渡す

web-perf の結果を最も改善しやすいのは、URL、対象デバイス、テスト条件、そして最重要の指標を渡すことです。「checkout を速くしたい」では弱すぎます。「新しい hero banner 公開後の checkout を、中位 Android・高速 4G 条件で LCP と CLS の観点から監査して」のほうがはるかに有効です。

変更時期と疑わしい原因を共有する

何が変わったか分かっているなら、必ず伝えてください。リリースノート、最近の CMS 更新、新しい third-party script、あるいは刷新された hero は、調査の方向をかなり絞り込めます。そうすることで、skill はページ全体を闇雲に見るのではなく、ありそうな原因を優先して検証できます。

証拠と優先順位付きの修正ルートを求める

有用な web-perf の出力は、確定した原因と可能性が高い原因を分け、そのうえでユーザー影響と実装コストの順に修正案を並べるべきです。最初の回答が広すぎる場合は、上位 2 つのボトルネック、その根拠となる trace の証拠、そして改善確認のための最小限で安全な変更を求めてください。

変更前後の計測で反復する

最初の実行は結論ではなく、診断の開始点だと考えてください。修正を入れたら、同じページと同じ条件で同じ web-perf ワークフローを再実行し、trace の証拠と指標を一貫して比較できるようにします。これが、web-perf guide を再現可能な最適化ループに変える最短ルートです。