Core Web Vitals とは何か：LCP・CLS・INPを整理する

定義と結論

Core Web Vitalsは、Webページの体感品質を「表示」「視覚的な安定」「操作への応答」の三つで捉える指標群です。 現在の中心指標はLCP、CLS、INPです。

判定は、実ユーザーのページ読み込みの75パーセンタイルで、モバイルとデスクトップを分けて見ることが推奨されています。平均値だけが速くても、遅い側の利用者が多ければ良好とは言えません。

なぜ必要なのか

「ページが遅い」という感想だけでは、サーバー、画像、JavaScript、レイアウトのどこを直すべきか決められません。三指標へ分けると、主内容が出ない、表示中に動く、押しても反応しないという異なる症状を測定できます。

ただし、Core Web VitalsはUXのすべてではありません。アクセシビリティ、内容の有用性、エラー率、タスク完了率、安全性は別に確認します。検索評価だけを目的に数字を操作するのではなく、利用者の困りごとと結び付けて改善します。

登場人物と測定対象

• 利用者: 端末、通信、地域、キャッシュ状態が異なる実際の訪問者
• 開発者: 原因を再現し、コードや配信を改善する
• デザイナー: 画像、フォント、後出しUI、操作フィードバックを設計する
• バックエンド／基盤担当: 応答時間、CDN、キャッシュを改善する
• 分析担当: 実ユーザーデータをページ種別や端末別に読む
• 計測ツール: Chrome UX Report、PageSpeed Insights、DevTools、Lighthouseなど

計測対象は「サイト全体の一つの点数」ではありません。ページ、閲覧環境、期間によって値が異なります。検索画面、記事、商品詳細のようにテンプレート単位で傾向を見ると対策しやすくなります。

フィールドデータとラボデータ

フィールドデータは実際の利用者から集めた値です。端末やネットワークのばらつきを含み、改善の最終判断に向きます。Chrome UX ReportやReal User Monitoringが代表例です。ただし、一定のアクセス量が必要で、反映には時間差があります。

ラボデータは制御した環境でその場で測る値です。LighthouseやDevToolsを使い、変更前後を再現しやすい利点があります。ただし一回の測定は全利用者を代表しません。

フィールドデータで問題を発見し、ラボデータとトレースで原因を絞り、再びフィールドデータで効果を確認するのが基本の流れです。

LCP：主な内容が見えるまで

LCPはLargest Contentful Paintの略で、ビューポート内に描画された最大の対象要素が表示されるまでの時間です。画像、<img>、動画のポスター画像、背景画像、テキストを含むブロックなどが候補になります。ページによって対象は変わるため、「常にヒーロー画像」とは限りません。

LCPの内訳

LCPは概念的に次の待ち時間へ分けて考えられます。

1. TTFB: HTMLの最初のバイトが届くまで
2. リソース読込開始までの遅延: ブラウザがLCP画像などを発見するまで
3. リソース読込時間: 対象を取得する時間
4. 描画遅延: 取得後、画面へ描画されるまで

サーバーが遅いならTTFB、画像がCSS内で遅く発見されるなら開始遅延、数MBの画像なら取得時間、重いJavaScriptやCSSが妨げるなら描画遅延が増えます。内訳を見ずに画像だけ圧縮しても改善しない場合があります。

LCP改善の例

• CDN、キャッシュ、サーバー処理を見直す
• LCP画像をHTMLから早く発見できるようにする
• 重要画像へ適切な優先度を与え、遅延読込にしない
• 表示サイズに合うWebP／AVIF等とレスポンシブ画像を使う
• 描画を妨げるCSS・JavaScriptを減らす

<img
  src="hero-1280.webp"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="受講生がWebアプリを制作している様子"
>

fetchpriority="high" は重要画像へ選択的に使います。すべてを高優先度にすると優先順位の意味が薄れます。

CLS：予期しないずれ

CLSはCumulative Layout Shiftの略で、利用者の入力によらず発生したレイアウトシフトを、影響範囲と移動距離から算出して累積します。単位は秒ではありません。

典型例は、画像サイズが未指定で、読み込み後に本文を押し下げるケースです。広告、同意バナー、Webフォント、遅れて届くコンテンツも原因になります。ボタンを押す直前に位置が変われば、誤操作にもつながります。

CLS改善の例

• 画像や動画へ width と height、または aspect-ratio を指定する
• 広告や埋め込みの領域を先に確保する
• 既存コンテンツの上へ要素を後挿入しない
• フォントのフォールバックとメトリクスを調整する
• アニメーションはレイアウトを変えるプロパティより transform を検討する

.video-frame {
  aspect-ratio: 16 / 9;
  width: 100%;
}

