agentleFS
Sign inStart free
goonobu-dotgoonobu-dot/dev-skills-library/skills/performance-optimization/SKILL.md

performance-optimization

Skill0 starsChanged 4 months agoMITView on GitHub

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).

125 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use constraint-driven-development, git-workflow-and-versioning and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MrCipherSmithSkill

    constraint-driven-development

    Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

    Also in 15 projects that use this

  • LLl0k0laDSkill

    git-workflow-and-versioning

    Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.

    Also in 42 projects that use this

  • LLl0k0laDSkill

    using-agent-skills

    Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.

    Also in 33 projects that use this

  • HK-hubSkill

    deprecation-and-migration

    Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.

    Also in 39 projects that use this

  • ukanwatSkill

    input-systems

    Architect game input — action mapping (abstracting keys into named actions), rebinding with conflict detection and persistence, multi-device support (keyboard, gamepad, touch), analog deadzones, and feel features like input buffering and coyote time, plus accessibility. Engine-neutral. Use when the user mentions input mapping, rebind controls, gamepad support, deadzone, input buffering, coyote time, or accessible controls.

    Also in 4 projects that use this

  • HK-hubSkill

    observability-and-instrumentation

    Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

    Also in 31 projects that use this

  • +6 more from LLl0k0laD

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 110 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before/Afterの数値を並べて提示する（「速くなったはず」ではなく「◯msから◯msに改善」と報告する）。

    line 43

“Common” is measured: kept by at least 6 in 10 of the 110 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Performance Optimization

「推測で最適化しない」ことを鉄則とする。Donald Knuthの"premature optimization is the root of all evil"に基づき、計測→仮説→修正→再計測のループを必ず踏む。

鉄則（Iron Law）

計測せずに最適化コードを書いてはいけない。 「ここが遅そう」という直感は高確率で外れる。修正前後の数値がない「最適化しました」は報告として認めない。

適用手順

1. 何を測定するか明確にする

  1. パフォーマンス改善を依頼されたら、最初に「何を測定するか」を確定する：実行時間か、メモリ割り当てか、I/O待ちか、レンダリング時間か。
  2. 「遅い」という報告を受けたら、具体的な再現手順（どの操作が、どの条件で、どれくらい遅いか）を言語化してから着手する。

2. 修正前に現状を計測する

  1. プロファイラ・ベンチマーク・パフォーマンス計測ツールで現状の数値を取得する。コードを目で読んでボトルネックを決めつけない。
  2. サーバーサイド/バッチ処理：CPUプロファイラ、実行時間計測、DBクエリのEXPLAIN/実行計画を確認する。
  3. フロントエンド：Chrome DevTools Performanceパネル・Lighthouse・PageSpeed Insightsでフィールドデータとラボデータの両方を確認する。
  4. 計測結果から、実際のボトルネック箇所を1つ以上特定してから次に進む。特定できない場合は計測方法を見直す（推測で次のステップに進まない）。

3. Core Web Vitalsの目標値（フロントエンド）

  • LCP（Largest Contentful Paint、最大コンテンツ描画）：2.5秒以内
  • INP（Interaction to Next Paint、応答性）：200ミリ秒以内
  • CLS（Cumulative Layout Shift、累積レイアウトシフト）：0.1以下

改善手順：

  1. LCPが悪い場合：最大コンテンツ要素（画像・見出し等）の読み込みを優先度高に設定し、レンダリングをブロックするリソース（同期JS/CSS）を減らす。
  2. INPが悪い場合：メインスレッドを長時間占有する処理を分割する（長いタスクの分割、重い同期処理の非同期化）。DOMの読み書きを分離し、強制リフロー（レイアウトスラッシング）を避ける。
  3. CLSが悪い場合：画像・広告枠にサイズ（width/height）を明示し、動的に挿入されるコンテンツが既存レイアウトを押し出さないようにする。
  4. DOMサイズを小さく保ち、画面外要素はCSS containment等で遅延レンダリングする。

4. ボトルネックにのみ手を入れる

  1. 計測で判明した箇所にのみ最適化を適用する。計測されていない箇所を「ついでに」最適化しない。
  2. 可読性を犠牲にする最適化（ループ展開、キャッシュの手動管理等）は、効果が数値で確認できた場合のみ適用する。効果が誤差程度なら元の可読なコードに戻す。
  3. アルゴリズム・データ構造の選択（O(n²)をO(n log n)にする等）を、細かいマイクロ最適化より優先して検討する。

5. 修正後に再計測して報告する

  1. 修正前と同じ条件・同じ計測方法で再計測する。
  2. Before/Afterの数値を並べて提示する（「速くなったはず」ではなく「◯msから◯msに改善」と報告する）。
  3. 改善が誤差範囲内だった場合は、その修正を採用するかどうかを可読性とのトレードオフで再検討する。

チェックリスト

  • 何を測定するか（実行時間/メモリ/I/O/レンダリング）を明確にしてから着手した
  • 修正前に実測でボトルネックを特定した（推測で決めていない）
  • ボトルネック箇所にのみ手を入れた
  • 可読性を落とす最適化は効果を数値で確認してから適用した
  • 修正後に同条件で再計測し、Before/Afterを数値で報告した
  • フロントエンドの場合、LCP/INP/CLSの目標値に対して現状を確認した

アンチパターン集

アンチパターンなぜ問題か代わりにすること
コードを読んで「ここが遅そう」と決めつけて修正する直感は実際のボトルネックと一致しないことが多いプロファイラ・計測ツールで実測してから対象を決める
計測せずに「最適化しました」と報告する効果があったか誰も検証できず、再発時に切り分けられないBefore/Afterの数値を必ず併記する
ボトルネックでない箇所まで「ついでに」最適化する可読性が落ちる割に効果がなく、変更差分も無駄に大きくなる計測で特定した箇所だけに絞る
マイクロ最適化（ループ展開等）から着手するアルゴリズム自体が非効率だと焼け石に水まずアルゴリズム・データ構造・クエリ設計を見直す
画像・フォントを無条件に同期読み込みのままにするLCP/INPが悪化し、体感速度が落ちる遅延読み込み・優先度指定・サイズ事前指定を行う
効果が誤差程度の最適化を可読性を犠牲にして残す将来のメンテナンスコストが増えるだけで実利がない効果が誤差なら可読なコードに戻す判断をする

出典

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free