「サイトが遅い気がする」という曖昧な相談を、具体的な改善タスクに落とすための共通言語がCore Web Vitalsです。Googleが定義するユーザー体験の指標で、検索順位への影響もあるため、フロントエンドの運用では避けて通れません。
本記事では、LCP・CLS・INPの3指標について、それぞれの意味と計測方法、現場でよく効く改善手段を整理します。「どの指標が悪いのか」を特定してから手を打つ、という順序が何より重要です。
3つの指標が示すもの
Core Web Vitalsは現在、次の3指標で構成されています。それぞれ「良好」とされる目安の閾値があります。
- LCP（Largest Contentful Paint）: 最大の要素が表示されるまでの時間。2.5秒以内が良好。体感的な「表示の速さ」に相当します
- CLS（Cumulative Layout Shift）: 表示中のレイアウトのずれの累積量。0.1以下が良好。「押そうとしたボタンがずれた」という体験の指標です
- INP（Interaction to Next Paint）: 操作してから画面が反応するまでの時間。200ミリ秒以内が良好。旧FIDの後継指標です
ユーザーからのクレームは「遅い」の一言でも、実際にはこの3つのどれが悪いかで打ち手がまったく変わります。まず切り分けることが最初の仕事です。
計測方法｜LighthouseとCrUXの使い分け
計測には大きく2種類あります。ラボデータ（合成環境での計測）とフィールドデータ（実ユーザーの計測値）です。
- Lighthouse: Chrome DevToolsから実行できるラボ計測。再現性が高く、改善前後の比較や原因調査に向きます。ただしINPは操作が必要なためラボでは直接計測できません
- CrUX（Chrome UX Report）: 実際のChromeユーザーから収集されたフィールドデータ。PageSpeed InsightsやSearch Consoleで確認でき、検索評価に使われるのはこちらです
現場でありがちなのが「Lighthouseのスコアは良いのにCrUXが悪い」というケースです。開発機の高速な環境と、実ユーザーの低速回線・低スペック端末の差が原因であることが多く、最終的な判断は必ずフィールドデータで行います。
LCPの改善｜読み込みの最短経路を作る
LCPの対象は多くの場合、ファーストビューのメイン画像かヒーローテキストです。改善の基本は「LCP要素をブラウザにいかに早く発見・取得させるか」です。
- LCP画像には
loading="lazy"を付けない（遅延させるとその分LCPが悪化します） fetchpriority="high"や<link rel="preload">で優先読み込みを指示する- 画像はWebP/AVIFで軽量化し、CDNから配信する
- サーバー応答（TTFB）が遅い場合はキャッシュ戦略から見直す
<!-- ヒーロー画像を優先的に取得させる -->
<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">CLSとINPの改善
CLS: 領域を先に確保する
CLSの原因の大半は「後から読み込まれるものが場所を押し広げる」ことです。画像には width/height 属性を必ず指定し、広告や埋め込みには min-height で枠を確保します。Webフォントによる文字のずれは font-display: swap と代替フォントのメトリクス調整で緩和できます。
INP: メインスレッドを塞がない
INPの悪化は、クリック時に走る重いJavaScript処理が原因です。長いタスクを分割する、状態更新を必要最小限にする、サードパーティスクリプトの読み込みを遅延させる、といった対策が基本です。Chrome DevToolsのPerformanceパネルで「Long Task」を特定するところから始めます。
まとめ
Core Web Vitals改善は「計測して悪い指標を特定する→指標ごとの定石を打つ→フィールドデータで効果を確認する」というサイクルの繰り返しです。LCPは読み込みの優先度、CLSは領域の事前確保、INPはメインスレッドの負荷、とそれぞれ見る場所が異なります。闇雲な最適化ではなく、まずPageSpeed InsightsでCrUXデータを確認するところから始めてみてください。
