テクニカルSEO

Core Web Vitals改善ガイド｜LCP・INP・CLSの最適化手法

Core Web Vitalsとは

Core Web Vitals（コアウェブバイタル）は、Googleが定めたウェブページのユーザー体験を測定する3つの主要指標です。2021年にランキング要因として導入され、2026年現在もSEOにおいて重要な評価軸の一つです。

Core Web Vitalsは、ウェブページの「表示速度」「操作への応答性」「視覚的な安定性」という3つの側面からユーザー体験を定量的に評価します。3指標全てで「良好」の基準を満たすことが、検索ランキングとユーザー満足度の両面で重要です。

3指標の概要

指標 測定対象 良好 改善が必要 不良
LCP 表示速度 2.5秒以下 2.5〜4.0秒 4.0秒超
INP 操作応答性 200ms以下 200〜500ms 500ms超
CLS 視覚的安定性 0.1以下 0.1〜0.25 0.25超

測定方法

Core Web Vitalsの測定には「フィールドデータ」と「ラボデータ」の2種類があります。

**フィールドデータ（実ユーザーデータ）**は、実際のユーザーのブラウザから収集されたデータです。Chrome User Experience Report（CrUX）に蓄積され、Googleのランキング評価に使われるのはこちらのデータです。

  • PageSpeed Insights: URLを入力するだけでフィールドデータとラボデータの両方を確認可能
  • Google Search Console: サイト全体のCore Web Vitalsの状態を一覧で確認可能
  • CrUXダッシュボード: Looker Studioで時系列の変化を視覚的に把握可能

**ラボデータ（合成データ）**は、制御された環境でのシミュレーション結果です。開発中の改善効果を検証するのに適しています。

  • Lighthouse: Chrome DevToolsに組み込まれた総合監査ツール
  • WebPageTest: 世界各地のサーバーからの詳細な測定が可能
  • Chrome DevTools Performance パネル: JavaScriptの実行状況を詳細に分析可能

LCP（Largest Contentful Paint）の最適化

LCPとは

LCP（Largest Contentful Paint）は、ビューポート内で最も大きなコンテンツ要素が表示されるまでの時間を測定する指標です。ユーザーが「ページが表示された」と感じるタイミングに近い指標であり、目標値は2.5秒以内です。

LCPの対象となる要素は、<img>要素、<video>のポスター画像、CSSのbackground-imageで読み込まれた画像、テキストブロック（<h1>、<p>など）です。

LCP改善テクニック

サーバーレスポンスの高速化

サーバーの応答時間（TTFB: Time to First Byte）はLCPに直接影響します。

  • CDNの導入: CloudflareやFastlyなどのCDNを使い、ユーザーに近いエッジサーバーからコンテンツを配信する。TTFBが数百ミリ秒改善するケースが多い
  • サーバーサイドのキャッシュ: データベースクエリ結果やレンダリング結果をキャッシュし、同一リクエストの処理時間を短縮する
  • HTTP/2またはHTTP/3の使用: 多重化やヘッダー圧縮により、リソースの転送を効率化する

画像の最適化

多くのページでLCP要素は画像です。画像の最適化はLCP改善の最重要施策と言えます。

  • 次世代フォーマットの使用: WebPやAVIF形式を使用すると、JPEGと比較して30〜50%のファイルサイズ削減が可能。<picture>要素でフォールバックも設定できる
<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="ヒーロー画像" width="1200" height="600">
</picture>
  • 適切なサイズの指定: 実際の表示サイズに合わせた画像を配信する。srcset属性でデバイスごとに最適な画像を提供する
  • preloadの活用: LCP要素となる画像は<link rel="preload">で優先的に読み込む
<link rel="preload" as="image" href="hero.webp" type="image/webp">
  • fetchpriorityの指定: LCP画像にはfetchpriority="high"を指定し、ブラウザに優先的な読み込みを指示する
<img src="hero.webp" alt="ヒーロー画像" fetchpriority="high" width="1200" height="600">

レンダリングブロックリソースの排除

CSSやJavaScriptがレンダリングをブロックすると、LCPが遅延します。

  • クリティカルCSSのインライン化: ファーストビューに必要なCSSをHTMLの<head>にインラインで記述し、残りは非同期で読み込む
  • JavaScriptの遅延読み込み: defer属性やasync属性を使ってJavaScriptの実行を遅延させる。ファーストビューに不要なスクリプトにはdeferを使う
  • フォントの最適化: font-display: swapを指定し、Webフォントの読み込み中にフォールバックフォントを表示する。また、<link rel="preload">でフォントを事前読み込みする

INP（Interaction to Next Paint）の最適化

INPとは

INP（Interaction to Next Paint）は、ユーザーの操作（クリック、タップ、キーボード入力）から、ブラウザが次のフレームを描画するまでの時間を測定する指標です。2024年3月にFID（First Input Delay）に代わって導入されました。

FIDが「最初の操作のみ」を測定していたのに対し、INPはページのライフサイクル全体を通じた全てのインタラクションを測定し、最も遅い値（外れ値を除く）を報告します。目標値は200ミリ秒以内です。

INPの3つのフェーズ

INPの応答時間は、以下の3つのフェーズの合計です。

  1. 入力遅延（Input Delay）: ユーザーが操作してから、イベントハンドラが実行開始するまでの時間。メインスレッドが他のタスクで忙しいと長くなる
  2. 処理時間（Processing Time）: イベントハンドラの実行にかかる時間。JavaScriptの処理量に依存する
  3. 描画遅延（Presentation Delay）: イベントハンドラ完了後、ブラウザが次のフレームを描画するまでの時間。DOMの変更量やスタイル再計算の複雑さに依存する

