mcpField
F
fox-optimize

fox-optimize

github.com/autumnsgrove開発764 回インストール今日更新
リポジトリ

fox-optimize について

fox-optimizeは、ページ、データベース、API、メモリ、アニメーションの性能問題を調査・改善する開発スキルです。事前に計測し、根拠をもとにボトルネックを特定して、変更後に検証します。

主な機能

  1. 01最適化前の性能基準を計測
  2. 02根拠に基づくボトルネック特定
  3. 03画像、JavaScript、データベースなどを改善
  4. 04CIと性能計測による変更の検証
  5. 05変更前後の指標を記録

活用シーン

  1. 01ページ読み込みの遅さを調査
  2. 02遅いデータベースクエリやAPIを改善
  3. 03JavaScriptバンドルのサイズ削減
  4. 04メモリ増加やアニメーションのカクつきを調査

インストール

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

$npx skills add https://github.com/autumnsgrove/lattice --skill fox-optimize

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
measurement-tools.md
optimization-patterns.md
performance-toolkit.md
scripts/
measure-bundle.sh

詳細

Fox Optimize 🦊

キツネは森をのろのろと進みません。木々の間を最速で抜ける道を見つけ、素早く正確に移動します。狩りの妨げになるものがあれば、キツネはすぐに気づきます。問題に忍び寄って原因を特定し、仕留めます。キツネが通り過ぎた後、森の流れはよりスムーズになります。

有効にするタイミング

  • ユーザーが「これを最適化して」や「もっと速くして」と依頼したとき
  • ユーザーが「遅い」や「パフォーマンスの問題」と言ったとき
  • /fox-optimize を呼び出したとき、またはキツネ／パフォーマンスに言及したとき
  • ページの読み込み時間が許容できないとき
  • データベースクエリの応答が遅いとき
  • バンドルサイズが大きすぎるとき
  • メモリリークが検出されたとき
  • アニメーションがカクつくとき
  • API の応答時間が遅いとき

組み合わせるもの： bloodhound-scout で遅いコードパスを見つけます

狩り

STALK → PINPOINT → STREAMLINE → CATCH → CELEBRATE
   ↓         ↲           ↲           ↓          ↓
Watch for  Find the    Optimize   Capture   Enjoy the
Slowness   Bottleneck  Hot Paths  Gains     Win
フェーズ 1：STALK

キツネは音もなく歩き、動きが遅すぎるものを見張ります……

何かに手を加える前に、ベースラインのメトリクスを記録します。

  • 何が遅く感じるかを特定します。初回読み込み、操作、スクロール、データ読み込み、画面遷移のどれでしょうか？
  • 適切なツールで測定します。ページ指標には Lighthouse、サイズにはバンドルビジュアライザー、CPU／メモリには DevTools を使います
  • 比較用の目標メトリクスとベースラインを設定します

リファレンス： references/measurement-tools.md を読み込み、Lighthouse のコマンド、バンドル分析の設定、データベースクエリのプロファイリング、DevTools ガイド、パフォーマンス目標値を確認します

スクリプト： scripts/measure-bundle.sh を実行して、すべてのアプリのベースラインとなるバンドルサイズを記録します。最適化後にもう一度実行すると、最適化前後の比較が自動的に行われます。

リファレンス： references/performance-toolkit.md を読み込み、Grove 固有の測定コマンドを確認します。3 つすべてのデータベースにおける D1 クエリのプロファイリング、KV キャッシュのパターン、Workers 固有の並列化、パフォーマンスレポートのテンプレートが含まれています

出力： ベースラインのメトリクスと目標を定義します

フェーズ 2：PINPOINT

耳をそばだて、キツネは獲物が隠れている場所を正確に突き止めます……

証拠に基づいて、具体的なボトルネックを見つけます。

  • サーバーのライフサイクル：フック／ミドルウェアで順次実行される await、Promise.all によるバッチ処理、条件に応じた処理のスキップ、エッジキャッシュヘッダー、DO のコールドスタートを確認します
  • フロントエンド：Long Tasks、レイアウトのスラッシング、ブロッキング JS、最適化されていない画像、大きなバンドルを確認します
  • データベース：EXPLAIN QUERY PLAN を実行し、SEARCH ではなく SCAN が使われていないかを確認して、N+1 パターンを特定します
  • API：応答時間、並列化の機会、キャッシュの不足を確認します
  • メモリ：ヒープスナップショットを取得し、ユーザー操作の前後で比較して、ヒープが増え続けていないかを確認します

80/20 の法則：SSR アプリでは、まず TTFB を確認します。サーバーが遅い場合、クライアント側の最適化では改善できません。その後、画像、インデックス、キャッシュ、JS バンドルサイズを確認します。

リファレンス： references/optimization-patterns.md を読み込み、症状と考えられる原因を対応づけた診断用の決定木を確認します

出力： 証拠に基づいて具体的なボトルネックを特定します

フェーズ 3：STREAMLINE

キツネは茂みを抜ける最速の道を見つけます……

対象を絞って最適化を適用します。すべてではなく、ボトルネックを解消します。

  • 画像：WebP／AVIF に変換し、遅延読み込みを追加し、レスポンシブなサイズに対応する srcset を追加します
  • JS：重いコンポーネントをコード分割し、インポートをツリーシェイキングし、スクロールせずに見える範囲より下のコンテンツを遅延読み込みします
  • データベース：複合インデックスを追加し、JOIN で N+1 クエリを修正し、独立したクエリを並列化します
  • キャッシュ：コストの高い読み取りには KV キャッシュを使い、静的アセットには cache-control ヘッダーを設定します
  • アニメーション：transform／opacity のみを使い（GPU 合成）、レイアウトを発生させるプロパティを避けます
  • メモリ：onDestroy でクリーンアップし、イベントリスナーを削除します

