この記事の要点：
- ここでいう表示速度は、Webページが表示され、読んだり操作したりできるようになるまでの速さのことです。1つの数字ではなく、サーバーの応答（TTFB）、最初の表示（FCP）、主な内容の表示（LCP）、操作への応答（INP）、表示のずれ（CLS）などの指標に分けて測ります。
- Google は、ランキング システムで Core Web Vitals（LCP・INP・CLS）を使うと説明しています。一方で、良い結果が出ても上位表示が保証されるわけではなく、点数の満点を取ること自体を目的にしないよう書いています。
- 測る道具は、実際の利用者のデータ（フィールド）と、決まった条件で測るデータ（ラボ）で役割が違います。PageSpeed Insights と Search Console で実際の利用者の値を、Lighthouse で原因を見ます。
- 直す順番は、悪い指標から逆算して決めます。サーバー、最も大きく表示される画像、スクリプト、フォントと表示のずれの順に、原因を1つずつ確かめます。
表示速度とは：Webページが表示され、使えるようになるまでの速さ
表示速度とは、Webページを開いてから、内容が表示され、読んだり操作したりできるようになるまでの速さのことです。ページ速度・ページスピードとも呼ばれます。「表示速度」という語は車の速度表示などにも使われますが、この記事ではWebページの表示速度を扱います。
表示速度は1つの数字では表せません。ページを開くと、サーバーが応答し、最初の文字や画像が描かれ、主な内容が表示され、ボタンなどが操作できるようになります。どの段階が遅いかで原因も直し方も変わるため、段階ごとの指標に分けて測ります。
Google は、ウェブで優れたユーザー エクスペリエンスを実現するための指標をまとめた取り組みを Web Vitals と呼び、そのうちすべてのページで測るべき3つを Core Web Vitals としています（web.dev「Web Vitals」、最終更新日 2024年10月31日、2026年10月13日確認）。3つの指標の基準と改善方法の詳細は「コアウェブバイタルとは」で説明しています。
表示速度とSEO：Googleの説明
表示速度は検索順位に関係しますが、関係の仕方は限られています。Google は、ページ エクスペリエンスのうちランキングに使われる要素について「Google のランキング システムでは Core Web Vitals が使用されます」と答えています（Google 検索セントラル「ページ エクスペリエンスと Google 検索結果への影響」、最終更新日 2026-09-25、2026年10月13日確認）。
同じページで Google は、Search Console の Core Web Vitals レポートやほかのツールで良い結果が得られても、上位表示が保証されるわけではないとし、「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう」と書いています。また、検索は「ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています」とし、検索語に合う役に立つページが多数ある場合に、優れたページ エクスペリエンスが重要になると説明しています。
| よくある誤解 | 実際（Google の説明） |
|---|---|
| PageSpeed Insights の点数が低いと順位が下がる | ランキングに使われるのは Core Web Vitals で、点数の満点を目指すこと自体は勧められていない。点数はラボの値で、実際の利用者の値とは別 |
| 表示が速ければ上位に入る | 良い結果でも上位表示は保証されない。内容が検索語に合っていることが前提 |
| サイト全体で1つの評価がある | 一般的にはページ単位で評価し、サイト全体での評価も一部で行う |
| Core Web Vitals 以外の速さは関係ない | ほかのページ エクスペリエンスの要素はランキングを直接上げないが、利用者の満足を高めることには意味がある |
検索順位とは別に、表示が遅いと、読者が内容を見る前に離れてしまうことがあります。速さは SEO のためだけでなく、来た人に内容を届けるために整えるものと考えると、優先順位を決めやすくなります。
表示速度を表す指標の一覧
表示速度を表す主な指標は、TTFB・FCP・LCP・INP・CLS の5つです。このうち LCP・INP・CLS が Core Web Vitals で、TTFB と FCP は原因を探すための補助の指標です。次の表の「良好」「低速」の基準は、PageSpeed Insights と web.dev の記載に基づきます（2026年10月13日確認）。
| 指標 | 何を測るか | 良好 | 低速（不良） | Core Web Vitals |
|---|---|---|---|---|
| TTFB（最初のバイトまでの時間） | ページをリクエストしてから、サーバーの応答の最初のバイトが届くまで。リダイレクト・DNS・接続・サーバーの処理を含む | 0.8秒以下 | 1.8秒超 | いいえ |
| FCP（最初のコンテンツの表示） | 何らかの文字や画像が最初に画面に描かれるまで | 1.8秒以下 | 3.0秒超 | いいえ |
| LCP（最大のコンテンツの表示） | 画面内で最も大きな画像や文字のかたまりが表示されるまで | 2.5秒以下 | 4.0秒超 | はい |
| INP（次の描画までの操作の応答） | クリックやタップなどの操作から、画面が反応して描き変わるまで | 200ミリ秒以下 | 500ミリ秒超 | はい |
| CLS（累積レイアウト シフト） | 表示中に要素が予期せずずれた量 | 0.1以下 | 0.25超 | はい |
web.dev は、これらの目標を「ページ読み込みの75パーセンタイル」で測ることを勧めています。訪問の4分の3以上で基準を満たしているかを見る、という意味です。TTFB について web.dev は「Core Web Vitals の指標ではない」とし、重要な指標を損なわない限り良好の基準を満たすことは必須ではないと書いています（web.dev「最初のバイトまでの時間（TTFB）」）。
ラボの道具でよく見る TBT（合計ブロック時間）は、INP の代わりにラボで測る値です。web.dev は、Lighthouse のように利用者がいない環境では INP を測れず、TBT が INP のプロキシ（代わりの目安）になると説明しています。TBT が良くても、実際の INP が良いとは限りません。
表示速度の測り方：道具ごとの違い
表示速度を測る道具は、実際の利用者のデータ（フィールド データ）を見るものと、決まった条件でページを読み込んで測るもの（ラボ データ）に分かれます。順位に関係する Core Web Vitals の判定は、実際の利用者のデータで行われます。web.dev は、ラボでの測定は開発中のテストや低下の把握に最適だが「フィールドでの測定の代わりにはなりません」としています。
| 道具 | データ | 分かること | 使いどころ |
|---|---|---|---|
| PageSpeed Insights | フィールド（CrUX、過去28日間）とラボ（Lighthouse） | URL 単位の実際の利用者の FCP・LCP・INP・CLS・TTFB と、改善案 | 1ページずつ、実際の値と原因の候補を同時に見る |
| Search Console の Core Web Vitals レポート | フィールド（過去28日間） | 似たページをまとめた URL グループごとの、良好・改善が必要・低速の状態 | サイト全体で、どの種類のページが遅いかを見る |
| Lighthouse（Chrome デベロッパー ツールなど） | ラボ | 点数・各指標・遅い原因の監査項目 | 直す前後を同じ条件で比べる、原因を探す |
| Chrome デベロッパー ツールのパフォーマンス | 手元のブラウザ | 読み込みや操作の間に何が起きているかの時間の流れ | どのスクリプトが処理を止めているかを詳しく見る |
PageSpeed Insights は、ページが新しい場合や実際の利用者のサンプルが少ない場合は URL 単位のデータが無く、サイト全体（オリジン）のデータを表示し、それも不十分なら実際の利用者のデータを表示できないと説明しています（PageSpeed Insights について、最終更新日 2025-07-25）。Search Console でも、プロパティが新しいかデータが不足していると「データがありません」と表示されます（Search Console ヘルプ「Core Web Vitals レポート」）。アクセスの少ないサイトは、ラボの値で原因を探しながら、実際の値が出るのを待つことになります。PageSpeed Insights の画面の読み方は「PageSpeed Insightsの使い方」にまとめています。
遅い原因の見つけ方
遅い原因は、どの指標が悪いかから逆算して探します。指標ごとに、遅れが起きている段階が違うためです。WordPress のサイトで、TTFB・LCP の要素・画像・スクリプトの順に原因を切り分ける手順は「WordPressの表示速度の改善」で説明しています。
- Search Console の Core Web Vitals レポートで、モバイルとパソコンそれぞれの「低速」「改善が必要」の URL グループと、問題の種類（LCP・INP・CLS）を確かめます。
- 問題のグループの代表の URL を PageSpeed Insights で調べ、実際の利用者の値で悪い指標を確かめます。
- 同じページを Lighthouse で測り、監査項目（レンダリングを妨げるリソース、使われていない JavaScript、画像の配信など）から原因の候補を挙げます。
- 原因の候補を1つずつ直し、同じ条件で測り直します。複数をまとめて直すと、どれが効いたか分からなくなります。
| 悪い指標 | まず疑うこと | 確かめる場所 |
|---|---|---|
| TTFB | サーバーの処理の遅さ、キャッシュの未使用、リダイレクトの多さ | PageSpeed Insights の TTFB、サーバー・CMS のキャッシュ設定 |
| FCP | 表示を止める CSS・JavaScript・Web フォントの読み込み | Lighthouse の「レンダリングを妨げるリソース」 |
| LCP | 最も大きな画像の重さ・読み込みの遅れ、TTFB の遅さ | Lighthouse で LCP の要素を特定する |
| INP | 操作時に長く動くスクリプト、計測タグや広告などの外部スクリプト | 実際の利用者の INP、ラボでは TBT とメインスレッドの処理 |
| CLS | 大きさを指定していない画像・広告枠、後から差し込まれる部品、フォントの切り替え | Lighthouse の「レイアウト シフト」の項目 |
改善の順番：サーバー・画像・スクリプト・フォント
表示速度の改善は、影響の大きい段階から順に進めます。後の段階はその前の段階の時間を含むため、サーバーの応答が遅いままでは画像を軽くしても LCP は縮みにくくなります。一般的な順番は次のとおりですが、実際には前の節で確かめた悪い指標に合わせて選びます。
- サーバーとキャッシュ：TTFB が遅いなら、サーバーのキャッシュ、CMS のページキャッシュ、不要なリダイレクトを確かめます。WordPress ではキャッシュの設定とプラグインの数から見ます。全般の進め方は「WordPressのSEO」で説明しています。
- 最も大きく表示される画像：LCP の要素が画像なら、表示する大きさに合った幅の画像を用意し、軽い形式にします。最初の画面に入らない画像は遅延読み込みにします。画像の形式と遅延読み込みは「画像最適化とlazy loadの使い方」にまとめています。
- スクリプト：使っていない JavaScript、重複した計測タグ、表示に関係ない外部スクリプトを減らすか、読み込みを後にします。INP と TBT に効きます。
- フォントと表示のずれ：Web フォントの読み込みが表示を止めていないか、画像や埋め込みに大きさを指定しているかを確かめます。FCP と CLS に効きます。
Google は Lighthouse を、パフォーマンスなどの監査を行うオープンソースのツールとし、不合格の監査項目をページ改善の指標として使うよう説明しています（Chrome for Developers「Lighthouse の概要」、最終更新日 2025-06-02）。改善案の一覧を上から全部直すより、悪い指標に関係する項目から手を付けます。
当サイトの計測と改善の記録
当サイト（seoagent.jp）では、トップページの表示速度を Lighthouse で測り、次の2つの改善を行いました。いずれもラボ値で、実際の利用者の値（フィールド データ）ではありません。改善による順位や流入の変化は、まだ測定前のため書きません。
| 起きていたこと | 行ったこと | 結果（Lighthouse モバイル、ラボ値） |
|---|---|---|
| モバイルの Lighthouse が85、LCP が4.1秒 | モバイルではヒーロー画像を読み込まない、800px 幅の画像を追加、画像のキャッシュ期間を延長 | 85 → 100（LCP 約1.5秒） |
| Google タグ（約180KB）がメインスレッドを0.46秒ほど止めていた | 計測の設定は残したまま、タグ本体をページの読み込み後に読む | 92 → 96〜97（LCP 2.7〜3.2秒 → 1.9秒） |
1つ目は「最も大きく表示される画像」、2つ目は「スクリプト」の段階の改善です。2つ目では、計測タグを外すのではなく読み込みの順番を変え、GA4 の計測は続けています。計測タグの設定は「Googleタグマネージャーとは」で説明しています。Lighthouse の値は計測する環境や回数で変わるため、改善の前後は同じ条件で比べ、1回の値だけで判断しないようにしています。
AI検索と表示速度
AIによる概要や AI モードでも、表示速度はページ エクスペリエンスの一部として扱われます。Google は、AI 機能のための特別な最適化は不要としたうえで、引き続き重要な SEO の基本として「ユーザーにとって優れたページ エクスペリエンスを提供します」を挙げています（Google 検索セントラル「AI 機能とウェブサイト」、最終更新日 2025-12-31、2026年10月13日確認）。
AI の回答から自社のページへ移った読者にとっても、表示が遅いページは内容を読む前に離れる原因になります。一方で、表示速度を上げると AI の回答に引用されやすくなる、という説明は Google の公式の資料にはありません。速度は、AI 検索の対策としてではなく、来た人に内容を届けるための基本として整えます。
よくある質問
表示速度は何秒以内がよいですか？
1つの秒数ではなく、指標ごとに目安があります。主な内容が表示されるまで（LCP）は2.5秒以下、最初の表示（FCP）は1.8秒以下が「良好」とされ、操作への応答（INP）は200ミリ秒以下、表示のずれ（CLS）は0.1以下が目安です。実際の利用者の75パーセンタイルで判定します。
PageSpeed Insightsの点数が低いと順位が下がりますか？
点数そのものがランキングに使われるとは説明されていません。Google がランキングに使うと説明しているのは Core Web Vitals で、点数の満点を目指すこと自体は勧めていません。点数はラボの値なので、実際の利用者の LCP・INP・CLS もあわせて確かめます。
スマホとパソコンで速度が違うのはなぜですか？
端末の処理能力と回線の速さが違うためです。Lighthouse のモバイルの計測は、処理の遅い端末と遅い回線を想定した条件で行うため、パソコンより遅く出ます。Search Console の Core Web Vitals レポートもモバイルとパソコンを分けて表示します。
WordPressで速度を上げるには何から始めますか？
まず PageSpeed Insights で悪い指標を確かめます。TTFB が遅ければキャッシュの設定、LCP が遅ければ最初の画面の画像、INP や TBT が悪ければプラグインや計測タグのスクリプトから見ます。プラグインを足すより、使っていないものを減らすほうが効くことがあります。
SEOAGENTでできること
SEOAGENT の「AI検索・表示速度の診断」では、表示速度を、実際の利用者のデータ（CrUX）による判定と、計測ツールの点数に分けて表示します。取得できた実測や計測情報をもとに、改善点を検討できます。Search Console と GA4 を連携すると、記事ごとの検索での表示やクリック、自然検索からの訪問もあわせて確認できます。
できないこと：診断機能のため、テーマ・サーバー・プラグインの設定は自動で変更しません。改善は診断を見てサイト側で行います。順位を保証するものでもありません。表示速度と関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。
参考情報
- Google 検索セントラル：ページ エクスペリエンスと Google 検索結果への影響
- Google 検索セントラル：Core Web Vitals と Google 検索の検索結果について
- web.dev：Web Vitals
- web.dev：最初のバイトまでの時間（TTFB）
- web.dev：First Contentful Paint（FCP）
- web.dev：Largest Contentful Paint（LCP）
- Google for Developers：PageSpeed Insights について
- Search Console ヘルプ：Core Web Vitals レポート
- Chrome for Developers：Lighthouse の概要
- Google 検索セントラル：AI 機能とウェブサイト
