mcpField
P
perf-audit

perf-audit

github.com/helderbertoテスト・品質1942 回インストール2 日前に更新
リポジトリ

perf-audit について

Webのビルド成果物とソースコードのリスクを評価する、開発者向けパフォーマンス監査スキルです。出力ファイルのサイズや依存関係、Core Web Vitalsに関するリスクを調べ、ブラウザーやサーバーを起動せずに結果をまとめます。

主な機能

  1. 01ビルドツールの検出
  2. 02本番ビルドの分析
  3. 03生サイズとgzipサイズの報告
  4. 04大きな依存関係の確認
  5. 05Core Web Vitalsのソースリスク調査
  6. 06監査結果の整理

活用シーン

  1. 01リリース前のバンドルサイズ評価
  2. 02大きなチャンクや依存関係の特定
  3. 03読み込みと描画に関するソースリスクの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/helderberto/agent-skills --skill perf-audit

インストール後、Claude Code で/perf-auditを入力して読み込まれたか確認します。

詳細

パフォーマンス監査

ワークフロー

  1. package.json からビルドツールを検出します(vite、webpack、next、rollup)

  2. プロジェクトのタスクランナーを使って本番ビルドを実行します(package.json から自動検出します)。

  3. ビルド出力を分析します。非インタラクティブな方法に限ります。監査中にブラウザーを起動したり、長時間実行されるサーバーを起動したりしないでください。自動実行が停止する原因になります。次の順に優先してください。

    • 出力されたファイルを直接測定する:出力ディレクトリ内の各ファイル(例:dist/assets/*.js)について、非圧縮サイズと gzip 圧縮後のサイズを報告します — gzip -c <file> | wc -c。これは常に機能し、追加のツールも不要です。
    • 静的な成果物としてモジュールごとの内訳を作成する(サーバーではありません)。$TMPDIR(未設定の場合は /tmp)の下に作成し、作業ツリーには絶対に置かないでください。次の commit で一緒に取り込まれる可能性があります。パスを表示してください。
      • Vite/Rollup:npx source-map-explorer 'dist/assets/*.js' を実行するか、rollup-plugin-visualizer を追加し、JSON/HTML をファイルに出力するよう設定します
      • webpack/Next.js:npx webpack-bundle-analyzer -m static -r "${TMPDIR:-/tmp}/report.html" <stats-file> を実行します(ファイルを書き出します。デフォルトのサーバーモードは使用しないでください)
    • npx vite-bundle-visualizer はブラウザーを開いて処理を停止させます。手動で調査するための方法としてユーザーに提案する場合に限り、ここでは実行しないでください。
  4. package.json で、既知のサイズの大きいパッケージを確認します。

  5. 以下の Core Web Vitals のリスク について、ソースを確認します。最初にフレームワークを検出し、そのフレームワークの慣例に沿った方法のみを推奨してください。

  6. 調査結果を報告します。バンドルのサイズへの影響と、ソースに起因するリスクの潜在的な影響を記載してください。

業界標準のしきい値と比較し、gzip 圧縮後のサイズを報告してください。

Core Web Vitals のリスク

次の項目についてソースを確認します。測定するまでは、いずれも「潜在的な影響」です。

  • LCP:ヒーロー画像や見出しが遅延読み込みされていない。LCP 画像が初期 HTML にあり、fetchpriority="high" が指定されている。defer/async のない <head> 内のスクリプトがない。重要なフォントがプリロードされている
  • CLS:画像、iframe、埋め込みコンテンツの表示領域が確保されている(width/height または aspect-ratio)。既存のコンテンツより上に何も挿入されない。フォントに font-display と適切なフォールバックが指定されている
  • INP:イベントハンドラー内で長時間の同期処理がない。長いループでは処理を譲る(scheduler.yield()、フォールバックとして setTimeout)。負荷の高い処理はワーカーで実行する
  • レンダリング:長いリストは仮想化されている。アニメーションには transform/opacity を使用する。読み取り後に書き込みを行うレイアウト処理のループがない。効果が見込める場合にのみメモ化する
  • ネットワーク:独立したリクエストは逐次的な await ではなく並列で行う。過剰なデータ取得がない。リストはページネーションされている。ハッシュ付き静的アセットは長期間キャッシュされている。負荷の高いサードパーティ製ウィジェットはファサードの背後に配置する

出力形式

  • バンドルの概要:合計サイズ / gzip 圧縮後のサイズと予算との比較
  • 大きなチャンク:名前 + サイズ + 合計に占める割合
  • サイズの大きい依存関係:パッケージ + サイズ + より軽量な代替案
  • すぐにできる改善:推定削減量の大きい順
  • Core Web Vitals:LCP、INP、CLS — 値 + ソース、または not measured
  • ソースのリスク:file:line、リスクのある指標、修正方法

ルール

  • gzip 圧縮後のサイズ(ブラウザーがダウンロードするサイズ)を報告します
  • 依存関係を自動的に変更しないでください。報告して提案するだけにしてください
  • ユーザーが提供した測定結果(Lighthouse または PageSpeed の JSON、CrUX データ、DevTools のトレース)がない限り、LCP、INP、CLS の値を断定しないでください。ラボデータかフィールドデータかを明記してください
  • Core Web Vital やバンドルに明確な効果が見込めないマイクロ最適化は省略してください

エラー処理

  • ビルドに失敗した場合 — エラーを報告し、バンドルの手順を省略します。ソースのチェックは引き続き実行してください
  • ビルド出力が見つからない場合 — まず本番ビルドを実行します
  • ビルドツールを特定できない場合 — package.json でサイズの大きいパッケージを調べてから、ソースのチェックを実行します

コメント