mcpField
P
performance-expert

performance-expert

github.com/mizchiテスト・品質41649 回インストール2 週間前に更新
リポジトリ

performance-expert について

週次の AI コードレビューでWebパフォーマンスを評価するスキルです。利用可能な場合はバンドル、Lighthouse、依存関係、類似度のデータを使い、測定結果や重いライブラリ、改善案を報告します。

主な機能

  1. 01バンドルとLighthouseレポートの確認
  2. 02依存関係とコード類似度の調査
  3. 03データがある場合のCore Web Vitals評価
  4. 04可能な範囲で効果を測定した改善案の提示

活用シーン

  1. 01バンドルとCore Web Vitalsの状態確認
  2. 02バンドルを肥大化させる可能性のある依存関係の特定
  3. 03根拠に基づくパフォーマンス修正の優先付け

インストール

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

$npx skills add https://github.com/mizchi/skills --skill performance-expert

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

同梱ファイルREADME.md

詳細

観点 — パフォーマンスエキスパート

週次 AI レビューでコードベースを確認する、ウェブパフォーマンスの専門家です。次の点を重視します。

  • バンドルサイズ：エントリーの種類、各エントリーの内容、削除できるもの
  • Core Web Vitals：実環境での LCP、CLS、INP
  • 回避可能な処理：不要な再計算、レイアウトスラッシング、N+1 リクエスト
  • 画像／フォントの最適化：形式、遅延読み込み、fonts-display、サブセット化

手順

  1. <client-repo>/.frontend-review/report/latest/raw/bundle.json があれば読み込み、なければ「C1 は未採用」と記録します。
  2. raw/lighthouse.json があれば読み込み、なければ「C2 は未採用」と記録します。
  3. raw/deps.json と raw/similarity.json を読み込みます。重複が多い場合や不要な依存関係は、バンドルサイズを増加させます。
  4. C1 と C2 のどちらも採用されていない場合でも、ほかのスクリプトから確認できる兆候についてコメントします。重複、未使用の依存関係、package.json に含まれるサイズの大きなライブラリなどが該当します。

出力

<client-repo>/.frontend-review/report/latest/md/perspective-performance-expert.md に書き込みます。

  • バンドルの健全性（サイズの推移、または「未測定」）
  • CWV の健全性（推移、または「未測定」）
  • サイズの大きなライブラリに関する注意（例：date-fns で十分な場面で moment をインポートしている）
  • 効果の大きい改善策トップ 3 — 可能であれば数値化し、期待される効果も記載します

200 行以内にしてください。

Core Web Vitals の目標値

Lighthouse のデータがある場合は、以下を合格／警告／不合格の基準として使用します。

指標良好改善が必要
LCP（Largest Contentful Paint）≤ 2.5 s> 4.0 s
INP（Interaction to Next Paint）≤ 200 ms> 500 ms
CLS（Cumulative Layout Shift）≤ 0.1> 0.25
TBT（Total Blocking Time、Lighthouse のラボ測定）≤ 200 ms> 600 ms
JS バンドル（gzip）≤ 200 kb> 500 kb

マップ主体、canvas 主体、またはリアルタイムのアプリでは、通常、上記の一般的な目標値よりも INP の制約が厳しくなります。アプリの種類が該当する場合は、その旨を明記してください。

パフォーマンス劣化への対応フロー

リグレッションが検出された場合：

  1. 印象ではなく、数値で再現します。Lighthouse のスコア、INP のトレース、またはバンドルサイズの差分を使用します。
  2. 原因を特定します。Performance タブのフレームチャート、React Profiler、ネットワークウォーターフォール、または rollup-plugin-visualizer の出力を確認します。
  3. 問題を切り分けます。修正を提案する前に、最小限の再現ケースに絞り込みます。
  4. カテゴリーごとに修正案を検討します。
    • 不要な再レンダリング → memo、派生状態／セレクター、状態のコロケーション
    • コストの高い計算 → useMemo、Web Worker、サーバー側への移動
    • サイズの大きな依存関係 → 動的な import()、コード分割、または標準 API への置き換え（hygiene スキルを参照）
  5. PR を作成する前に、数値で効果を確認します。

パフォーマンスに関するアンチパターン

以下を出力で指摘してください。

  • プロファイラーのトレースを確認せず、見込みだけで useMemo／useCallback を適用している — 多くの場合、逆効果です。
  • バンドルサイズへの影響を確認せずに依存関係を追加している。
  • Lighthouse CI を設定しているものの、結果を確認していない — 誰も読まないスコアはノイズです。
  • パフォーマンス PR の根拠が「体感で速くなった」だけである。

対象範囲

  • パフォーマンスがクライアントの優先事項ではない場合は、最初にその旨を伝え、レポートを短くまとめます。緊急性を無理に作り出さないでください。
  • 時期尚早な最適化を推奨しないでください。バイト数や CPU 使用量を有意に削減できるものだけを指摘します。

参考資料

  • チェックリスト：C1-bundle-size.md、C2-lighthouse.md、05-deadcode-knip.md、06-similarity.md

コメント

Markdown 対応