Web パフォーマンス

「サイトが遅い」と言われたら、いきなりコードを直さず、どこが・どれだけ遅いかを計測してから直します。思い込みで直すと、効かない作業に時間を使ったり、別のところを遅くしたりします。

報告するときは「LCP の p75 が 4.1 秒 → 2.3 秒（原因：トップの画像が 1.2MB で優先度が低かった）」のように、指標・前後の数字・原因をセットにします。性能のテストの進め方は QA の性能のテスト、サーバー側の深掘りは SRE のパフォーマンスチューニングも参考になります。

Core Web Vitals は、Google が決めたユーザー体験の指標です。検索順位の要素の1つにもなっています。操作への反応の指標は、2024年3月に FID から INP に置き換わりました。目安は、実ユーザーの 75 パーセンタイル（遅いほうから4分の1の人）で判定します。

• ラボ：Lighthouse や開発者ツールで、決まった端末・回線の条件で測る。毎回同じ条件なので、変更の前後の比較や原因の調査に向く。INP は操作がないと測れないので、代わりに TBT（メインスレッドが止まった時間）を見る。
• RUM（実ユーザー計測）：本番で実際のユーザーのブラウザから値を集める。web-vitals ライブラリで測って送る、または Chrome の実データ（CrUX、Search Console・PageSpeed Insights に出る）を見る。遅い端末や回線のユーザーも入るので、本当の体験が分かる。

ラボでは速いのに RUM では悪い、はよくあります。目標は RUM で決め、原因の調査はラボで行います。

RUM の値はページの種類・端末（スマホ／PC）・国で分けて見ます。全体の平均だと、遅いページが隠れます。

まず「どの指標が悪いか」で手段を選びます。

• 形式：写真は AVIF・WebP（JPEG より小さい）、図やアイコンは SVG。<picture> で対応形式を出し分けるか、画像 CDN に任せる。
• サイズ：表示する大きさに合わせる。srcset と sizes で画面に合った大きさを選ばせる。4000px の写真を 400px で表示しない。
• 遅延読み込み：画面の外の画像は loading="lazy"。ただし LCP になる最初の大きな画像には付けず、逆に fetchpriority="high" を付ける。
• width・height（または aspect-ratio）を書いて場所を先に取り、CLS を防ぐ。

<img src="hero-800.avif"
  srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1600.avif 1600w"
  sizes="(min-width: 768px) 50vw, 100vw"
  width="800" height="450" fetchpriority="high" alt="…">

• バンドルアナライザーで大きいものを探し、要らないライブラリを外す・軽いものに替える。
• ページ単位・重い部品単位でコード分割し、最初に要らないものは後から読む。
• Server Components や静的な HTML で済む所は JS を送らない。
• 長い処理は分割し、INP を悪くしない。

画像は同じ重さでも描画を止めませんが、JS は解析と実行でメインスレッドを使うので、同じバイト数なら JS のほうが体験への影響が大きくなります。

• Web フォントは使う太さと文字だけに絞り（日本語は特に大きい）、font-display: swap で読み込み中も文字を出す。自分のドメインから配信し、必要なら preload。
• 計測タグ・チャット・広告などのサードパーティは、性能を落とす大きな原因になる。本当に要るかを定期的に見直し、async／defer で読み、ユーザーの操作の後に遅らせて読むものも検討する。

あわせて、HTML や API の TTFB（CDN のキャッシュ・サーバーの処理）と、ハッシュ付きファイルの長期キャッシュも効きます。

TTFB（Time to First Byte）は、リクエストを送ってから最初の1バイトが届くまでの時間です。LCP の土台なので、ここが遅いとフロントで何をしても速くなりません。

TTFB の目安としては 0.8 秒以内が「良い」とされています。サーバーの処理時間は、Server-Timing ヘッダーで開発者ツールに出すと調べやすくなります。

TTFB や API の応答が遅いときは、サーバーの中で何に時間を使っているかを分けて見ます。たいていは「アプリの処理」より「待ち時間」（DB・外部 API・ロック・接続の空き待ち）が長いです。

平均は少数のとても遅いリクエストを隠すので、p95・p99で見ます。手元で試すときは、本番に近い件数のデータで計ります（件数が少ないと、インデックスがなくても速く見えます）。

速くしても、機能を足すうちに少しずつ遅くなります。パフォーマンスバジェット（守る上限）を決めて、超えたら気づける仕組みにします。

ラボの計測はばらつくので、1回の結果で落とさず、複数回の中央値や「一定以上悪くなったら」で判定します。サードパーティのスクリプト（広告・分析・チャット）は、入れる前に影響を測る決まりにしておくと、気づかないうちに重くなるのを防げます。