表示速度はSEOにどう効く？ Core Web Vitalsの見方と確かめること

表示速度は、Googleの検索の順位に使われる「Core Web Vitals（コア ウェブ バイタル）」という指標に関わります。ただしGoogleは、順位に使われる単一の「ページ エクスペリエンス シグナル」はなく、ページ エクスペリエンスが平均を下回るページも含めて、最も関連性の高いページを表示するように設計していると説明しています。速さは、内容が同じくらい役に立つページの中で差がつくところと考え、まず実際の訪問者の数字で遅いページがないかを確かめるのが現実的です。

この記事では、次のことがわかります。

• Googleが表示速度とページ エクスペリエンスについて、公式に何と言っているか
• Core Web Vitalsの3つの指標と、「良好」の目安
• Search ConsoleとPageSpeed Insightsでの見方と、数字が合わないときの考え方
• AIによる概要・AIモードと表示速度の関係
• 重いサイトで確かめること（チェックリスト）

Core Web Vitalsとは：表示の速さ・反応・ずれの3つの指標

Core Web Vitalsは、実際の利用者がページを開いたときの体験を測る、Googleの3つの指標です。Googleの文書は、読み込みの速さ、操作への反応、見た目の安定を測る指標の組み合わせだと説明しています。

CLSは、読み込みの途中だけでなく、ページを開いている間のずれ全体が対象です。web.devによると、短い間に続けて起きたずれを1つのまとまりとして合計し、そのうちいちばん大きいまとまりの値で見ます。

目安は web.dev（Googleの Web 開発者向けの解説）の書き方です。Google 検索セントラルの文書は、INPを「200 ミリ秒未満」、CLSを「0.1 未満」と書いていて、境目の値ちょうどの扱いが少し違いますが、目安の数字は同じです。

大事なのは、判定に使うのが「訪問の75%」の値だという点です。web.devは、モバイルとパソコンに分けて、ページの読み込みの75パーセンタイル（すべての読み込みのうち、4分の3がこの値以内に収まる値）で目安を満たしているかを見るのが適切だとしています。一度だけ速く開けたかどうかではなく、多くの訪問者にとって速いかを見ます。

Googleの公式の説明：順位に使われるが、それだけでは決まらない

Googleは、ページ エクスペリエンス（ページの使いやすさ全体）について、次のように書いています。

Google のランキング システムでは Core Web Vitals が使用されます。

一方で、順位に使われる単一の「ページ エクスペリエンス シグナル」があるかという問いには「単一のシグナルはありません」と答え、コア ランキング システムはさまざまなシグナルを評価するとしています。また、どのくらい大事かについては、次のように書いています。

Google 検索は、ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています。

続けて、検索語句に合う役に立つコンテンツが多数あるときは、優れたページ エクスペリエンスが順位を上げるうえで重要になる、としています。つまり、遅いから必ず順位が落ちる、速くすれば必ず上がる、というものではありません。

点数の取り方にも注意があります。Googleは、Search Consoleのレポートや外部のツールで良い結果が出ても、上位の表示が保証されるわけではないとしたうえで、「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう」と書いています。

Core Web Vitals以外の要素

Googleは、自分のページを見直す質問として、Core Web Vitalsのほかに、HTTPSで安全に配信しているか、スマートフォンで適切に表示されるか、主な内容のじゃまになるほどの広告がないか、煩わしい全画面の表示（インタースティシャル）を避けているか、主な内容とそれ以外を区別しやすいか、を挙げています。

これらは、Core Web Vitals以外の要素が順位の上昇に直接つながることはないとしつつ、訪問者の満足を高める可能性があり、それは通常ランキング システムでも高く評価される、という位置づけです。また、ページ エクスペリエンスは一般にページごとに評価され、サイト全体での評価も一部行われているとしています。

Search ConsoleとPageSpeed Insightsでの見方

自社のサイトの数字は、無料の2つの道具で確かめられます。どちらも、実際の訪問者の数字は Chrome の利用者から集めたデータ（CrUX）を使い、過去28日間を表しています。

見るときの注意は次のとおりです。

