製品の役に立つパフォーマンス予算を決める

現在の流れを読み取る

パフォーマンス予算は見栄えのよい点数ではなく、特定の利用体験に対する境界です。比較的低性能なスマートフォンで説明ページを開く、業務一覧を絞り込む、相談を送信するなど、重要な作業と端末から始めます。上限を決める前に現状を測り、測定条件も記録します。

守りたい対象範囲

体験の指標と制御できる負荷を組み合わせます。表示、操作反応、レイアウト安定性が体験を表し、スクリプト、画像、フォントの転送量が理由を探る材料になります。web.devも予算を判断に使う制限として説明しています。ページや作業ごとに担当と超過時の対応を決め、数字だけで終わらせません。

一つの仕事をたどる

公開ページに比較機能を加える例では、同じ端末・回線条件で本番相当の変更前後を測ります。転送コードと主要説明の表示を確認し、判断に貢献しない遅延なら簡略化や必要時の読込を検討します。不可欠な機能なら悪化を隠さず、価値の低い別の負荷を減らせないか考えます。

例外も守る

キャッシュ済みPCと初回モバイルを比較せず、最良の一回を代表値にしません。実験室の測定と実利用者の観測は分けます。エラー、長文、翻訳用フォント、外部スクリプトも含めます。上限を守るために文字を読みにくくしたり、機能や難しいURLを測定から外したりしないでください。

予算を繰り返せる公開判断にする

トップだけでなく、役立つ中で最も重いページも含む代表URLを選びます。本番ビルド、端末、通信条件、キャッシュ状態、作業を基準結果と記録します。後の差が製品変更なのか測定環境変更なのかを分けてから、公開を判断します。

各上限に理由を付けます。初期スクリプト量は低速回線を、操作遅延は繰り返す絞り込みを守るかもしれません。超過時は影響する作業と負荷の内訳を調べます。大きなコード、画像、遅いフォント、データ取得には別の対策が必要です。総合点のために役立つ機能を外すと製品を悪くすることもあり、実際の結果と併せて判断します。

例外は明示します。専門ページの必要な図が重ければ、理由、実測影響、比較した手段、受け入れる人を残します。全URLの基準を緩めず、そのページだけに限定し、一時的な依存なら特に見直し時期を設けます。公開後は実利用の観測があれば実験と比べます。なければ「このURLをこの条件で確認した」という狭い範囲を伝えます。万能保証ではなくても、範囲の分かる証拠は有用です。

予算のレビュー表

決める前に

上限を超えると何の作業が遅くなるか。誰でも測定を再現できるか。例外を誰が承認し、いつ見直すか。代表URLと端末条件を持ち寄り、小さく繰り返せる確認をリリースに組み込みます。