Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目(2026年9月時点)
Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目(2026年9月時点)
目次
01 何が起きたか — Core Web Vitalsの3指標には、公式が数字で示す3段階の基準がある
引用について
この記事の「」内のうち、英語の公式発表・公式ヘルプからの引用は、日本語に訳したものです。原文は各リンク先で確認できます。
「良好」の基準は、Googleの公式ドキュメントに明記されている
Core Web Vitals(コアウェブバイタル)は、Googleが提唱する「読み込み」「応答性」「視覚的な安定性」の3つを測る指標セットである。web.devの公式ガイドは、この3指標を次のように定義している。「Largest Contentful Paint(LCP): 読み込みのパフォーマンスを測定する。良好なユーザー体験を提供するには、LCPはページの読み込みが始まってから2.5秒以内に発生すべきである」「Interaction to Next Paint(INP): 応答性を測定する。良好なユーザー体験を提供するには、ページのINPは200ミリ秒以下であるべきである」「Cumulative Layout Shift(CLS): 視覚的な安定性を測定する。良好なユーザー体験を提供するには、ページはCLSを0.1以下に維持すべきである」。この3つの数字(2.5秒・200ミリ秒・0.1)が、「良好」の境界線として公式に定義されている値である。
「改善が必要」「不良」の境界も、Search Consoleのヘルプに表で載っている
「良好」の数字は複数の公式ページで繰り返し示されているが、「改善が必要」「不良」までを含めた3段階の表は、Search Consoleヘルプの「Core Web Vitalsレポート」ページに明記されている。原文では次のように、指標ごとの範囲が表形式で示されている。
| 指標 | 良好(Good) | 改善が必要(Need improvement) | 不良(Poor) |
|---|---|---|---|
| LCP | 2.5秒以下 | 4秒以下 | 4秒超 |
| INP | 200ミリ秒以下 | 500ミリ秒以下 | 500ミリ秒超 |
| CLS | 0.1以下 | 0.25以下 | 0.25超 |
数字は「75パーセンタイル」で判定される。1回だけの計測値ではない
これらの数字は、1回のアクセスで測った値をそのまま基準に当てはめるものではない。web.devの公式ガイドは「これらの指標について、ほとんどのユーザーで推奨目標を達成できているかを確認するには、モバイルとデスクトップに分けたうえで、ページ読み込みの75パーセンタイルを測定するのがよい基準になる」と説明している。つまり、サイトを訪れた人たちの体験を分布として集め、そのうち75%の人が基準内の体験をしているかを見る、という考え方だ。1人のユーザーがたまたま速い回線で速く読み込めたとしても、それだけでは「良好」の根拠にはならない。
INPは、2024年3月12日にFIDを正式に置き換えた新しい指標
現在の3指標のうち、INPは比較的新しい。web.devの発表記事は「今日、INPが正式にCore Web Vitalに加わり、今年(2024年)の3月12日にFID(First Input Delay)を置き換えることを発表する。この移行に伴いFIDは非推奨となる」と述べている。
切り替えのタイミングはツールによって異なり、続く一文では「FIDは、INPがCore Web Vitalになる3月12日と同時にGoogle Search Consoleから削除される。PageSpeed InsightsやCrUXなど、それ以外のツールでは、開発者がコードを更新できるよう6か月間の移行期間が設けられる」と明記されている。この記事を書いている2026年9月時点では、FIDはすでにどのツールからも役割を終えている。
02 なぜ・背景 — 3つの指標が測っているのは「体験の3つの側面」
読み込み・応答性・視覚的な安定性という3つの軸
Web Vitalsの公式ガイドは、Core Web Vitalsの位置づけを次のように説明している。「Core Web Vitalsは、すべてのウェブページに当てはまり、すべてのサイト所有者が計測すべきであり、Googleのすべてのツールで表示される、Web Vitalsのサブセットである。Core Web Vitalsの各指標は、ユーザー体験の異なる側面を表し、フィールドで計測可能であり、重要なユーザー中心の成果の実際の体験を反映している」。現在の3指標が対象にしているのは、読み込み・応答性・視覚的な安定性という3つの側面であり、どれか1つだけを測っても、ページ全体の体験は分からない。
INPがFIDを置き換えたのは「見ている範囲」が違うから
なぜFIDからINPへの切り替えが行われたのか。web.devの公式ガイドはその理由を、両者が測っている範囲の違いとして説明している。「INPは、FIDの後継指標である。どちらも応答性の指標だが、FIDはページ上の最初のインタラクションの入力遅延しか測定していなかった。INPは、入力遅延から、イベントハンドラの実行時間、そしてブラウザが次のフレームを描画するまでの、ページ上のすべてのインタラクションを観測することでFIDを改善している」。最初のクリックだけが速くても、2回目以降のクリックで固まるサイトはある。INPはページの滞在中に起きたすべての操作を見る設計になっている。
注意
FIDが「最初の1回」しか見ていなかったのに対し、INPは訪問中の全インタラクションのうち最も遅かったものを報告する。過去にFIDで「良好」だったページが、INP基準では「改善が必要」に変わることは珍しくない。
Googleは「ランキングシステムが評価する内容と一致する」と表現している
Core Web VitalsとGoogle検索の関係について、Google Search Central公式ドキュメントは次のように述べている。「Core Web Vitalsは、ページの読み込みパフォーマンス・応答性・視覚的な安定性について、実際のユーザー体験を測定する指標のセットである。検索での成功と、一般的に優れたユーザー体験を確保するために、サイト所有者が良好なCore Web Vitalsを達成することを強く推奨する。これは、他のページエクスペリエンスの側面とともに、当社のコアランキングシステムが評価しようとしている内容と一致している」。順位を直接押し上げる係数の大きさまでは、この文からは読み取れない。「評価しようとしている内容と一致する」という表現にとどまっている点は、正確に読んでおく必要がある。
03 この記事で出てくる用語
用語
LCP(Largest Contentful Paint)—ビューポート内に表示される最大の画像・テキストブロック・動画が描画されるまでの時間。読み込みの速さを表す。良好の基準は2.5秒以下。
用語
INP(Interaction to Next Paint)—訪問中に発生したクリック・タップ・キー入力のすべてについて、操作から次の画面更新までの時間を観測し、最も遅かった応答を報告する指標。応答性を表す。良好の基準は200ミリ秒以下。2024年3月12日にFIDを置き換えた。
用語
CLS(Cumulative Layout Shift)—ページの表示中に要素の位置が予期せずずれる量を、視覚的な移動割合から累積したスコア。視覚的な安定性を表す。良好の基準は0.1以下。
「フィールドデータ」と「ラボデータ」は、測る場所も対象人数も違う
Core Web Vitalsを扱う記事では「フィールドデータ」「ラボデータ」という言葉が頻繁に出てくる。この2つは似た言葉ではなく、測り方そのものが異なる。web.devの公式ガイドは次のように定義している。
用語
ラボデータ(Lab data)—「あらかじめ決められたネットワークとデバイスの条件からなる、制御された環境でウェブページを読み込むことで測定されるデータ」。Lighthouseを実行するツールが報告する。1台のデバイス・1つのネットワーク・1つの場所から測る。
用語
フィールドデータ(Field data)—「あるページを訪れたすべてのユーザーを監視し、それぞれのユーザー個々の体験について、決められたパフォーマンス指標を測定することで決まるデータ」。Real User Monitoring(RUM)データとも呼ばれ、Chrome User Experience Report(CrUX)から取得されることが多い。
フィールドデータは「1つの数字」ではなく「分布」である
この違いを押さえておかないと、後述する測定ツールの数字が食い違って見えたときに混乱する。web.devの公式ガイドは「フィールドデータについて理解すべき最も重要なことは、それが単一の数字ではなく、数字の分布であるという点だ」と述べたうえで、実例を示している。
「フィールドデータのLCPの分布を見ると、訪問の88%はLCPが2.5秒以下(良好)、8%は2.5秒から4秒の間(改善が必要)、4%は4秒を超えていた(不良)。75パーセンタイルでは、LCPは1.8秒だった」。同じページのラボデータでは3.0秒だったと続く。ラボは1本の計測値、フィールドは大勢の分布から取った75パーセンタイル値という違いが、この数字の差に表れている。
04 型別 — 適用範囲・この記事が測っていないこと・手順
🅰 適用範囲 — すべてのサイトが対象になる指標
Core Web Vitalsは、特定の業種や規模のサイトに限定された基準ではない。画像や動画を多く使うサイトではLCP、クリックやタップの多いフォーム・メニューを持つサイトではINP、広告や埋め込みコンテンツを表示するサイトではCLSが、それぞれ問題になりやすい傾向はあるが、基準自体はすべてのページに等しく当てはまる。3指標のうち1つだけを気にして残り2つを見ないと、片方を直したつもりで別の指標を悪化させることがある点には注意したい。
🅱 この記事が測っていないこと・分からないこと
本記事はweb.devとGoogle Search Central、Search Consoleヘルプの公式資料を中心に確認した。分からないことを、分かるふりで埋めていない。
第一に、Core Web VitalsがGoogleの検索順位付けアルゴリズムの中で、具体的にどれだけの重みを持つかという係数は、公式ドキュメントに明示されていない。「一致している」という表現にとどまっている。
第二に、Lighthouseのパフォーマンススコア(0〜100)が、LCP・INP・CLSをどのような重み付けで合算しているかの詳細な計算式は、本記事の範囲では確認していない。
第三に、モバイル端末の機種差やネットワーク回線の違いによって、同じページでもフィールドデータの分布がどこまで変動するかは、実際にサイトごとに異なるため、一律の数字では示せない。
🅲 手順 — 自分のサイトで5分測る流れ
実際の確認は、次の流れで進める。第一にPageSpeed Insightsで対象URLを測り、フィールドデータとラボデータの両方を見る。第二に、フィールドデータが表示されない場合はSearch Consoleの「ウェブに関する主な指標」レポートでサイト全体の傾向を見る。第三に、不良と判定された指標があれば、そのページを実際に開いて原因になっていそうな要素(大きな画像・重いスクリプト・後から差し込まれる広告など)を目視で確認する。05章のチェックリストは、この3段階をそのまま作業に落とし込んだものである。
実務のヒント
1ページずつ手作業で測るのが手間なときは、当サイトの🔧 Lighthouse監査・チェックツール(利用には無料の会員登録が必要です)で最大3ページまでまとめて測定できる。
05 明日、自分のサイトで確認できることチェックリスト
以下は、今日からPageSpeed InsightsとSearch Consoleだけで確認できる項目である。1〜4番目はフィールドデータとラボデータの見分け方、5〜6番目はサイト全体の傾向、7〜9番目は不良と判定された場合の原因の当たりをつける作業、10〜14番目は記録と再測定の準備にあたる。
- PageSpeed Insightsに自社のトップページURLを入力し、モバイル・デスクトップ両方でレポートを開く
- 表示された結果が「フィールドデータ」と「ラボデータ」のどちらの見出しの下にあるかを確認する
- LCP・INP・CLSそれぞれの数値を、01章のしきい値の表と照らして良好・改善が必要・不良のどれに当たるか判定する
- フィールドデータの欄に「このURLのデータが不足しています」と表示されていないか確認する
- Search Consoleの「ウェブに関する主な指標」レポートを開き、モバイル・デスクトップ別にURLグループのステータスを確認する
- 「不良」または「改善が必要」に分類されているURLグループの件数を数える
- LCPが不良の場合、そのページで最も大きく表示されている画像・見出し・動画のどれが該当するかを目視で特定する
- CLSが不良の場合、ページ読み込み中に位置がずれる広告・埋め込み・後から差し込まれる要素が無いか、実際にページを開いて確認する
- INPが不良または改善が必要の場合、クリックしてから反応が返るまでに遅れを感じる操作を3つ試して確認する
- 過去に同じページを測った記録がある場合、今回の数値と比べて改善したか悪化したかを記録する
- Chrome DevToolsのLighthouseパネルでラボデータを取得し、PageSpeed Insightsのラボデータと大きくずれていないか確認する
- 同じページで、モバイルとデスクトップのステータスが食い違っていないか確認する
- 今週行った変更から数えて、まだ28日が経過していないかを確認する
- 改善を行った場合、変更から1〜2週間後にもう一度同じ手順で測り直す予定を立てる
| 観点 | 該当する項目 | 目安時間 |
|---|---|---|
| フィールド・ラボデータの見分け | 1〜4番目(4項目) | 10分 |
| Search Consoleでの全体傾向確認 | 5〜6番目(2項目) | 10分 |
| 不良の原因の当たりをつける | 7〜9番目(3項目) | 10分 |
| 記録と再測定の準備 | 10〜14番目(5項目) | 10分 |
すべてに目を通す時間の目安は1サイトあたり40分程度である。複数の主要ページを対象にする場合は、ページ数に応じて比例して時間が増える。件数が多いサイトでは、当サイトの🔧 WEBサイト総合分析・レポートツールでサイト全体の状態を先にまとめて確認しておくと、優先して測るべきページを絞り込みやすい。
06 代替・他の選択肢(表で)
測定ツールは1つではない。データの種類と見られる範囲が違う
Core Web Vitalsを測るツールは、PageSpeed Insightsだけではない。PSIの公式ガイドは「PSIは、ページについてラボデータとフィールドデータの両方を提供する。ラボデータは制御された環境で収集されるため、問題のデバッグに役立つ。ただし、実際のボトルネックを捉えられないことがある。フィールドデータは、実際のユーザー体験を捉えるのに役立つが、計測できる指標の種類はより限定的になる」と説明している。目的によって、どのツールを使うべきかが変わる。
| ツール | データ種別 | 見られる範囲 | 向いている場面 |
|---|---|---|---|
| PageSpeed Insights | フィールド+ラボ両方 | 入力した1URLずつ | 個別ページの診断と原因の特定 |
| Search Console CWVレポート | フィールドのみ(CrUX由来) | サイト全体をURLグループで | 優先して直すべきページ群の洗い出し |
| Chrome DevTools (Lighthouseパネル) | ラボのみ | 自分の環境で開いた1URL | 開発中の変更をその場ですぐ確認 |
| CrUXダッシュボード | フィールドのみ | サイト全体の月次推移 | 長期的な傾向を追う |
| web-vitals (JSライブラリ) | フィールド(自前計測) | 自社で計測対象にした全訪問者 | CrUXだけでは足りない詳細なRUMを自前で持つ |
PageSpeed InsightsのCrUXデータは日次更新、BigQueryのCrUXデータセットは月次更新
同じCrUXという発生源のデータでも、取り出し方によって更新頻度が違う点は見落とされやすい。PSIの公式ガイドは「PSIのデータが毎日更新されるのに対し、BigQuery上のCrUXデータセットは月次更新であり、オリジンレベルのデータに限定される」と説明している。細かい変化を追いたいならPSI、長期の大きな傾向を見たいならCrUX Dashboard、というように使い分けの軸になる。
07 自社サイトで確認したこと — 直した指標と、まだ直していない指標
CLSは0.234から0.034まで下がった
当サイトの記事ページでは、2026年9月19日にCLSが0.234から0.034まで改善した。原因は、記事の目次を後から差し込む形にしていたのを、ページの読み込み時点で最初から表示する形に変えたことだった。目次があとから挿入されると、その分だけ下の本文が押し下げられ、視覚的な移動が発生していた。CLSは「何かを消す」より「表示のタイミングを前倒しする」ことで下がる場合があるという一例になる。
トップページの画像の合計サイズは18.5MBから4.3MBになった
同じ日、トップページの画像の合計サイズが18.5MBから4.3MBへと、4分の1以下まで減った。原因は、一覧に表示するスライダー部分が原寸の画像をそのまま読み込んでいたのを、表示サイズに合わせた小さい版の画像を使う形に変えたことだった。画像のファイルサイズは、LCPが計測する「最大の要素の描画時間」に直接影響する要因のひとつである。
注意
トップページのLCPは、この記事を書いている時点でまだ改善に着手していない。画像の合計サイズを減らしたことがLCPにどう影響するかは、改めて測り直す必要がある。「関連する数値を直したから、この指標も良くなっているはずだ」と推測だけで済ませず、実際にもう一度測る。
直した指標と、まだ手を付けていない指標を、分けて記録する
今回の対応は、CLSと画像サイズという2点にとどまっている。LCP自体の数値がどう変化したか、INPに問題がないかは、この記事の時点ではまだ確認していない。「サイトを改善した」とひとくくりに書かず、何を直して何がまだ残っているかを分けて記録することは、05章のチェックリストの10番目(過去の記録と比較する項目)を、当サイト自身が実践している形でもある。
08 このテーマの、これまで
2020年5月、Core Web Vitalsが発表された
Core Web Vitalsという枠組みは、2020年5月に登場した。Google Search Central公式ブログの「Evaluating page experience for a better web」という記事が、その最初の発表とされている。この時点ではまだ検索結果への影響は発表段階で、指標の定義とツールでの計測開始が先に案内された。
2021年、ページエクスペリエンスの一部としてランキングに組み込まれた
その後、Core Web Vitalsを含む複数のユーザー体験シグナルをまとめた「ページエクスペリエンス」という考え方が示され、2021年にランキングシステムへの組み込みが段階的に行われた。今日の02章で見た「コアランキングシステムが評価しようとしている内容と一致している」という現在の説明は、この経緯を踏まえたものになる。
2024年3月12日、FIDがINPに置き換わった
3つの指標の顔ぶれは、ずっと同じだったわけではない。01章・02章で見たとおり、応答性を測る指標は当初FIDだった。2024年1月31日に切り替えの予告が発表され、2024年3月12日にINPが正式にCore Web Vitalとなり、FIDは役目を終えた。Search Consoleでは即日FIDの表示が終了し、PageSpeed InsightsとCrUXでは6か月間の移行期間が設けられた。現在の3指標(LCP・INP・CLS)の組み合わせは、この切り替えを経て今の形になっている。
この記事の数字も、確認した時点のものとして扱ってほしい
本記事で示したしきい値の出典は、Search Consoleヘルプの「Core Web Vitalsレポート」ページと、web.devの各指標ページから確認した。web.devの「vitals」記事の最終更新は2024年10月31日、「INP」記事の最終更新は2025年9月2日、developers.google.comの「Core Web Vitals」ドキュメントの最終更新は2025年12月10日である。公式ガイドの本文は今も更新され続けている一方、しきい値の数字自体は本記事の確認時点(2026年9月)でも変わっていなかった。将来また指標や基準が見直される可能性はあるため、必要なら公式ガイドを直接開いて最新の記載を確認してほしい。
現在の貴方のIPアドレス
このサイトで書いている人
WEBサイト