performance-optimization

パフォーマンス最適化

インターフェースを即座に反応するように感じさせ、正確に測定します。ユーザーが待つ箇所を見つけ、待ち時間ごとにそれをなくす（楽観的 UI、先読み、バッチ処理）か、目立たなくする（スケルトン、段階的な読み込み）かを判断し、改善を実装します。最優先の原則：実際の遅延より、体感の遅延を重視します。クリックに即座に反応する 3 秒の操作は、画面が固まる 1 秒の操作より優れています。ただし、実現できないことを偽ってはいけません（架空の進捗数値を表示しないこと、ロールバックでユーザーに不利益が生じる場面では楽観的 UI を使わないこと）。 ユーザーへの影響が大きい順に監査結果を提示し、動作するコードも提供します。

使用する場合／使用しない場合

以下の場合に使用します：動作が遅く感じられるインタラクション、楽観的 UI、Core Web Vitals の改善、先読み／先行読み込み、リクエストのバッチ処理／重複排除、レイアウトシフトの修正、体感パフォーマンスの戦略。

実際に必要なことが以下の場合は、代わりに引き継ぎます：

• ローディングインジケーター自体の選定／設計 → skills/frontend-design/loading-states
• コンポジター以外のプロパティによるアニメーションのジャンク → skills/frontend-design/interaction-physics（モーション仕様）または skills/frontend-design/design-engineer-mindset（レンダリングパイプライン、レイアウトスラッシング）
• 楽観的 UI に必要な失敗／ロールバック時のメッセージ → skills/frontend-design/error-handling-recovery
• バックエンド／クエリ自体の遅延 — 指摘はしますが、このスキルのフロントエンドの対象外です

ステップ 0 — コードベースを調査し、残った点だけを尋ねる

1. データレイヤーを確認します。生の fetch／axios か、データライブラリ（TanStack Query、SWR、Apollo、RTK Query）かを調べます。これによって実装戦略が決まります。ライブラリでは API を通じて楽観的更新や重複排除を実装できますが、独自実装のデータ取得では、こうした基本機能の追加が必要な場合があります。
2. 待機パターンを確認します。サーバーの応答まで UI を無効にするミューテーション、並列化できる逐次的な await の連鎖、同じリソースを重複して取得する処理、レンダリングのたびに再取得するエフェクトを探します。
3. レイアウトシフトの原因を探します。寸法／aspect-ratio が指定されていない画像、既存コンテンツの上に挿入されるコンテンツ、フォールバックのメトリクスなしで切り替わるフォント、予約領域のない広告／埋め込みコンテンツの枠などです。
4. 既存の測定手段を確認します。web-vitals パッケージ、Lighthouse CI、RUM／アナリティクスを調べます。この環境でプロジェクトを実行できる場合は、改善前後の実測値を取得します（Lighthouse またはプロファイル）。測定していないスコアを決して引用してはいけません。
5. 読み込み速度が問題の場合は、バンドルに関する兆候を確認します。ビルド出力のサイズ、ルート単位のコード分割がないこと、グローバルにインポートされている重量級の依存関係などを調べます。

調査で判明しなかった点だけをまとめて、一度にユーザーに尋ねます。どの操作フローが遅く感じられるか（または Lighthouse／CWV のスコアの問題か）、そして利用可能なフィールドデータがあるか（CrUX、アナリティクス）を確認します。問題がすでに具体的な場合（「タスクの保存がもたつく」など）は質問せず、そのフローをプロファイリングして進めます。

ワークフロー

1. あらゆる待ち時間を遅延の範囲に分類する

体感の待ち時間	対応
< 100ms	対応不要 — 即座に感じられます
100ms – 1s	即座にローカルのフィードバックを返す（ボタンの状態を変更）— スピナーは不要です
1s – 10s	可能なら待ち時間をなくし、それが難しければスケルトン／スピナーで目立たなくします（skills/frontend-design/loading-states に従う）
> 10s	実際の数値で進捗を示し、スタックが対応していれば処理をバックグラウンドで実行します

2. ミューテーションごとに楽観的か悲観的かを判断する — 失敗時のコストに基づいて

• 楽観的（UIをすぐに更新し、バックグラウンドで同期し、失敗時にロールバックする）：失敗時のコストが低く、成功の可能性が高く、簡単に元に戻せる場合です。いいね、切り替え、並べ替え、個人用リストへのアイテムの追加、名前の変更などが該当します。
• 悲観的（サーバーの確認を待ち、インラインで保留状態を表示する）：元に戻せない、または重大な結果を伴う場合です。支払い、送信（実際に送信されるメールやメッセージ）、取り消し手段のない削除、サーバー側の検証で拒否される可能性が高いものなどが該当します。
• 中間の方法：悲観的に確定しつつ取り消しを用意します（すぐに削除し、サーバーへの呼び出しの前に5～10秒間「取り消す」を表示する）。これにより、安全性を保ちながら即時に感じられます。
• 楽観的な更新にはすべて、変更前の状態のスナップショット、失敗時の正確なロールバック、ユーザーに表示される失敗通知が必要です（skills/frontend-design/error-handling-recovery を使って組み込んでください）。ロールバックのない楽観的 UI は、パフォーマンス向上ではなくデータ整合性のバグです。

3. 待ち時間を隠す前に取り除く

優先順位順：