CLSを下げる基本は、後から現れる要素の場所を先に予約することです。

INP：操作への応答

INPはInteraction to Next Paintの略です。ページ滞在中のクリック、タップ、キーボード操作について、操作開始から次の描画までのレイテンシを観察し、ページ全体の応答性を代表する値を示します。単なるイベントハンドラーの実行時間ではありません。

一つの操作は、入力遅延、イベント処理時間、次の描画までの遅延に分けられます。メインスレッドが長い処理で埋まっていればイベント開始が遅れ、ハンドラーが重ければ処理が長引き、大きなDOM更新があれば描画も遅れます。

INP改善の例

• 長いJavaScriptタスクを小さく分け、メインスレッドへ制御を返す
• 操作に不要な同期処理を後へ回す
• DOMの読み書きを整理し、不要な再描画を減らす
• 大きなライブラリや不要なサードパーティスクリプトを減らす
• 直ちに押下状態やローディングを描画し、重い仕事を続ける
• 重い計算は必要に応じてWeb Workerを検討する

イベントへ setTimeout を足せば自動的に速くなるわけではありません。仕事量、分割位置、描画タイミングをトレースで確認します。

指標の比較と主要パターン

指標は独立しきっていません。大量のJavaScriptはLCPの描画を遅らせ、同時にINPも悪化させます。画像寸法の指定はCLSを改善し、描画計画も安定させます。

具体例：申込みページ

申込みページで、ファーストビューの写真が3MB、寸法未指定、日付選択ライブラリが初期バンドルへ入り、クリック時に全候補を同期計算するとします。

写真の取得でLCPが遅れ、読み込み後にフォームが下へ動いてCLSが増え、日付選択時の長い処理でINPが悪化します。対策は、写真の適切な形式・サイズ・優先度、寸法の予約、日付機能の遅延読込、計算の削減・分割です。一つの「高速化」施策ではなく、症状ごとに原因を切り分けます。

よくある誤解

「Lighthouseで100点なら全ユーザーが良好」

Lighthouseは特定条件のラボ測定です。実ユーザーの低性能端末や遅い回線は別に確認します。

「LCPはページ全体の読み込み完了時間」

主な表示要素の描画を測る指標で、全画像や全通信の完了とは異なります。

「CLSは動くものすべてを減点する」

利用者操作に応じた変化や、レイアウトをずらさないアニメーションが同じ扱いになるわけではありません。予期しないシフトを調べます。

「INPは最初のクリックだけ」

ページ滞在中の複数の操作を観察します。初期表示後も重い画面では悪化します。

「合格境界を少し下回れば終わり」

測定値には揺れがあり、機能追加や第三者スクリプトで悪化します。余裕を持つ予算と継続監視が必要です。

注意点とベストプラクティス

• URL単体と、類似ページをまとめたオリジンデータを区別する
• モバイルとデスクトップを分ける
• 一回の測定で結論を出さず、複数回・複数条件で比較する
• 改善前に対象要素と原因区間を特定する
• サードパーティタグも自分たちの性能予算に含める
• 画像の見た目や機能を壊して点数だけ上げない
• リリース前のラボ検査と、公開後のRUMを組み合わせる

デバッグと確認方法

1. PageSpeed Insightsでフィールドデータの有無と対象範囲を見る
2. Chrome DevToolsのPerformanceでページ読み込みや操作を記録する
3. LCP要素、Layout Shift、Interaction、Long Taskを特定する
4. Networkで画像、フォント、JSの開始時刻・容量・優先度を見る
5. Lighthouseを同条件で複数回実行し、変更前後を比較する
6. 実ユーザー計測ではページ種別、端末、地域などで分ける
7. 公開後、十分な期間を置いて75パーセンタイルを再確認する

Chrome拡張や開発環境の処理が測定へ混ざる場合があります。シークレットウィンドウや新しいプロファイル、CPU・ネットワーク制限を使い、条件を記録します。

まとめ

Core Web Vitalsは、LCPが主な表示、CLSが予期しないずれ、INPが操作への応答を測ります。 閾値は入口であり、目的は利用者の「見えない・ずれる・反応しない」を減らすことです。フィールドデータで課題を見つけ、ラボ計測で原因を切り分け、公開後の実測で改善を確認します。

参考資料

• web.dev: Web Vitals
• web.dev: Largest Contentful Paint
• web.dev: Cumulative Layout Shift
• web.dev: Interaction to Next Paint
• W3C: Layout Instability API

次に読む記事

• Lighthouse の読み方
• 画像最適化の基本
• パフォーマンス最適化
• バンドルとは何か

×

PR

×

PR