• モバイルとパソコンは別に出ます。 Googleはほとんどのサイトで主にモバイル版をインデックスに登録しているため、まずモバイルから見るとよいでしょう。
• URL グループの状態は、いちばん悪い指標で決まります。 例えばCLSが「低速」でINPが「良好」なら、そのグループは「低速」です。
• 「データがありません」は、設定の誤りとは限りません。 Search Consoleのプロパティが新しい場合や、訪問が少なくてCrUXに十分なデータがない場合に出ます。データが足りないページは、まとめて「オリジン グループ」（https:// などの方式とホスト名が同じURLの全体）として出ることもあります。オリジン グループにも十分なデータがなければ、レポートには何も出ません。
• レポートは全ページの一覧ではありません。 インデックスに登録されているURLのうちの見本です。データは正規URL（重複するページの代表のURL）ではなく、実際に開かれたURLに付きます。
• PageSpeed Insightsのフィールド データは、そのページだけの数字とは限りません。 そのURLのデータが足りないときは、サイトのすべてのページをまとめたオリジンの数字に切り替わります（オリジンのデータも足りなければ、何も出ません）。オリジンの数字は、調べたページだけの成績や、そのページを直した効果を表すものではありません。結果の欄で、そのURLの数字かオリジンの数字かを確かめましょう。
• PageSpeed Insightsの数字とレポートが合わないことがあります。 Search ConsoleはURL グループの単位でまとめ、PageSpeed Insightsはふつう1つのURLの数字を出すので、集計の単位が違います。1つのURLがグループの中で外れた値になっていることもあります。また、 ラボデータは、決まった通信の条件で1台の端末をまねて測ったもので、さまざまな端末や回線の訪問者のデータとは値が違うことがあります。ラボの診断の欄に出る100点満点の点数は、Lighthouse（Chromeに付いている診断の道具）がシミュレーションで出したもので、実際の訪問者のCore Web Vitalsの評価とは別のものです。点数は原因探しに使い、良し悪しの判断はフィールド データで行うのがよいでしょう。

AIによる概要・AIモードと表示速度

Googleの「AI 機能とウェブサイト」の文書は、AIによる概要やAIモードでサポートリンク（回答の根拠として示すリンク）として表示されるには、インデックスに登録されていること、Google 検索でスニペット（検索結果の説明文）を表示できること、検索の技術要件を満たすことが必要で、「これ以外に追加の技術要件はありません」としています。あわせて、Search Consoleの「検索の生成 AI 設定」で、サイトが生成 AI 機能に含まれていることも条件です。初期設定は「含める」ですが、親のプロパティがあるときの初期設定は「親から設定を継承する」なので、その場合は継承元の設定を確かめます（詳しくは「Search Consoleの検索の生成AI設定とは」）。表示速度に、AIの機能のための特別な基準があるわけではありません。また、これらを満たしても、表示が保証されるわけではないとGoogleは書いています。

そのうえで、同じ文書とAI 最適化ガイドは、引き続き重要な通常のSEOの基本の1つとして、優れたページ エクスペリエンスを挙げています。AI 最適化ガイドは、その中身として、すべての端末で適切に表示されること、レイテンシ（応答の待ち時間）を減らすこと、主な内容をほかの要素と区別しやすくすることを挙げています。速さは「AIのための対策」ではなく、検索全体の土台として整えるもの、と考えるのがGoogleの説明に沿っています。

なお、これはGoogle 検索の生成 AI 機能についての説明です。この記事で参照した公式の文書には、ChatGPTなどほかのAIの回答で表示速度がどう扱われるかの説明はありません。

「重いページ」で確かめたい3つのこと

「重い」には、意味の違うものが混ざりがちです。次の3つを分けて考えると、何を直すかが決めやすくなります。

1. 訪問者の体感（Core Web Vitals）：順位に使われるのはここです。上の2つの道具で、実際の訪問者の数字を見ます。
2. Googlebotが読むファイルの大きさ：Googleの文書によると、Google 検索のクロールでは、Googlebotは対応するファイル形式の最初の2MB（PDFは最初の64MB）を読みます。HTMLから読み込むCSSやJavaScriptなども、1つずつ別に取得され、同じ上限がかかります。上限に達すると取得を止め、そこまでの部分だけをインデックス登録の対象にします。上限は圧縮する前の大きさにかかります。画像用のGooglebotなどほかのクローラーには、別の上限がある場合があります。画像は別のファイルとして取得されるため、ページ全体の転送量（下の3）が大きいことと、この上限は別の話です。HTMLの中に大きなデータや画像を直接埋め込んでいるページは、HTMLの大きさと、大事な文章がHTMLの前の方にあるかを確かめておくと安心です。
3. ページ全体の転送量：画像や動画を含めた、1回の表示で読み込む合計の量です。順位の指標そのものではありませんが、訪問者の通信量が増え、特に最初に見える大きな画像が重いと、LCPが遅れる原因になることがあります。

Googleの「クロール バジェット」（Googleがサイトをクロールできる量）の考え方は、主に、重複のないページが100万以上で週1回ほど更新される大規模なサイト、1万以上で毎日更新されるサイト、Search ConsoleでURLの大部分が「検出 - インデックス未登録」になっているサイトが対象です（数は大まかな目安とされています）。ふつうの会社のサイトは、速さを理由に「クロールが追いつかない」ことを心配するより、訪問者の体感を先に見るのがよいでしょう。

