コアウェブバイタルとは？LCP・INP・CLSの基準と改善方法

この記事の要点：

• コアウェブバイタルは、読み込み（LCP）、操作への反応（INP）、表示の安定性（CLS）の 3 つで、実際の利用者の体験を測る Google の指標です。
• 「良好」の基準は LCP 2.5 秒以内、INP 200 ミリ秒以下、CLS 0.1 以下で、実際の訪問の 75 パーセンタイルで判定します。
• 合否の判断は実際の利用者のデータ（フィールドデータ）で行い、原因の調査に PageSpeed Insights などのラボデータを使います。
• 改善の中心は、LCP の画像を早く読ませる、メインスレッドを長く止めない、要素の場所を先に確保する、の 3 つです。
• 当サイト（seoagent.jp）では、画像とGoogle タグの読み込みを見直し、Lighthouse のモバイルの LCP（ラボ値）を 4.1 秒から約 1.5 秒にしました。

コアウェブバイタルとは：3 つの指標と「良好」の基準

コアウェブバイタル（Core Web Vitals）とは、読み込み（LCP）・操作への反応（INP）・表示の安定性（CLS）の 3 つで実際の利用者の体験を測る Google の指標で、「良好」の基準は LCP 2.5 秒以内、INP 200 ミリ秒以下、CLS 0.1 以下です。判定は、実際の訪問の 75 パーセンタイルの値で、モバイルとパソコンを分けて行い、3 つすべてが基準を満たすと合格です（web.dev：ウェブに関する主な指標）。

Google はCore Web Vitals と Google 検索の検索結果についてで、Core Web Vitals を「ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標」と説明しています。指標ごとの区分は次のとおりです。

75 パーセンタイルとは、訪問を速い順に並べたとき、4 分の 3 の位置にある値です。つまり、訪問の 4 分の 3 以上で基準を満たせば「良好」です。

INP は 2024 年 3 月に、FID（First Input Delay）に代わってコアウェブバイタルの指標になりました。FID は最初の操作の待ち時間だけを見ていましたが、INP はページを使っている間の操作全体の反応を見ます。FID を前提にした解説は、今は古い情報です。

検索順位にどれくらい影響するのか

コアウェブバイタルは Google のランキングシステムで使われていますが、「良好」にしても上位表示は保証されず、影響の大きさを示す公式の数字も公開されていません。Google はGoogle 検索結果におけるページ エクスペリエンスについてで、レポートやツールで良い結果が得られても上位に表示されることが保証されるわけではない、と説明しています。

同じページで Google は、検索は常に最も関連性の高いコンテンツを表示するように作られており、検索語句に一致する有用なコンテンツが多数ある場合に、優れたページ エクスペリエンスが重要になるとしています。内容が同じくらい役に立つページの間で差になりうる、という位置づけです。

順位とは別に、表示の遅さやずれは、読者がページを離れる理由になりえます。検索のためだけでなく、読者の体験を整える作業として取り組むのが自然です。順位の変化の原因を探すときは、順位が下がったときの確認手順で、速度以外の要因も合わせて確かめてください。

どこで確認するか：フィールドデータとラボデータ

コアウェブバイタルの合否は、実際の利用者のデータ（フィールドデータ）を Search Console の「ウェブに関する主な指標」と PageSpeed Insights の上段で確認し、原因は Lighthouse のラボデータで調べます。

PageSpeed Insights に出る 0〜100 の点数は、ラボデータによる Lighthouse の点数です。Search Console の「良好」「不良」とは別物です。点数が 100 でもフィールドデータが「不良」のこともあり、その逆もあります。

ラボデータでは、INP は測れません。操作をしないためです。代わりに Total Blocking Time（メインスレッドが止まっていた時間の合計）を、反応の悪さの手がかりにします。

PageSpeed Insights で 1 ページを調べる手順

PageSpeed Insights では、URL を入れるだけで、1 ページのフィールドデータとラボデータを同時に確かめられます。

