パフォーマンス予算
web.dev の Performance budgets 101 と Use Lighthouse for performance budgets を 取得して読み、理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
性能に影響する指標に、上限を先に決めておくこと。
性能を測るとユーザー体験の目標が 測った後の話なら、こちらは測る前に線を引く話。
効くのは、上限があると判断の順序が変わるため。 「機能を足してから、遅くなったら直す」ではなく、 **「足すなら、どこを削るか」**が設計・技術選定・機能追加のたびに問われる。
3種類の指標
| 種類 | 例 | 向いている場面 |
|---|---|---|
| 量 | ページ全体の重さ、リクエスト数、画像・フォント・スクリプトの上限 | 開発の早い段階。まだ動くものがなくても決められる |
| 時点 | FCP(最初の内容が描かれる)、操作可能になるまでの時間 | 利用者の体感に近い |
| 規則 | Lighthouse や WebPageTest のスコア | 改善のヒントが同時に得られる |
量の指標には落とし穴がある。 リクエスト数も総量も同じ2つのページが、読み込み順序の違いで体感が変わる。 重要な資源が後から来ると、数字が同じでも遅く感じる。
だから量だけで運用しない。 時点の指標と組み合わせる。
最初の数字をどう決めるか
競合を測って、それより速い側に線を引くのが出発点。
出発点として挙げられている既定値。
操作可能になるまで 5秒未満
重要な経路の資源 170 KB 未満(圧縮・最小化した状態)
3G 相当の回線と、標準的な端末を前提にした数字。 モバイル回線が通信の半分以上を占める、という理由づけになっている。
ページの種類ごとに変える。
商品ページ モバイルで JavaScript 170 KB 未満
検索ページ デスクトップで画像 2 MB 未満
トップ 遅い 3G で5秒以内に読み込みと操作可能
ブログ Lighthouse の性能スコア 80 以上
この出典は Time to Interactive を使っている点で古い。 現在の Core Web Vitals は INP が FID を置き換えており、 ユーザー体験の目標の LCP / INP / CLS で線を引く方が現行に合う。 考え方(先に上限を決める・量と時点を組み合わせる)はそのまま使える。
ビルドに組み込む
予算は、破ったときに気づける場所に置かないと機能しない。
budget.json を用意して Lighthouse に渡す。
[
{
"path": "/*",
"timings": [
{ "metric": "interactive", "budget": 3000 }
],
"resourceSizes": [
{ "resourceType": "script", "budget": 125 },
{ "resourceType": "total", "budget": 300 }
],
"resourceCounts": [
{ "resourceType": "third-party", "budget": 10 }
]
}
]lighthouse https://example.com --budget-path=./budget.json単位は、timings がミリ秒、resourceSizes がキロバイト、resourceCounts が件数。
resourceType に指定できるのは
document / script / stylesheet / image / media / font / third-party / total。
third-party の件数に予算を置けるのが実務的。
自分たちのコードは測っていても、タグや計測スクリプトの数は誰も見ていないことが多い。
道具としては Lighthouse CI のほか、webpack の性能機能、bundlesize がある。
これは壊れてほしくないものは CI に入れるの 一例で、性能の回帰をテストと同じ扱いにするということ。
超えたときにやること
3つしかない。
既存の機能や資源を最適化する
既存の機能や資源を削る
新しい機能や資源を足さない
この3択しかないことが、予算の効き目そのもの。 「今回は特別に超える」を許すと、予算は数字が書かれた文書に戻る。
費用対効果の判断を、 性能について先に済ませておく仕組みだと考えるとよい。
出したあとも測り続ける
実利用者のデータで、性能の変化が事業の指標にどう出たかを追う。
ユーザー体験の目標のフィールドデータの側。 ラボの数字だけを守り続けても、実際の利用者の回線と端末では違う結果になる。