INP改善テクニック

長いタスクの分割

メインスレッドを50ミリ秒以上ブロックするタスクは「Long Task」と呼ばれ、INPの大敵です。

  • setTimeoutやrequestAnimationFrameでのタスク分割: 大きな処理を小さなチャンクに分割し、メインスレッドを定期的に開放する
  • scheduler.yield()の活用: 2026年現在、多くのブラウザで利用可能になったScheduler APIを使い、優先度の低いタスクを適切にスケジューリングする
  • Web Workerへのオフロード: DOM操作を伴わない重い計算処理は、Web Workerに移動してメインスレッドの負荷を減らす

サードパーティスクリプトの最適化

広告、アナリティクス、チャットウィジェットなどのサードパーティスクリプトは、INPを悪化させる主要因の一つです。

  • 不要なスクリプトの削除: 実際に使われていないスクリプトを特定し、削除する
  • 遅延読み込みの実施: ユーザーの操作に必要ないスクリプトは、ページのインタラクティブ化後に読み込む
  • Partytown等の活用: サードパーティスクリプトをWeb Workerで実行するライブラリを検討する

イベントハンドラの効率化

  • デバウンスとスロットリング: スクロールやリサイズなど、高頻度で発火するイベントの処理頻度を制限する
  • 仮想スクロールの導入: 大量のリストやテーブルを表示する場合、ビューポートに見える部分のみをレンダリングする
  • CSSアニメーションの活用: JavaScriptアニメーションをCSSアニメーションやCSS Transitionに置き換え、コンポジター・スレッドで処理する

CLS（Cumulative Layout Shift）の最適化

CLSとは

CLS（Cumulative Layout Shift）は、ページの読み込み中や操作中に発生する予期しないレイアウトのずれ（レイアウトシフト）を測定する指標です。目標値は0.1以下です。

レイアウトシフトが発生すると、ユーザーが読んでいたテキストが突然移動したり、クリックしようとしたボタンがずれたりして、誤操作やストレスの原因になります。

レイアウトシフトの主な原因と対策

画像・動画のサイズ未指定

最も一般的なCLSの原因は、画像や動画にwidth/height属性が指定されていないことです。

<!-- 悪い例: サイズ未指定 -->
<img src="photo.webp" alt="写真">

<!-- 良い例: サイズ指定あり -->
<img src="photo.webp" alt="写真" width="800" height="450">

CSSのaspect-ratioプロパティを使う方法もあります。

.responsive-image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

Webフォントによるレイアウトシフト

Webフォントの読み込みにより、テキストのサイズや行間が変わるとレイアウトシフトが発生します。

  • font-display: swapの指定: システムフォントを先に表示し、Webフォントの読み込み後に置き換える
  • フォントのpreload: 重要なフォントを<link rel="preload">で事前読み込みする
  • サイズ調整のCSS: size-adjustプロパティでフォールバックフォントのサイズをWebフォントに近づけ、置き換え時のシフトを最小化する
@font-face {
  font-family: 'CustomFont';
  src: url('custom-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 105%;
}

動的コンテンツの挿入

広告バナー、Cookie同意バナー、遅延読み込みコンテンツなどの動的挿入はレイアウトシフトを引き起こします。

  • 表示領域の事前確保: 広告やバナーの表示領域をCSSで事前に確保する（min-heightの指定）
  • ページ上部への動的挿入を避ける: コンテンツの上部に要素を挿入すると、下の全コンテンツがシフトする
  • content-visibilityプロパティの活用: ビューポート外のコンテンツのレンダリングを遅延させつつ、contain-intrinsic-sizeでサイズを事前に指定する
.lazy-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

アニメーションによるレイアウトシフト

top、left、width、heightなどのプロパティをアニメーションさせると、レイアウトの再計算が発生します。

  • transformプロパティを使う: translate、scale、rotateはレイアウトに影響せず、コンポジター・スレッドで処理されるため高速
  • will-changeの適切な使用: アニメーション対象の要素にwill-change: transformを指定し、ブラウザに最適化の準備をさせる

改善の優先順位と実践フロー

ステップ1：現状の測定

まずPageSpeed InsightsとGoogle Search Consoleで現状を把握します。フィールドデータが蓄積されていない場合は、ラボデータを参考にします。

ステップ2：問題の特定

Chrome DevToolsのPerformanceパネルで、具体的にどの要素・どの処理が問題を引き起こしているかを特定します。LighthouseのDiagnosticsセクションも具体的な改善提案を提示してくれます。

ステップ3：影響度の大きい施策から着手

一般的に、以下の順序で改善のインパクトが大きい傾向があります。

  1. LCP画像の最適化（preload + 次世代フォーマット + fetchpriority）
  2. レンダリングブロックリソースの排除（CSS/JSの遅延読み込み）
  3. 画像・動画のサイズ指定（CLS改善の即効策）
  4. サードパーティスクリプトの整理（INP改善の即効策）
  5. サーバーレスポンスの高速化（CDN導入）

ステップ4：継続的なモニタリング

改善は一度で終わりではありません。新機能追加やコンテンツ更新のたびに指標が悪化する可能性があります。

  • Google Search Consoleの定期確認（週1回程度）
  • CI/CDパイプラインにLighthouseチェックを組み込む
  • Real User Monitoring（RUM）でフィールドデータを継続収集する

Core Web Vitalsの改善は、SEOだけでなく、コンバージョン率やユーザー満足度の向上にも直結します。技術的な投資に見合うリターンが期待できる、優先度の高い施策です。