1. PageSpeed Insights を開き、調べたいページの URL を入力して「分析」を押す
2. 「携帯電話」と「デスクトップ」のタブを切り替えて、両方の結果を見る
3. 上段の「実際のユーザーの環境で評価する」で、LCP・INP・CLS の 75 パーセンタイルの値と合否を見る。「この URL」と「オリジン」（サイト全体）を切り替えられる
4. 下段の「パフォーマンスの問題を診断する」で、ラボの値と改善の提案（例：LCP の要素、レンダリングを妨げるリソース）を確かめる

表示名は更新で変わることがあります。アクセスの少ないページでは、上段にフィールドデータが出ません。その場合はラボデータで大きな問題がないかを見ます。点数とフィールドデータの違いや、画面の各項目の読み方は「PageSpeed Insightsの使い方」で説明しています。

Search Console でサイト全体を見る手順

Search Console では、サイトの URL を似たものごとにまとめたグループの単位で、合否を確かめられます。

1. 左のメニューで「エクスペリエンス」→「ウェブに関する主な指標」を開く
2. 「モバイル」または「PC」の「レポートを開く」を押す
3. 「不良」「改善が必要」の行を開き、問題（例：「LCP の問題: 2.5 秒超（モバイル）」）ごとの URL グループを確かめる
4. グループの代表 URL を PageSpeed Insights で調べ、原因を特定する

似た URL はグループにまとめて表示され、グループの判定は 3 つの指標のうち最も悪いものになります。対象はインデックスに登録された URL だけです。

LCP を改善する方法とコード例

LCP（Largest Contentful Paint）は、画面内で最も大きな画像や文章のかたまりが表示されるまでの時間で、2.5 秒以内が「良好」、4 秒を超えると「不良」です。LCP が遅いときは、LCP の要素（多くはファーストビューの画像）が「見つかるのが遅い」「読み込みの優先度が低い」「大きすぎる」「サーバーの応答が遅い」のどれかであることが多くあります。web.dev は、画像のダウンロードそのものより、見つけて読み始めるまでの遅れが問題になりやすいと説明しています。

LCPとは：対象になる要素と、時間の 4 つの内訳

LCP（Largest Contentful Paint）とは、ページを開いてから、画面に見えている範囲で最も大きな画像・文章のかたまり・動画が表示されるまでの時間です。web.dev によると、対象になる要素は img 要素、svg の中の image 要素、video 要素（ポスター画像か最初のフレーム）、CSS の url() で読み込んだ背景画像、文字を含むブロック要素です。不透明度が 0 の要素や、画面全体を覆う背景のような要素は除かれます。LCP の時間は、サーバーの応答（TTFB）、LCP の画像を読み始めるまでの遅れ、画像の読み込み時間、読み込み後の描画の遅れの 4 つに分けて原因を探せます（web.dev、2026 年 10 月 14 日に確認）。

LCP の画像を遅延読み込みにしない・優先度を上げる

ファーストビューの画像（LCP の要素になりやすい画像）は、loading="lazy" を付けず、fetchpriority="high" で先に読ませます。

<!-- 例：ファーストビューの画像 -->
<img src="/img/hero-800.webp"
     srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w"
     sizes="100vw"
     width="1600" height="900"
     fetchpriority="high"
     alt="サービスの画面">
<!-- loading="lazy" は付けない。2 枚目以降の画像に付ける -->

WordPress のテーマやプラグインが、すべての画像に loading="lazy" を付けることがあります。ファーストビューの画像だけは外します。WordPress が自動で付ける遅延読み込みの条件と、テーマ側の確かめ方は「WordPressの表示速度：高速化の手順」で説明しています。

CSS の背景画像は先に知らせる

CSS の背景画像は、CSS を読むまでブラウザが見つけられません。LCP の要素が背景画像なら、head で先読みを指定します。

<link rel="preload" as="image" href="/img/hero-800.webp" fetchpriority="high">

端末に合った大きさで配り、キャッシュする

スマートフォンに幅 1600px の画像を送る必要はありません。srcset と sizes で幅の違う画像を用意します。画像の形式や圧縮は「画像の最適化」で説明しています。再訪問のために、画像には長めのキャッシュ期間を付けます。

