コアウェブバイタル（Core Web Vitals。Search Console の日本語の画面では「ウェブに関する主な指標」）は、Googleが実際の訪問者のデータで測る、ページの使い心地の3つの指標です。LCP（一番大きな画像や文章が表示されるまでの時間）は2.5秒以下、INP（クリックやタップへの反応の遅さ）は200ミリ秒以下、CLS（表示中のずれ）は0.1以下が「良好」の基準です。
判定には、モバイルとパソコンに分けた、訪問の75パーセンタイル（速い順に並べて4分の3の位置の値）が使われます。Googleは、Core Web Vitals を検索のランキングの仕組みで使っていると説明する一方、良い数字でも上位表示は保証されず、ページの体験が劣っていても関連性の高い内容が表示される、とも書いています。
小さな会社がやることは、Search Console のレポートで「低速」のページがないかを確かめ、データが出ていなければ PageSpeed Insights で主なページを測り、赤い指標があれば直す、までです。満点を追う必要はありません。
3つの指標の意味と「良好」の基準値
web.dev（Googleのウェブ開発者向けの解説サイト）と Search Console のヘルプが示す基準値は次のとおりです。Search Console では、3段階を「良好」「改善が必要」「低速」と表示します。
| 指標 | 何を測るか | 良好 | 低速 |
|---|---|---|---|
| LCP | 一番大きな画像や文章のかたまりが表示されるまで | 2.5秒以下 | 4秒を超える |
| INP | クリック・タップ・キー操作への反応の遅さ | 200ミリ秒以下 | 500ミリ秒を超える |
| CLS | 表示中に起きる予期しないずれ | 0.1以下 | 0.25を超える |
「良好」と「低速」の間が「改善が必要」です。なお、Google 検索セントラルの説明では「2.5秒以内」「200ミリ秒未満」「0.1未満」と書かれていて、境目ちょうどの扱いが文書によって少し違います。境目ぴったりの数字で悩む場面はまれなので、目安として覚えておけば足ります。
LCP（Largest Contentful Paint）：読み込みの速さ
ページを開いてから、画面に見えている範囲で一番大きな画像、文章のかたまり、または動画が表示されるまでの時間です。web.dev の説明では、img要素の画像、背景に指定された画像、動画、文章を含むかたまりなどが対象になります。会社のホームページでは、一番上の大きな写真（メインビジュアル）や、記事の題と冒頭の文章がLCPの要素になることが多いでしょう。サーバーが最初の応答を返すまでの時間も、LCPに含まれます。
INP（Interaction to Next Paint）：操作への反応の速さ
ページを開いている間のクリック、タップ、キー操作について、操作してから画面が次に描き変わるまでの遅れを測ります。ホバー（マウスを重ねるだけ）、スクロール、拡大縮小は対象外です。メニューのボタンを押したのに開くまで間がある、といった「もたつき」を数字にしたものです。
INPは2024年に、それまでのFID（最初の操作の反応だけを測る指標）に代わって Core Web Vitals に加わりました。古い解説記事でFIDが出てくるのは、このためです。
CLS（Cumulative Layout Shift）：見た目の安定
読んでいる途中で、文章やボタンが急に下にずれる現象の大きさです。押そうとしたボタンがずれて、別のところを押してしまう、といった体験を数字にしたものです。web.dev の説明では、クリックやタップなどの操作から500ミリ秒以内に起きたずれは、利用者が予期したものとして除かれます。
「75パーセンタイル」と「28日間」：合否の決まり方
Core Web Vitals は、1回の計測ではなく、実際の訪問の積み重ねで決まります。web.dev の説明では、モバイルとパソコンに分けた訪問の75パーセンタイルで判断します。たとえば100回の訪問があれば、速い方から75回目あたりの値が「良好」の範囲に入っていれば合格です。一部の遅い回線の訪問者がいても、4回に3回が良好なら合格という考え方です。
PageSpeed Insights の説明では、集計の期間は過去28日間です。3つの指標すべての75パーセンタイルが「良好」なら合格で、INPのデータが足りない場合はLCPとCLSが「良好」なら合格になります。
このデータの元は、Chrome ユーザー エクスペリエンス レポート（Chromeの利用者から集めた表示速度の統計。CrUX）です。Chromeでそのページを開いた人がある程度いないと、統計にならず、数字が出ません。
Search Console の「ウェブに関する主な指標」レポートの見方
Search Console では、左のメニューの「ウェブに関する主な指標」で、サイト全体の状況を見られます（ヘルプでは「Core Web Vitals レポート」とも書かれています）。見る手順は次のとおりです。
- Search Console で自社のサイトのプロパティを開き、左のメニューから「ウェブに関する主な指標」を開きます。
- モバイルとパソコンのグラフが並びます。見たい方のグラフの横の「レポートを開く」を押します。
- 「低速」「改善が必要」「良好」ごとの件数と、問題の種類（例：LCPが長い）が出ます。「低速」の行から開きます。
- 問題を開くと、似たページをまとめた「URLグループ」と、その例のURLが出ます。同じテンプレートで作られた記事ページなどが、一つのグループにまとめられます。
- 例のURLを PageSpeed Insights で測り、原因を探します。
ヘルプの説明では、URLは「ユーザー エクスペリエンスが類似するページ」ごとにグループにされます。1ページずつではなく、似たページをまとめて見る仕組みなので、テンプレートの共通部分（一番上の大きな画像、共通のヘッダーなど）を直すと、まとめて良くなることがあります。
直したあとは、問題の詳細の画面から検証を始めます。ヘルプでは「トラッキングを開始」を押すと28日間の確認が始まり、その間に問題が出なければ解決とみなされる、と説明されています。過去28日間のデータで判定する仕組みなので、直した翌日に表示が変わるものではありません。
「データがありません」と出たとき
アクセスの少ないサイトでは、このレポートに「データがありません」と出ることがあります。ヘルプは、その理由を、プロパティが新しいか、CrUXのデータが足りないため、としています。また、LCPとCLSの両方のデータが最低限に満たないURLは、レポートから除かれます。
これは不具合ではなく、放っておいて構いません。当社のサイトも、記事のページを PageSpeed Insights で調べると「Chrome ユーザー エクスペリエンス レポートには、このページの実際の速度データが十分にありません。」と出ます（2026年10月9日）。訪問者が多くない会社のサイトでは、よくある状態です。
実際のデータがないうちは、PageSpeed Insights の下の部分で見る
実際のデータが出ないうちは、PageSpeed Insights の下の部分（「パフォーマンスの問題を診断する」。Googleの側での1回の模擬の読み込み）で代わりに見ます。ただし、ここでは3つの指標がそのまま出るわけではありません。
- LCP：そのまま出ます。
- CLS：そのまま出ます。ただし、試験の読み込みの間に起きたずれが対象で、訪問者が読み進めてから起きるずれは拾えないことがあります。
- INP：出ません。人が操作しない試験なので測れないためです。web.dev は、代わりに Total Blocking Time（TBT。読み込み中に操作を受け付けない時間の合計）を大まかな目安にできるが、INPの完全な代わりにはならない、としています。
当社の記事ページ（「クロール済み – インデックス未登録」の記事）を2026年10月9日に携帯電話の条件で1回測った結果は、LCP 4.8秒、CLS 0、TBT 150ミリ秒でした。LCPは「良好」の2.5秒を大きく超えていて、手を付けるならここです。CLSは0でずれがなく、TBTも Chrome の説明で携帯電話の緑（200ミリ秒まで）の範囲に入っています。実際の訪問者のデータではないので、Core Web Vitals に合格・不合格とは言えませんが、「直すならLCP」という判断はこれで十分につきます。結果の読み方の詳細はPageSpeed Insightsの使い方と見方に書きました。
検索順位との関係：Googleが公式に言っていること
Core Web Vitals と検索順位の関係は、言い過ぎた解説が多いところです。Google 検索セントラルの「ページ エクスペリエンス」の説明（日本語版）から、該当する文をそのまま引きます。
- 「Google のランキング システムでは Core Web Vitals が使用されます。」
- 良い数字であっても、「Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」
- 「単一のシグナルはありません。」
- 「ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています。」
- 「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう。」
一方で、Core Web Vitals の説明のページでは、「サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。」とも書いています。
まとめると、速さは検索の評価に使われてはいるものの、それだけで順位が決まるものではなく、検索した人の用事に合った中身の方が優先される、ということです。当社は、順位のために数字を磨くより、まず中身を整え、そのうえで「低速」をなくす、という順番で考えています。速さが効いてくるのは、順位よりも、開いた人が待ちきれずに帰ってしまうかどうかの方だと見ています。
指標ごとの、よくある原因と最初に試すこと
| 指標 | よくある原因 | 最初に試すこと |
|---|---|---|
| LCP | 大きすぎる画像、サーバーの応答の遅さ、表示を妨げるCSSやJavaScript | 一番上の画像を縮める、遅延読み込みにしない |
| INP | 重いJavaScript、外部のタグやプラグインの多さ | 使っていないプラグインやタグを外す |
| CLS | 大きさの指定がない画像や動画、後から入る広告や埋め込み、文字の書体の入れ替わり | 画像に幅と高さを指定する、埋め込みの場所を空けておく |
LCPについて、web.dev は「LCP 画像を遅延読み込みしないでください。」と書いています。一番上の写真を「後から読み込む」設定にしていると、かえって遅くなります。画像の縮め方や遅延読み込みの扱いは画像の最適化に、原因の切り分けと直す順番はホームページが重い・表示が遅いときの原因と直す順番にまとめました。
CLSについて、web.dev は大きさの分からない画像や動画、大きさが変わる広告や部品、既にある内容の上に後から差し込まれる要素などを原因に挙げています。WordPressは、メディアから本文に入れた画像に幅と高さの指定を補うので、本文の画像よりも、ずれの原因になりやすいのは、後から読み込まれる外部の部品（地図、SNSの埋め込み、チャットの窓など）です。
小さな会社がやること、やらなくてよいこと
やることは、次の5つで足ります。
- 月に一度、Search Console の「ウェブに関する主な指標」で、「低速」のURLグループがないかを見ます。ほかに見る画面と合わせて、サーチコンソールの使い方：中小企業が月に一度見る画面と決めることにまとめました。
- 「データがありません」なら、トップ、主なサービスのページ、問い合わせのページ、よく読まれる記事を PageSpeed Insights の携帯電話の条件で測ります。
- 赤い指標（LCPなら4秒以上）があるページから直します。LCP、CLS、TBTのうち悪いものに効く手を打ちます。
- 直したら、PageSpeed Insights で測り直します。Search Console にデータがあるなら、検証を始めます。
- ページを増やしたり、デザインや外部の部品を変えたりしたときに、もう一度測ります。
やらなくてよいのは、すべての指標を緑にすること、点数を100に近づけることです。Googleの言うとおり、満点を取りにいく時間は、検索した人の用事に答えるページを1本増やす方に回した方が、問い合わせにはつながりやすいと当社は考えています。速さのために、説明や写真を削りすぎるのも本末転倒です。
当社の関わり方
当社は、ホームページの運営に加わり、検索から問い合わせが来るまでを引き受けています。表示速度は、その道のりの途中で詰まっていれば直す項目の一つで、何よりも先にやることではありません。どの指標から手を付けるべきか、そもそも速度に手を入れる段階なのかを一緒に判断したい場合は、相談するからお知らせください。
参考にした公式の説明
- web.dev「ウェブに関する主な指標」
- web.dev「Largest Contentful Paint（LCP）」
- web.dev「Interaction to Next Paint（INP）」
- web.dev「Cumulative Layout Shift（CLS）」
- web.dev「LCP を最適化する」
- Search Console ヘルプ「Core Web Vitals レポート」
- Google 検索セントラル「Core Web Vitals」
- Google 検索セントラル「ページ エクスペリエンス」
- Google for Developers「PageSpeed Insights について」
※内容は2026年10月時点の各公式の説明で確かめたものです。Search Console の画面の表示名は変わることがあります。当社の数字は、2026年10月9日に当社の記事ページを1回計測した結果です。