Web パフォーマンス（Core Web Vitals）

なぜ速さが重要か

表示が遅いページは、見られる前に閉じられます。読み込みが数秒延びるだけで離脱率は跳ね上がり、ECサイトなら売上に直結します。速さは「快適さ」だけでなくビジネス指標です。

加えて、Google はページの体験を検索ランキングの要素に含めています。同等の内容なら、速く・安定して表示できるページが有利になります。そこで体感を共通のものさしで測るのが Core Web Vitals です。

• 主観の「なんとなく速い／遅い」を、誰が測っても同じ数値にする。
• 実際の利用者の計測（フィールドデータ）を重視する。

Core Web Vitals の三本柱

Core Web Vitals は、ユーザー体験を 3 つの側面から測ります。それぞれ「何の速さ／安定さ」を見ているかが異なります。

指標	何を測るか	良い目安
LCP（Largest Contentful Paint）	主要コンテンツが表示されるまでの読み込み速度	2.5 秒以下
CLS（Cumulative Layout Shift）	表示中に要素がずれるレイアウトの安定性	0.1 以下
INP（Interaction to Next Paint）	クリック等の操作に画面が反応する応答性	200 ミリ秒以下

ざっくり言うと、**LCP は「すぐ見えるか」、CLS は「ガタつかないか」、INP は「押したらすぐ反応するか」**です。3 つそろって初めて「速くて快適」と言えます。

なお INP は、かつての指標 FID（First Input Delay）に代わって体感応答性の主要指標になったものです。

LCP / CLS / INP の中身

それぞれ、悪化させる典型原因が違います。原因が違えば打ち手も変わります。

• LCP（表示速度）：多くの場合、画面で一番大きい要素（ヒーロー画像や見出し）の描画が遅い。重い画像、遅いサーバ応答、描画をブロックする CSS / JS が主因。
• CLS（安定性）：画像や広告にサイズ指定が無いと、後から読み込まれて他の要素を押しのける。Web フォントの遅延差し替えでもずれる。
• INP（応答性）：クリック後に重い JavaScript が走り、ブラウザが描画を返せない。メインスレッドを長時間占有する処理が主因。

改善の勘所

費用対効果の高い順に、定番の打ち手を挙げます。

• 画像の最適化：適切なサイズに縮小し、WebP / AVIF など効率的な形式を使う。srcset で端末に合う解像度を出し分ける。
• 遅延読み込み（lazy loading）：画面外の画像や iframe は loading="lazy" で後回しにし、初期表示を軽くする。
• サイズの事前確保：画像や広告枠に width / height（または aspect-ratio）を指定し、CLS を防ぐ。
• 不要な JavaScript を減らす：バンドルを分割し、使う分だけ読み込む。重い処理は分割して INP を改善する。
• 重要リソースの優先化：最初に必要な CSS / 画像を優先し、描画をブロックするものを後回しにする。

<!-- 画面外の画像は遅延読み込み + サイズ確保で CLS も防ぐ -->
<img src="hero.webp" width="1200" height="630" alt="製品の写真" loading="lazy" />

<!-- 解像度の出し分けで、端末に合った最小限の画像を配信 -->
<img
  src="photo-800.webp"
  srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800"
  height="600"
  alt="風景"
/>

計測と運用

一度直して終わりではなく、悪化を見張り続けることが大切です。

• ラボとフィールドの両輪：Lighthouse で原因を特定し、実利用者のデータで実態を確認する。
• 継続的に監視：機能追加でスクリプトが増えると簡単に悪化する。CI やモニタリングで指標を見張る。
• 配信の最適化：HTTP キャッシュ や CDN で配信を速くするのも、LCP 改善に効く。

表示の前提となる ブラウザのレンダリング や レスポンシブデザイン の理解があると、どこがボトルネックかを掴みやすくなります。