Performance optimization
Skill goonobu-dot/dev-skills-library/skills/performance-optimization
15 auto-selectable Claude Code skills distilling engineering best practices (Kent Beck, Fowler, Google SRE, OWASP, Anthropic, Netflix…), with a bilingual offline learning site. Make Claude Code write better code — and learn the practices yourself.
npx -y skills add goonobu-dot/dev-skills-library --skill performance-optimizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Measurement-first performance optimization: profile before changing, verify with numbers, Core Web Vitals targets and remediation steps. Use when the user reports slowness, asks to optimize or speed up code or pages, or says 遅い, パフォーマンス, 高速化, 重い. Never optimize without measuring first. Not for architecture-level scaling decisions (use scalability-design).
SKILL.md
6.4 KB, as published. Nobody here has run it
Performance Optimization
「推測で最適化しない」ことを鉄則とする。Donald Knuthの"premature optimization is the root of all evil"に基づき、計測→仮説→修正→再計測のループを必ず踏む。
鉄則（Iron Law）
計測せずに最適化コードを書いてはいけない。 「ここが遅そう」という直感は高確率で外れる。修正前後の数値がない「最適化しました」は報告として認めない。
適用手順
1. 何を測定するか明確にする
- パフォーマンス改善を依頼されたら、最初に「何を測定するか」を確定する：実行時間か、メモリ割り当てか、I/O待ちか、レンダリング時間か。
- 「遅い」という報告を受けたら、具体的な再現手順（どの操作が、どの条件で、どれくらい遅いか）を言語化してから着手する。
2. 修正前に現状を計測する
- プロファイラ・ベンチマーク・パフォーマンス計測ツールで現状の数値を取得する。コードを目で読んでボトルネックを決めつけない。
- サーバーサイド/バッチ処理：CPUプロファイラ、実行時間計測、DBクエリのEXPLAIN/実行計画を確認する。
- フロントエンド：Chrome DevTools Performanceパネル・Lighthouse・PageSpeed Insightsでフィールドデータとラボデータの両方を確認する。
- 計測結果から、実際のボトルネック箇所を1つ以上特定してから次に進む。特定できない場合は計測方法を見直す（推測で次のステップに進まない）。
3. Core Web Vitalsの目標値（フロントエンド）
- LCP（Largest Contentful Paint、最大コンテンツ描画）：2.5秒以内
- INP（Interaction to Next Paint、応答性）：200ミリ秒以内
- CLS（Cumulative Layout Shift、累積レイアウトシフト）：0.1以下
改善手順：
- LCPが悪い場合：最大コンテンツ要素（画像・見出し等）の読み込みを優先度高に設定し、レンダリングをブロックするリソース（同期JS/CSS）を減らす。
- INPが悪い場合：メインスレッドを長時間占有する処理を分割する（長いタスクの分割、重い同期処理の非同期化）。DOMの読み書きを分離し、強制リフロー（レイアウトスラッシング）を避ける。
- CLSが悪い場合：画像・広告枠にサイズ（width/height）を明示し、動的に挿入されるコンテンツが既存レイアウトを押し出さないようにする。
- DOMサイズを小さく保ち、画面外要素はCSS containment等で遅延レンダリングする。
4. ボトルネックにのみ手を入れる
- 計測で判明した箇所にのみ最適化を適用する。計測されていない箇所を「ついでに」最適化しない。
- 可読性を犠牲にする最適化（ループ展開、キャッシュの手動管理等）は、効果が数値で確認できた場合のみ適用する。効果が誤差程度なら元の可読なコードに戻す。
- アルゴリズム・データ構造の選択（O(n²)をO(n log n)にする等）を、細かいマイクロ最適化より優先して検討する。
5. 修正後に再計測して報告する
- 修正前と同じ条件・同じ計測方法で再計測する。
- Before/Afterの数値を並べて提示する（「速くなったはず」ではなく「◯msから◯msに改善」と報告する）。
- 改善が誤差範囲内だった場合は、その修正を採用するかどうかを可読性とのトレードオフで再検討する。
チェックリスト
- 何を測定するか（実行時間/メモリ/I/O/レンダリング）を明確にしてから着手した
- 修正前に実測でボトルネックを特定した（推測で決めていない）
- ボトルネック箇所にのみ手を入れた
- 可読性を落とす最適化は効果を数値で確認してから適用した
- 修正後に同条件で再計測し、Before/Afterを数値で報告した
- フロントエンドの場合、LCP/INP/CLSの目標値に対して現状を確認した
アンチパターン集
| アンチパターン | なぜ問題か | 代わりにすること |
|---|---|---|
| コードを読んで「ここが遅そう」と決めつけて修正する | 直感は実際のボトルネックと一致しないことが多い | プロファイラ・計測ツールで実測してから対象を決める |
| 計測せずに「最適化しました」と報告する | 効果があったか誰も検証できず、再発時に切り分けられない | Before/Afterの数値を必ず併記する |
| ボトルネックでない箇所まで「ついでに」最適化する | 可読性が落ちる割に効果がなく、変更差分も無駄に大きくなる | 計測で特定した箇所だけに絞る |
| マイクロ最適化（ループ展開等）から着手する | アルゴリズム自体が非効率だと焼け石に水 | まずアルゴリズム・データ構造・クエリ設計を見直す |
| 画像・フォントを無条件に同期読み込みのままにする | LCP/INPが悪化し、体感速度が落ちる | 遅延読み込み・優先度指定・サイズ事前指定を行う |
| 効果が誤差程度の最適化を可読性を犠牲にして残す | 将来のメンテナンスコストが増えるだけで実利がない | 効果が誤差なら可読なコードに戻す判断をする |
出典
- Donald Knuth, "premature optimization is the root of all evil" の原則（一般的引用）
- Shopify Engineering, "How to Fix Slow Code in Ruby" (https://shopify.engineering/how-fix-slow-code-ruby)
- web.dev, "The most effective ways to improve Core Web Vitals" (https://web.dev/articles/top-cwv)（Google公式、CC BY 4.0）
- 上記は要約・手順化したものであり、原文の丸写しはしていない。