superior-performance

優れたパフォーマンス

見た目が高コストなだけのコードではなく、実際に制約となっているユーザー体験やシステムの成果を改善します。比較可能な根拠に基づいて最適化を行い、正確性、セキュリティ、アクセシビリティ、保守性を維持します。

パフォーマンスの目標を定義する

最適化に着手する前に、次の項目を明確にします。

• 影響を受けるユーザーの操作、処理、ワークロード、またはリソース。
• 指標と目標。関連する場合は、パーセンタイルや分布も含めます。
• 現在のベースライン、回帰を確認する期間、測定元。
• 環境、ハードウェア、ネットワーク、データの形状、同時実行数、キャッシュの状態。
• 変更の対価として損なってはならない正確性と品質の制約。
• 目標がレイテンシ、スループット、応答性、容量、効率、コストのいずれなのか。

「遅い」といった未検証の印象を、あらゆる状況に当てはまる目標に置き換えてはいけません。明示的な目標値がない場合は、プロダクトへの期待とリポジトリ内の根拠から暫定的な比較基準を導き、それが暫定値であることを明記します。

変更前に測定する

ベースラインの確立、プロファイリングツールの選定、ベンチマークの作成、代替案の比較を行う際は、references/measurement-profiling-and-benchmarks.md を参照してください。

• 実用上可能であれば、編集前に代表的なワークロードを再現します。
• ランタイムとキャッシュは意図的にウォームアップします。コールド時とウォーム時の両方が重要な場合は、それぞれの結果を報告します。
• 勘に頼るより、プロファイル、トレース、クエリプラン、フレームグラフ、アロケーションデータ、ブラウザーのタイムラインを優先します。
• 重要な変数を一度に一つだけ変更し、同じ設定で比較します。
• ばらつき、バックグラウンド処理、サンプリング、スロットリング、測定によるオーバーヘッドを考慮します。

一度だけ速い結果が出ても、改善の根拠にはなりません。合成ベンチマークが有用なのは、実際に再現できている挙動の範囲に限られます。

ボトルネックを担う箇所を最適化する

CPU、メモリ、アロケーション、I/O、並行処理、キュー、バッチ処理、キャッシュ、接続プール、サービス容量に関する作業では、references/runtime-capacity-and-caching.md を参照してください。

バンドル、ネットワークウォーターフォール、画像、フォント、ハイドレーション、レンダリング、入力への応答性、長時間タスク、レイアウト、クライアントメモリに関する作業では、references/client-delivery-and-rendering.md を参照してください。

• 必要な処理を速くする前に、不要な処理を取り除きます。
• 制約を担うレイヤーで作業量を減らし、別のサービス、クライアント、キュー、デプロイ段階へ気付かれないまま負荷を移さないようにします。
• 有界性とバックプレッシャーを維持します。不安定なキューを生み出すスループットの向上は、改善ではありません。
• キャッシュは無償で速度を得る手段ではなく、一貫性とライフサイクルを管理する仕組みとして扱います。
• 価値の低い構文上のマイクロ最適化より、アルゴリズム、クエリ、ペイロード、ラウンドトリップの改善を優先します。

ベンチマークを改善できるという理由だけで、並行処理、メモ化、遅延読み込み、先読み、圧縮、キャッシュを追加してはいけません。ワークロード、無効化、メモリ、レイテンシ、運用上のトレードオフを確認してください。

正確性と体験を守る

• 出力、順序、認可、エラー処理、キャンセル、冪等性が正しく維持されることを検証します。
• 遅いリクエストを落とす、エラーを隠す、結果の品質を下げる、扱いにくいデバイスやデータを除外するといった方法で平均値を改善してはいけません。
• クライアント側の最適化でも、アクセシビリティと動きを減らす設定への対応を維持します。
• 明示的な承認と安全対策がない限り、本番環境でのプロファイリング、負荷生成、キャッシュのフラッシュ、広範なテレメトリーの変更、リソース制限の変更は避けます。
• パブリックな挙動、一貫性、保持期間、コストを変えるパフォーマンス変更は、見えない実装の詳細ではなく、契約の変更として扱います。

改善を検証する

変更後にベースラインのプロトコルを繰り返し、次の内容を報告します。

• 変更前後の分布または代表的な測定値；
• ワークロード、環境、サンプル数または測定時間、キャッシュの状態；
• ボトルネックが移動または軽減したことを示すプロファイルの証拠；
• 実施した正確性と回帰のチェック；
• 新たに生じたリソースまたはコスト面のトレードオフ；
• ベンチマークの限界と、検証していない条件。

隣接するワークロードに回帰がないか確認します。最適化によって、あるパーセンタイル、ペイロード、ルート、またはデバイスが改善する一方で、別のものが悪化することがあります。結果が測定誤差の範囲内であれば、改善したとせず、結論が出ていないと報告します。

スキルは必要な範囲に絞って組み合わせる

• パフォーマンスの症状の原因がまだ不明で、因果関係の調査が主目的の場合は、superior-debugging を使用します。
• クエリプラン、インデックス、ロック、スキーマ、またはデータストアの容量がボトルネックの原因の場合は、superior-database を使用します。
• 目標、過負荷時の動作、グレースフルデグラデーション、または復旧が結果を左右する場合は、superior-reliability を使用します。
• パフォーマンスの証拠がリリースの判断基準となる場合、または最適化によってビルドやロールアウトの動作が変わる場合は、superior-delivery を使用します。
• ベンチマークの設計やパフォーマンス回帰の自動化に、専用のテスト判断が必要な場合は、superior-testing を使用します。
• 測定された改善を安全に実現するためにインターフェースの変更が必要な場合は、superior-ui、superior-responsive、または superior-accessibility を使用します。
• 最適化によってアプリケーションの動作、並行処理、状態、または外部呼び出しが変わる場合は、superior-logic を使用します。
• 重大なパフォーマンスの変化が検証された後、または測定方法や運用手順書を長期的に更新する場合は、superior-docs を使用します。

明示的に範囲へ含まれていない限り、対象を絞った最適化を、フレームワークの書き換え、インフラストラクチャの移行、またはオブザーバビリティプラットフォームの置き換えにまで広げないでください。