パフォーマンス予算は、苦情が来る前ではなく設計の前に決める
パフォーマンスを最適化フェーズとして扱うと、常に機能に負けます。設計が始まる前に合意された制約として扱うと、静かに、無料で、よりよい判断を生みます。
ほとんどのチームがパフォーマンスは重要だと言います。そしてほとんどのチームが、それを終盤のフェーズに置きます。そこでは出荷することと競合し、負けます。
結果的に速いプロダクトを持つチームは違うことをしています。それは英雄的な最適化ではありません。誰かがデザインツールを開く前に「十分に速い」の意味を決め、その数字をブラウザ対応表と同じように扱うのです。目標ではなく制約として。
「あとで最適化する」が失敗する理由
理由は三つあり、あなたを倒すのは三つ目です。
- トレードオフを強制するものがない。 個々の機能は、単独で見ればコストに見合っています。予算がなければ「ノー」と言うものが存在せず、合計すると遅くなります。
- 安い対策は尽きる。 圧縮、キャッシュ、画像形式が買えるのは決まった、そこそこの量だけです。その先はアーキテクチャの領域です。
- 高くつく原因はアーキテクチャにある。 過剰に取得するデータ層、ネットワークで止まるレンダリング経路、クリティカルパス上のサードパーティスクリプト。これらは早期に決まり、あとで剥がすのに莫大な費用がかかります。
測れるようになったころには、結果を決めた判断はもう数か月前のものです。
予算とはどんなものか
予算とは、ビルドが通るか落ちるかを判定できる、少数の具体的な上限です。KoiSpeak の検索に対する例：
| 指標 | 予算 | 理由 |
|---|---|---|
| 最初の結果が出るまで | 150 ms 未満 | 人は話の途中で辞書を開く。これを超えると待たされた感覚になる。 |
| Largest Contentful Paint | 中位機で 2.5 秒未満 | 「良好」とされる一般的な閾値。 |
| Interaction to Next Paint | 200 ms 未満 | 入力が引っかかってはいけない。 |
| 送信する JavaScript 量 | ルートごとの上限 | ほかのすべてを予測できる唯一の数字。 |
予算を飾りではなく本物にする性質が二つあります。
- 形容詞ではなく数字であること。 「速い」ではビルドを落とせません。150 ms なら落とせます。
- ユーザーが実際に持つ端末で測ること。 開発者のノート PC でオフィス Wi-Fi 越しに測った予算は、何も測っていません。
実在するハードウェアでテストする
ここが、多くのパフォーマンス作業が始まる前から狂う場所です。
開発は速いマシンと速い回線で行われます。ユーザーは数年前の中位 Android 機で、モバイル回線で、バックグラウンドに十数個のアプリを抱えています。この二つの体験の差は 20% ではありません。CPU 律速の処理では、日常的に 5 倍から 10 倍です。
実務上の最低限：
- 本物の中位機を 1 台机に置き、毎週使う。
- 開発者ツールの CPU スロットリングを、特別な演習ではなく既定で有効にする。
- 実セッションのフィールドデータを集める。ラボは何が変わったかを、フィールドはユーザーが実際に何を受け取ったかを教えます。
予算が判断をどう変えるか
価値は測定にではなく、何かがつくられる前に、早く安く決着する議論のほうにあります。
- 書体がコストになる。 2 書体 4 ウェイトはモバイル予算の実質的な一部です。設計段階で 2 ウェイトに絞る判断が、揉めずに下せます。
- アニメーションライブラリが自己正当化を迫られる。 自分で書く CSS と比べて。
- 解析やチャットのウィジェットが計上される。 サードパーティスクリプトはしばしば最大の項目で、チームの誰も書いていないので誰も気づきません。
- データの形が予算に従う。 最初の結果が 150 ms 以内に届くべきなら、大きな塊を取ってクライアントで絞ることはできません。それは接頭辞索引へ押しやります。そしてそれが元々正解です。
最後の項目こそがパターンです。予算はあなたを遅くしません。正しいアーキテクチャを早く明らかにします。
ローンチ後にやるパフォーマンス作業は救出作戦です。最初から制約として扱われたパフォーマンスは、ただの設計です。
儀式なしで守らせる
誰も確認しない予算は願望です。守らせる仕組みは安く保ちましょう。
- バンドルサイズ超過でビルドを落とす。 CI 設定 1 行で、退行の大半を捕まえ、維持費はゼロ。
- プルリクごとに合成計測を走らせる。 最重要の 2、3 ルートだけで十分です。
- フィールド指標は週次でアラート。 コミットごとではなく。実ユーザーのデータはノイズが多いので、傾向を見ます。
- プロダクトが変わったら予算を見直す。 予算は神聖ではありません。理由をもって意識的に上げるのは構いません。黙って超え続けるのは駄目です。
予算をどこに使うか
予算は最小化ではなく配分の話です。重さに見合うものもあります。
- クリティカルパス。 ユーザーが来た目的のものが最初で、残りは待てます。辞書なら検索窓と結果。店なら商品画像と価格。
- 測定速度より体感速度。 結果のスケルトンを即座に出すほうが、応答を 40 ms 速くするより効くことが多い。
- 入力への即時フィードバック。 キー入力への反応が約 100 ms 以内なら即座に感じられます。おおよそ 300 ms を超えると気づかれます。
居心地の悪い部分
本物の予算は、単独では良いものにノーと言うことを意味します。それこそが機能する理由であり、チームが静かに予算を捨てる理由でもあります。誰かが欲しい機能を初めて予算が止めたとき、いちばん楽な手は予算を上げることだからです。
規律は数字を決める場面にはありません。その数字を守り抜く会議のほうにあります。