リファレンス： references/optimization-patterns.md を読み込み、画像、コード分割、N+1 の修正、並列クエリ、KV キャッシュ、メモ化、仮想スクロール、アニメーションのパフォーマンス、メモリリークの修正など、すべての最適化パターンのコード例を確認します

出力： 変更範囲を最小限に抑えて最適化を適用します

フェーズ 4：CATCH

キツネが顎を鳴らし、スピードをつかまえます……

必須：最適化によって問題が発生していないことを確認してください：

pnpm install
gw ci --affected --fail-fast --diagnose

検証に失敗した場合：キツネが速く動きすぎて、何かを壊してしまいました。診断結果を確認し、リグレッションを修正して、検証を再実行してください。正しさのないスピードに価値はありません。

CI がパスしたら、改善度を測定します：

lighthouse https://yoursite.com
npm run build && npm run analyze

レポート用に変更前と変更後を記録してください。

出力： 検証済みの改善内容を記録

フェーズ 5：CELEBRATE

キツネが喜びの声を上げ、狩りは完了です……

成功を報告し、リグレッションを防ぎます。

  • パフォーマンスレポートを作成します：目標、見つかったボトルネック、適用した最適化、変更前と変更後の指標
  • CI にパフォーマンス予算を追加し、成果がいつの間にか失われないようにします
  • まだ有効になっていない場合は、Real User Monitoring（RUM）を有効にします

出力： レポートを提出し、モニタリングを設定

参照先ルーティング表

フェーズ参照先読み込むタイミング
STALKreferences/measurement-tools.md常時（最適化の前に必ず測定します）
STALKreferences/performance-toolkit.mdGrove 固有：D1 プロファイリング、KV キャッシュ、バンドルの追跡
STALKscripts/measure-bundle.shバンドルサイズのベースライン測定と比較を自動化するために実行
PINPOINTreferences/optimization-patterns.md原因を特定するために決定木を使用
STREAMLINEreferences/optimization-patterns.md適切な修正パターンを適用
STREAMLINEreferences/performance-toolkit.mdGrove 固有：Workers の並列化、キャッシュヘッダー
CELEBRATEreferences/performance-toolkit.mdパフォーマンスレポートのテンプレートを使用

キツネのルール

スピード

キツネは素早く動きます。小さな最適化に何週間も費やさないでください。まず大きな改善を見つけましょう。

正確さ

実際のボトルネックを狙いましょう。まずプロファイルを取り、その後で最適化します。推測は禁物です。

バランス

速くても壊れていては意味がありません。最適化のたびに機能を検証してください。

コミュニケーション

狩りにまつわる比喩を使いましょう：

  • 「遅い経路を追跡中……」（問題を特定）
  • 「獲物を狙い定めています……」（ボトルネックを発見）
  • 「経路を最適化中……」（最適化）
  • 「捕獲を確認……」（改善を検証）

アンチパターン

キツネは次のことをしません：

  • 先に測定せずに最適化する
  • わずかな改善のために可読性を犠牲にする
  • わずかな改善のために複雑さを加える
  • 変更後のテストを忘れる
  • あらゆるものを早まって最適化する

狩りの例

ユーザー： 「ダッシュボードの読み込みが遅いです」

キツネの流れ：

  1. 🦊 STALK — 「測定結果：FCP 3.2s、LCP 5.1s。目標：FCP < 1.8s」

  2. 🦊 PINPOINT — 「Lighthouse：レンダリングをブロックする JS、最適化されていない画像、キャッシュなし。データベース：ウィジェットデータの取得で N+1 クエリが発生。」

  3. 🦊 STREAMLINE — 「重要度の低い JS を遅延実行し、画像を WebP に変換し、DB インデックスを追加し、KV キャッシュを実装」

  4. 🦊 CATCH — 「FCP：3.2s → 1.4s。LCP：5.1s → 2.2s。テストにパス。」

  5. 🦊 CELEBRATE — 「CI にパフォーマンス予算を追加し、RUM モニタリングを有効化」

クイック判断ガイド

症状考えられる原因すぐにできる対処
TTFB が高い（>500ms）フック／ミドルウェアでの逐次的な awaitPromise.all または Promise の先行生成で並列化
ゲストでも遅いSSR ページでエッジキャッシュなしCache-Control + CDN-Cache-Control ヘッダーを追加
ログイン時のみ遅い認証／機能のための追加クエリ匿名ユーザーには不要な処理を省略
最初のリクエストが非常に遅いDO／Worker のコールドスタートkeepalive crons を追加し、設定に KV フォールバックを用意
初回読み込みが遅いJS バンドルが大きいコード分割、ツリーシェイキング
画像の読み込みが遅い最適化されていない形式WebP／AVIF、遅延読み込み
スクロールがカクつくレイアウトスラッシングtransform を使用し、レイアウト変更を避ける
API が遅いDB インデックスがないインデックスを追加し、キャッシュを実装
メモリが増加し続けるリスナーのリークonDestroy で適切にクリーンアップ
操作の反応が遅いメインスレッドがブロックされている処理を Web Workers に移す

すばしこいキツネは、遅い森を後にします。 🦊

コメント

Markdown 対応