1. リクエストを並列化／バッチ化する — 直列の await チェーンを Promise.all またはバッチエンドポイントに置き換えます。実行中のリクエストを重複排除します（データライブラリでは標準で対応しています）。
2. 先読みする — ホバー時またはビューポートの近くに来たときに、ルート／データをプリフェッチします（フレームワークに組み込みのプリフェッチ機能があれば、それを使用します）。
3. キャッシュして再利用する — ナビゲーション時に変更されていないデータを再取得しないようにします。
4. その後、残った待ち時間を隠します。既知のレイアウトにはスケルトン、画像にはぼかしからの表示、二次コンテンツにはプログレッシブエンハンスメント、リストには段階的な表示を使います（全体の段階表示は約300～400ms以内に抑えます）。実装例：references/patterns.md。

4. 実測したバイタルを実際のしきい値に照らして改善する

Core Web Vitals の「良好」なしきい値（フィールドデータの75パーセンタイル）：

• LCP ≤ 2.5s — 最大コンテンツの描画です。改善策：LCP 画像を優先／プリロードする、重要なコンテンツをサーバー側でレンダリングする、レンダリングをブロックするリソースを削減する、コード分割する。
• INP ≤ 200ms — 操作への応答性です（2024年3月に FID に代わりました）。改善策：メインスレッドの長時間タスクを分割する、緊急でない処理を遅延する、ハンドラー内で同期的にレイアウトを読み取らない。
• CLS ≤ 0.1 — レイアウトの安定性です。改善策：すべてのメディアに寸法を指定する、非同期コンテンツ用のスペースを確保する（スケルトンはこの点でも役立ちます）、代替フォントのメトリクスを考慮した font-display 戦略を使う。

数値を作り上げないでください。報告するのは実測値だけとし、ラボデータかフィールドデータかを明記してください。この環境で測定できない場合は、改善策とユーザーが検証するための手順を提示してください。

5. 検証する

測定前と同じ方法で再測定します（同じツール、同じページ、スロットリングの有無を記録）。楽観的なフローでは、失敗を強制し、正確にロールバックされて通知が表示されることを確認します。CLS の改善では、ネットワークをスロットリングした状態で再読み込みし、レイアウトシフトを確認します。

必須の出力形式

次の2つを納品してください。

1. コード — 実装済みの楽観的ミューテーション（プロジェクトにデータライブラリがある場合はそれを使用）、並列化／バッチ化／重複排除されたリクエスト、待ち時間を隠す処理、バイタルの改善。

2. パフォーマンス監査（Markdown）：

## Summary
One paragraph: what felt/measured slow, root causes, what changed.

## Measurements
| Metric | Before | After | Threshold | Source (lab/field, tool) |
| LCP | 4.1s | 2.2s | ≤2.5s | Lighthouse, throttled |
| INP | — | — | ≤200ms | not measurable here — verify via [tool] |
| CLS | 0.34 | 0.05 | ≤0.1 | Lighthouse |
(only rows you actually measured; never invented)

## Findings & fixes (ranked by user impact)
| # | Finding | Evidence | Fix | Status |
| 1 | Task save blocks UI ~800ms | network tab | optimistic update + rollback | implemented |
| 2 | 4 serial awaits on dashboard load | code | Promise.all | implemented |
| 3 | Hero image no dimensions → CLS | measured 0.34 | aspect-ratio + preload | implemented |

## Mutation strategy table
| Mutation | Strategy | Why | Rollback/undo |
| Like toggle | optimistic | trivial reversal | snapshot restore |
| Checkout | pessimistic | irreversible charge | n/a — inline pending |

## Not done / recommended next
[Backend latency, infra, CDN items outside frontend scope]

品質基準（納品前に確認）

• 記載した数値はすべて実測済みで、ラボデータかフィールドデータかを明記している。測定できない指標はその旨を示している
• すべての楽観的更新にスナップショット、正確なロールバック、ユーザーに表示される失敗通知がある
• 支払い、送信済みのメッセージ、取り消し手段のない破壊的操作に楽観的な処理を使っていない
• 独立したリクエストを直列に並べた await チェーンが残っていない
• 変更したコード内のすべての画像／埋め込み要素に、あらかじめ寸法が指定されている
• ユーザーに架空の進捗率や所要時間の見積もりを表示していない
• 待ち時間を隠す処理が prefers-reduced-motion を尊重し、段階表示を上限内に抑えている
• 改善策を実装の容易さではなく、ユーザーへの影響度に基づいて順位付けしている

厳守事項：1つの最適化だけを目的にデータ取得ライブラリを追加する場合、そのトレードオフを明示してください。実際の UX を損なう小細工で Lighthouse のスコアを追い求めないでください（LCP 画像の遅延読み込み、すぐに表示できるコンテンツをスケルトンでちらつかせるなど）。「より速く感じさせる」ためだけに、既存の読み込みフィードバックを削除しないでください。

統合

• skills/frontend-design/loading-states → このスキルで解消できない待ち時間にどのインジケーターを表示するかを担います。併用してください。スペースの確保はCLSを抑える共通の取り組みです。
• skills/frontend-design/error-handling-recovery → 楽観的な変更すべてに必要なロールバック失敗時のメッセージを提供します。
• skills/frontend-design/design-engineer-mindset → INPやカクつきの修正でメインスレッドの作業が必要な場合に、レンダリングパイプラインの詳細（レイアウトスラッシング、フレーム予算）を担います。
• skills/frontend-design/interaction-physics → コンポジターのみを使うアニメーションのルールにより、このスキルで対処することになるカクつきを防ぎます。

参考資料

• references/patterns.md — 楽観的な作成／削除／切り替えとロールバック、データライブラリに関する補足、スケルトン／ぼかしからの表示／段階的表示／段階的なマスキング、先読み、リクエストのバッチ処理と重複排除のコード、CWVの測定ガイダンスを掲載しています。修正を実装する際に参照してください。