performance-optimization
画面とサーバーの性能を、測ってから直させる。測る・突き止める・直す・測り直す・守るの 5 段で進め、測り直して差が誤差の内なら元に戻させる。N+1・索引・接続の数・キャッシュ・画像・再描画・バンドルの直し方を例つきで添える
npx skills add addyosmani/agent-skills/performance-optimization入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 69,662
- 実用度
- 43
- GitHub star
- 113,697
- 最終更新
- 2026/11/2
頼み方の例
そのままコピーして使えますperformance-optimizationスキルを使って、一覧画面の遅さを調べてください。まず今の数値を測って基準を記録し、原因を 1 つに絞ったところで止めて、直すのは私が確認してからにしてください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
- ファイルを書き換える記述があります
- パッケージを導入する記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: bash、javascript
この解説は再確認中です。 2026年10月30日に原本（SKILL.md）が更新されており、以下の解説が現在の内容と合っていない可能性があります。最新の内容は GitHub の SKILL.md を確認してください。
いつ使うか
性能の問題があるという証拠があって、それを測って直したいときに使います。本文の「使うとき」は、仕様に性能の要件がある（読み込みの時間の予算や応答の時間の約束）、利用者や監視が遅さを報告している、Core Web Vitals が基準を下回る、変更で遅くなった疑いがある、大きなデータや多くの通信を扱う機能を作る、の 5 つです。
最初の一文が「最適化の前に測れ」です。測らない性能の作業は当て推量で、大事なところを良くしないまま複雑さだけを足す、と書いています。
- 進め方（測る・突き止める・直す・測り直す・守る）
- 5 段
- 例つきの直し方（サーバー 5・画面 3）
- 8 つ
- 同梱ファイル（2026-10-23 時点）
- 1 件
- SKILL.md（2026-10-23 時点）
- 16,698 バイト
5 段で進める
- 測る実際のデータで基準を取る
- 突き止める思い込みではなく、実際の詰まりを見つける
- 直す突き止めた 1 つだけを直す
- 測り直す同じやり方で測り、残すか戻すかを決める
- 守る監視か試験を足して、また遅くならないようにする
測るのは 2 通り、両方使う
1 つは Lighthouse や DevTools の Performance タブのような、条件をそろえて再現できる合成の計測です。CI で遅くなったのを捕まえ、個別の問題を切り分けるのに向きます。もう 1 つは web-vitals ライブラリや CrUX のような、実際の利用者の環境での計測で、直したことで体験が良くなったかを確かめるのに要る、と書かれています。
本文は Core Web Vitals の基準も表で示しています。
| 指標 | 良い | 改善が要る | 悪い |
|---|---|---|---|
| LCP | 2.5 秒以下 | 4.0 秒以下 | 4.0 秒超 |
| INP | 200ms 以下 | 500ms 以下 | 500ms 超 |
| CLS | 0.1 以下 | 0.25 以下 | 0.25 超 |
症状から、測り始める場所を決める
何が遅いかで分けた木が載っています。初回の読み込み（バンドルの大きさ、サーバーの応答、描画を止める資源）、操作のもたつき（主スレッドの 50ms を超える長い処理、再描画、強制的な再レイアウト）、画面を移ったあと（API の応答、取得の連鎖）、サーバーと API（1 つの口だけ遅いのか、全部遅いのか、時々遅いのか）の 4 つです。
直すのは、突き止めた 1 つだけ
- N+1 の問い合わせ行ごとに問い合わせず、関連を同じ問い合わせで取る
- 上限の無い取得一覧の口は件数の上限と安定した順で必ずページ送り
- 索引を使わない問い合わせ索引を足す前に EXPLAIN ANALYZE で実行計画を読む
- 接続の枯渇プールはプロセスに 1 つ。台数かける上限をデータベースの上限の内に
- キャッシュの欠け作るのが重く、変わるより読まれるほうがずっと多いものだけ
- 画像幅と高さを必ず書く。LCP の画像は優先度を上げ、下の画像は遅延読み込み
- 余計な再描画描画のたびに作る値を外へ出す。memo は計測が重いと示した所だけ
- 大きなバンドル経路ごとの分割と、重くて使われにくい機能の遅延読み込み
それぞれの具体的な直し方は、同梱の references/optimization-patterns.md に例つきで載っています。本文は、要るものだけを、そのコードに着いたときに開け、と案内しています。
索引は「足す」ではなく「読む」
「索引を足せ」は推測で、実行計画が計測だ、という書き方です。索引が無い全件の走査、行数の見積もりが実際と桁で違う（統計が古いので索引ではなく ANALYZE を流す）、走査の上に並べ替えが載っている、の 3 つでそれぞれ直し方が違います。
選択性の低い多数派の値、先頭が % の LIKE、列に関数をかけた条件には、ふつうの索引は効きません。索引はすべての書き込みにかかる税で、付けたあとに実行計画が変わらないなら戻せ、と書かれています。
キャッシュの鍵は正しさを決める
応答を変える入力（テナント・言語・権限・機能の切り替え）は全部、キャッシュの鍵に入れます。閲覧者を鍵から外すと、ある利用者のデータが別の利用者に出る、と本文は警告しています。
古さが正しさの不具合になるもの（残高・権限・決済時の在庫）はキャッシュしません。無効にするやり方は 1 つに決め、許せる古さの幅をはっきり書け、とも書かれています。
測り直して、差が無ければ戻す
| 基準との比較 | 扱い |
|---|---|
| 閾値を超えて良くなり、試験も緑 | 残す。前後の数値をコミットのメッセージに書く |
| 誤差の内で差が無い | 戻す |
| 悪くなった | 戻す |
| 良くなったが試験が赤 | 戻す |
測り直しは、基準と同じコマンド・同じ条件・同じ回数で行います。変えるのは一度に 1 つで、±5% の揺れの中の 3% の改善は改善ではない、と書かれています。
試したことは、戻したものも記録する
戻した変更は git の履歴に残らないので、同じ失敗を次の四半期にまた試すことになる、という理由です。プルリクエストの説明の節か、リポジトリの PERF.md に、試したこと・前後の数値・判定・理由の表を残せ、としています。
また遅くならないように守る
画面のある機能では、取り込む前の合成の計測による予算の関門と、実際の利用者の数値（p75）の監視の 2 層を勧めています。予算の例は、初回の JavaScript が gzip で 200KB 未満、CSS が 50KB 未満、上の方の画像が 1 枚 200KB 未満、フォントが合計 100KB 未満、API の応答が p95 で 200ms 未満などです。
使わないほうがいいとき
本文が名指しで外しているのは、問題の証拠が無いうちの最適化です。早すぎる最適化は、得られる性能より高くつく複雑さを足す、と書いています。
- ページの遅さを DevTools で測って報告したい計測と勧め方の決まりが中心の側
- 変更全体をレビューしたい性能は 5 つの軸の 1 つとして見る側
- 画面の部品を作る骨組みの表示や応答型まで含む側
測って報告するのが目的なら
web-perf は Chrome DevTools でページを測り、何をどう勧めるかに決まりを持たせたスキルです。効果が 0 ミリ秒のものは勧めない、他人のサイトならソースは見ない、など、報告の質に重きがあります。
このスキルは、自分のコードを直し、測り直して残すか戻すかまでを扱います。サーバーの問い合わせ・接続・キャッシュまで含むので、画面の速さだけを見たいなら web-perf のほうが軽く済みます。
変更全体を見たいなら
取り込む前に差分全体を見るなら、同じ公開元の code-review-and-quality が性能を 5 つの軸の 1 つとして点検し、詳しい計測と最適化はこのスキルを見よ、と案内しています。
React と TypeScript 以外
画面の例は React（React.memo・useMemo・Suspense）、サーバーの例は TypeScript の ORM 風の書き方と SQL です。考え方はほかの構成でも使えますが、例をそのまま写すことはできません。
注意点
SKILL.md には、外部の宛先へデータを送る記述はありません。シェルで動かすものとして、CI の例に npx bundlesize --config bundlesize.config.json と npx lhci autorun が挙がっています。直すことが仕事なので、作業ではコードが書き換わり、効果が無ければ戻されます。
試験を変えて得た改善は改善ではない
正しさが指標に先立つ、という決まりがあります。検証を飛ばす、新しさが要るものをキャッシュする、要る await を外す、のように、製品に要る仕事を落として速くしたものは後退だ、と書かれています。危険の兆しにも「試験を変えた・飛ばした・消した上での改善」が入っています。
予算や数字には出典が付いていない
予算の例（バンドル 200KB など）は本文の目安で、根拠は書かれていません。「100ms の遅れが成約率に響くという研究がある」という一文にも出典は示されていないので、目安として読むのが妥当です。
同梱は 1 件、点検表はフォルダの外
同梱は references/optimization-patterns.md の 1 件で、9,692 バイトです（2026-10-23 時点）。本文と同梱ファイルが案内する詳しい点検表 performance-checklist.md は、リポジトリの直下の references/ にあり、スキルのフォルダの外です。このスキルを 1 件だけ入れると、点検表は手元に無いことがあります。
ライセンス
リポジトリのライセンスは MIT です。
インストール数の推移
日次で記録10月18日 〜 11月7日（20日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
code-review-and-quality
取り込む前の変更を、正しさ・読みやすさ・設計・セキュリティ・性能の 5 つの軸で見させる。指摘には重さの札を付けて大事なものから並べさせ、試験が回帰を捕まえるかは条件を 1 つ反転させて実際に確かめさせる
frontend-ui-engineering
画面の部品を、本番に出せる水準で作らせる。部品の分け方・状態の置き場所・デザインシステムへの従い方・WCAG 2.1 AA の操作性までを決まりとして渡し、AI が作ったと分かる見た目の癖 8 つを名指しで避けさせる
web-perf
サイトの表示の遅さを実測で調べさせる。Chrome DevTools で計測し、効果が 0 ミリ秒の改善は勧めさせない
よくある質問
直しても数値が変わらなかったらどうなりますか
元に戻します。本文は「中立は残すのではなく戻す」と言い切っていて、残したコードは永遠に保守することになる、それに見合う働きをさせよ、と書いています。戻した試みも、試したことの記録の表に残して、次の人やエージェントが同じことを試さないようにします。
サーバー側の遅さにも使えますか
使えます。測る例には応答の時間の記録、アプリの性能監視、時間付きの問い合わせの記録、console.time が挙がっていて、直し方の 8 つのうち 5 つ（N+1・上限の無い取得・索引・接続の枯渇・キャッシュ）がサーバー側です。
同じリポジトリの `/webperf` とは何が違いますか
公開元の /webperf は、web-performance-auditor という役のサブエージェントを出して Web の性能を監査し、報告を返す命令です（2026-10-23 確認）。その役の定義は、細かい最適化の手引きと直し方はこのスキルに任せ、報告は監査の水準にとどめよ、と書いています。監査の報告が欲しいなら /webperf、直して測り直すならこのスキル、という分担です。
対応しているエージェントはどれですか
公開元の README が、Claude Code（推奨と明記）と Codex のそれぞれに入れ方を案内しています（2026-10-23 確認）。README はほかに Cursor・Gemini CLI・GitHub Copilot などへの入れ方も載せていますが、当サイトが表示しているのは Claude Code と Codex の 2 つです。