性能
遅いという主観を、測れるものに変えるための場所。
出典はいずれも無料で公開されている。本文は引用せず、読んで理解した内容を自分の言葉で書いている。
このディレクトリ
- 性能を測る — USE メソッド。資源の側から見る
- ユーザー体験の目標 — Core Web Vitals。利用者の側から見る
- パフォーマンス予算 — 測る前に上限を決める。CI で守る
- プロファイリング — フレームグラフ、off-CPU 分析。どのコード経路が時間を使っているか
- 負荷試験 — どこで壊れるかを探す。結果はキャパシティ計画へ渡す
三方向から見る
同じ遅さを、違う入口から見ている。
資源側(USE) どの資源が詰まっているか
CPU、メモリ、ディスク、スレッドプール、ファイルディスクリプタ
Utilization / Saturation / Errors
利用者側(Vitals) 利用者が何を待たされているか
LCP 2.5秒 / INP 200ms / CLS 0.1
75パーセンタイルで、モバイルとデスクトップを分けて
コード側(プロファイル) どの経路がその時間を使っているか
on-CPU(計算している)と off-CPU(待っている)の両方
フレームグラフで1枚にする
3つとも要る。 資源が余っていても利用者は待たされうるし、 利用者が満足していても資源が限界に近ければ次のピークで落ちる。 そして資源が詰まっていると分かっても、どのコードがそうしているかは別に調べないと分からない。
順序としては、資源側で当たりをつけ、コード側で原因を特定し、 利用者側で効果を確かめるのが素直。
上限を先に決める
パフォーマンス予算だけは、この3つと役割が違う。 測った後ではなく、測る前に線を引く。 予算があると「遅くなったら直す」ではなく「足すなら、どこを削るか」が毎回問われる。
共通する原則
このリポジトリの他の場所と、同じことを言っている。
| ここでの言い方 | 同じことを言っている場所 |
|---|---|
| ツールからではなく資源から始める | 原則 — 推測ではなく実際にどうなるか |
| 平均を使わず分布で見る | 可観測性 |
| 利用率100%まで安全ということはない | 可観測性 — サチュレーション |
| レイテンシを第一級のゴールにする | スケールするリーダー |
この階層は一巡した
ROADMAP に挙げた項目はすべて書いた。
手順そのものは他の階層にあるものが多いので、重複させずに委譲している。