中小企業のサイトで確かめるチェックリスト

Laugh Mind では、表示速度の確かめ方を次の順で整理しています（Googleの公式のチェックリストではありません）。

数字を見る

• Search ConsoleのCore Web Vitals レポートで、モバイルに「低速」「改善が必要」のURL グループがないか見た
• 「データがありません」のときは、PageSpeed Insightsで主なページ（トップ・サービス・問い合わせ）のフィールド データかオリジンのデータが出るかを見た。オリジンの数字は、そのページだけの成績ではないと考えた。どちらも出なければ、ラボデータを原因探しの参考にした
• 問い合わせや資料請求につながるページを優先した（すべてのページで満点を目指さない）

原因を探す

• LCPが遅い：最初に見える大きな画像（メインの写真・スライダー）の大きさ・形式・読み込みの順番を見直した
• INPが遅い：ボタンやメニューを押したときに、重いJavaScript（演出・外部のタグ・チャットなど）が反応を遅らせていないか確かめた
• CLSが大きい：画像や広告・埋め込みの場所に、あらかじめ大きさを指定しているか確かめた。最初の表示だけでなく、スクロールしたあとや、遅れて出る要素（広告・バナー・チャットなど）でもずれないか、実際に操作して見た
• 広告や全画面の表示が、主な内容のじゃまになっていないか見た

直したあと

• 直したページをPageSpeed Insightsで測り直した（ラボデータはすぐ変わる。直す前と同じ条件で比べる）
• フィールド データは過去28日間の値なので、直したあとの訪問だけの値になるまで28日ほどかかると考えて、Search Consoleで変化を見た。PageSpeed Insightsでオリジンの数字しか出ないページは、その変化を、そのページを直した効果と決めつけなかった
• 見た目や文章を変えていないか、スマートフォンで実際に開いて確かめた

私たちLaugh Mindの経験：演出の画像を軽くした

私たちLaugh Mindも、自社の採用ブランディングのページで、読み込みの量を見直しました。このページは、パソコンで1回に約95MBを読み込んでいました。演出用の大きな画像をロスレスのWebP（画質を落とさずに容量を小さくできる画像の形式）にするなどして、画像の見た目は同じまま、約70MBに減らしました。この数字は、当社が自社のページで測った読み込みの合計の量です。読み込みの量は、測る道具や、どこまでスクロールするか、ブラウザーのキャッシュの有無などで変わるので、同じページを開いても同じ数字になるとは限りません。

演出を大事にしたいページでも、画像の形式や大きさの見直しは、デザインを変えずに試せる方法の1つです。軽くしたあとは、上のチェックリストのとおり、そのページの実際の訪問者の数字（Core Web Vitals）があればそれで確かめます。ページだけの数字が足りないときは、直す前と同じ条件でのラボデータの比べ合わせや、実際に開いて操作した感じとあわせて見ます。サイト全体の数字が変わっても、そのページを直しただけの効果とは言い切れません。

まとめ

• Core Web Vitals（LCP・INP・CLS）は、Googleの検索の順位に使われる。ただし、ページの使いやすさ全体を表す単一の「ページ エクスペリエンス シグナル」があるわけではなく、Core Web Vitalsだけで順位は決まらない。Google 検索は、ページ エクスペリエンスが平均を下回るページも含めて、最も関連性の高いページを表示するように設計されている。
• 目安はLCP 2.5秒以内・INP 200ミリ秒以下・CLS 0.1以下で、訪問の75%で満たしているかを、モバイルとパソコンに分けて見る。
• 判断はSearch ConsoleとPageSpeed Insightsのフィールド データ（過去28日間）で行う。PageSpeed Insightsでは、そのURLの数字か、サイト全体（オリジン）の数字かを確かめる。ラボデータの点数は原因探しに使い、満点を目的にしない。
• AIによる概要・AIモードに表示されるための条件（インデックス登録・スニペット・技術要件・生成 AI 設定で、親からの継承も含めて生成AI機能に含まれていること）に、表示速度の追加の要件はない。優れたページ エクスペリエンスは、検索全体の土台として整える。
• 「重い」は、体感・Googlebotが読むファイルの大きさ（1ファイルの最初の2MB）・ページ全体の転送量の3つに分けて考える。

Googleが求める技術的な土台の全体は「中小企業のAI検索対策、最初の30日でやること」に、AIのクローラーが読めているかの確かめ方は「ChatGPT・Claudeに自社が出てこない？ AIのクローラーが読めているかの確かめ方」にまとめています。表示速度を含め、自社のサイトが検索やAIに伝わる状態かをまとめて確かめたいときは、AIO・LLMOソリューションの無料の初回診断（AIO SCORE 100）もご利用いただけます。