# 例：Apache の .htaccess で画像のキャッシュ期間を 1 年にする
<FilesMatch ".(webp|jpg|png|svg)$">
  Header set Cache-Control "public, max-age=31536000"
</FilesMatch>

ファイル名を変えずに画像を差し替えると、古い画像が表示され続けます。差し替えのときはファイル名を変えます。サーバーの応答（TTFB）が遅い場合は、ページのキャッシュやサーバーの見直しが必要です。

INP を改善する方法とコード例

INP（Interaction to Next Paint）は、クリック・タップ・キー入力から画面が次に描き変わるまでの時間で、200 ミリ秒以下が「良好」、500 ミリ秒を超えると「不良」です。INP が悪い主な原因は、JavaScript がメインスレッド（画面の描画と操作の処理を担う部分）を長く止めることです。50 ミリ秒を超えて止める処理を「長いタスク」と呼びます。

INPとは：数える操作と、反応の 3 つの内訳

INP（Interaction to Next Paint）とは、ページを開いている間のクリック・タップ・キー入力のうち、画面が次に描き変わるまでに最も時間がかかった操作の時間で、操作への反応の速さを表します。操作の多いページでは、50 回ごとに最も遅い 1 回を除いて計算します。ホバー・ズーム・スクロールは数えません。そのため、スクロールしかしなかった訪問では INP の値が出ません。1 回の操作の時間は、処理が始まるまでの「入力の遅れ」、処理そのものの「処理時間」、次の画面を描くまでの「表示の遅れ」の 3 つに分かれます（web.dev、2026 年 10 月 14 日に確認）。

操作の直後に必要な処理だけを先にする

クリックの処理の中で重い作業をすると、画面が反応するまで待たされます。画面の更新を先に行い、残りの処理は後に回します。

// 例：ボタンを押したら、先に表示を変え、重い処理は後で行う
button.addEventListener('click', async () => {
  button.textContent = '保存しています…';   // 画面の更新を先に
  await yieldToMain();                          // 一度ブラウザに処理を返す
  saveAndSendAnalytics();                       // 重い処理は後で
});

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

外部のスクリプトを減らし、後から読む

広告・計測・チャットなどの外部タグは、メインスレッドを止める原因になりやすい部分です。使っていないタグやプラグインを外し、残すものは defer や async で読みます。

<script src="/js/app.js" defer></script>

CLS を改善する方法とコード例

CLS（表示中の要素の予期しないずれ）は 0.1 以下が「良好」、0.25 を超えると「不良」です。後から読み込まれた要素が、表示中の文章を押し下げると悪くなるため、直し方の基本は要素の場所を先に確保することです。

CLSとは：ずれの点数の計算のしかた

CLS（Cumulative Layout Shift）とは、表示中に要素が予期せずずれた量を点数にしたもので、ページを開いている間で最も大きな「ずれのまとまり」の合計です。web.dev によると、まとまり（セッション ウィンドウ）は、ずれどうしの間隔が 1 秒未満で、全体が 5 秒以内のものを指します。1 回のずれの点数は、ずれた要素が画面に占める割合（影響の割合）と、動いた距離の割合を掛けて出します。例として、影響の割合 0.75、距離の割合 0.25 なら 0.1875 です。利用者の操作から 500 ミリ秒以内に起きたずれは除かれます（2026 年 10 月 14 日に確認）。

画像・動画・広告枠に大きさを指定する

画像・動画・広告枠に縦横の大きさを指定すると、読み込み前から場所が確保され、CLS（表示中の要素のずれ）が起きにくくなります。

<!-- 例：width と height を書くと、ブラウザが縦横比から場所を確保する -->
<img src="/img/chart.webp" width="800" height="450" alt="月ごとの推移">

/* 例：広告枠や埋め込みの場所を先に確保する */
.ad-slot { min-height: 250px; }
.embed { aspect-ratio: 16 / 9; width: 100%; }

Web フォントの切り替えによるずれを抑える

Web フォントが後から読み込まれて字体が切り替わると、文字の幅が変わって行がずれます。font-display で切り替え方を指定します。

@font-face {
  font-family: "Example Sans";
  src: url("/fonts/example.woff2") format("woff2");
  font-display: optional; /* 間に合わなければ代わりの字体のまま表示する */
}

ほかに、ページの上部に後からお知らせ帯やバナーを差し込まない、動きは transform で付ける（位置や大きさを変えるプロパティを動かさない）といった点も効きます。

当サイト（seoagent.jp）での改善例

当サイト（seoagent.jp）では、表示速度について 2 つの改善を行いました。数値はいずれも Lighthouse のモバイル設定で測ったラボ値で、実際の利用者のデータ（フィールドデータ）ではありません。当サイトはまだアクセスが少なく、フィールドデータでの変化は確認できていません。

1 つ目は、LCP の要素そのものを軽くした例です。スマートフォンの小さな画面では大きな飾りの画像が無くても内容は伝わると判断し、読み込まないようにしました。

2 つ目の考え方を、一般的な形で示します（例：当サイトのコードそのものではありません）。

<script>
  // 例：ページの読み込みが終わってから計測タグを読む
  window.addEventListener('load', () => {
    const s = document.createElement('script');
    s.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    s.async = true;
    document.head.appendChild(s);
  });
</script>

この方法では、読み込みが終わる前に離れた訪問が計測されない可能性があります。計測の正確さとの兼ね合いで判断してください。

改善の進め方と、直ったかの確かめ方

コアウェブバイタルの改善は、Search Console で「不良」の URL グループを選び、PageSpeed Insights で原因を特定して共通の原因から直し、Search Console の「修正を検証」で直ったかを確かめる、という順で進めます。

1. Search Console で「不良」の URL グループを確認し、含まれる URL の多いものから選ぶ
2. 代表の URL を PageSpeed Insights で調べ、どの指標がなぜ悪いかを特定する
3. テーマやテンプレートなど、多くのページに共通する原因から直す。変更前にバックアップを取り、1 つずつ変える
4. 修正後、PageSpeed Insights のラボの値で効果を確かめる。値は毎回少し変わるため、何度か測る
5. Search Console の問題の詳細から「修正を検証」を押す。28 日間の監視期間があり、結果が出るまで時間がかかる

表示速度は、サイトの技術的な土台の一部です。TTFB・FCP を含む速さの指標の全体と改善の順番は「表示速度とは」にまとめています。ほかの確認項目は「SEO の内部対策（テクニカル SEO）」にまとめています。コアウェブバイタルと関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。

よくある質問

PageSpeed Insights の点数は何点を目指せばよいですか？

Lighthouse では 90 点以上が「良好」の区分です。ただし検索で使われるのは点数ではなく、フィールドデータの LCP・INP・CLS です。点数は原因を探す目安として使います。

Search Console に「データがありません」と出ます。

アクセスが少なく、CrUX のデータが集まっていない状態です。悪い評価という意味ではありません。PageSpeed Insights のラボデータで大きな問題がないかを確かめます。

モバイルとパソコン、どちらを優先すべきですか？

判定は別々に出ます。Google はモバイル版のページを主にインデックスに使うため、まずモバイルの結果を確かめるのが一般的です。

直したのに Search Console の判定が変わりません。

フィールドデータは直近 28 日間の集計のため、修正後の訪問が集まるまで判定は変わりません。「修正を検証」を押して、監視期間の結果を待ちます。

SEOAGENTでできること

SEOAGENT では、実際の利用者のデータ（CrUX）による判定と、計測ツールの点数を分けて表示します。取得できた実測や計測情報をもとに改善点を検討できます。

診断機能のため、テーマやサーバーの設定は自動で変更しません。改善は、診断を見てサイト側で行います。

• AI検索・表示速度の診断
• SEO分析・効果測定

参考情報

• Google 検索セントラル：Core Web Vitals と Google 検索の検索結果について
• Google 検索セントラル：Google 検索結果におけるページ エクスペリエンスについて
• Search Console ヘルプ：ウェブに関する主な指標レポート
• PageSpeed Insights について
• web.dev：ウェブに関する主な指標
• web.dev：Interaction to Next Paint を最適化する