ページ速度（表示速度）とは、ユーザーがページにアクセスしてからコンテンツが表示され、操作できるようになるまでの速さのことです。Googleはこれを Core Web Vitals（LCP・INP・CLS）の3指標で評価しており、合格基準を満たすページは検索順位・UX・CVR（コンバージョン率）の面で有利になります。2026年現在、表示速度は「コンテンツの質」を前提とした品質シグナルの一つとして機能しています。
「ページ速度ってSEOにどう関係するの？」「うちのサイトは速いの？遅いの？」と悩む方は多いはずです。本記事では、当社が臨床検査技師の精度管理（QC：正常範囲を決め、異常を検知し、是正する）の考え方をSEMに転用した視点で、表示速度の「目安（合格基準）」「測定方法」「指標別の改善手順」を順に解説します。
この記事でわかること
- 目安はCWVの3指標： LCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下が「良好」の合格ラインです。
- 測定はGoogle公式ツールで完結： PageSpeed InsightsとSearch Consoleで、現状を無料で数値化できます。
- 改善は指標別に是正： 画像のWebP化（LCP）、JavaScript削減（INP）、要素サイズの明示（CLS）が王道です。
表示速度はSEOにどう影響するか
結論から言うと、2026年において表示速度は「コンテンツの関連性が同程度のページが並んだとき、どちらを上位にするか」を分ける品質シグナルとして働きます。Googleは、優れたページエクスペリエンス（表示速度を含む）はランキング要素であるものの、最も重要なのは関連性の高い優れたコンテンツであり、関連性が同程度なら体験の優れたページが上位に出やすい、という立場を公式に示しています（出典：Google Search Central｜ページエクスペリエンス）。
注意したいのは、かつての「ページエクスペリエンス」という独立したランキングシステムは2023年に廃止されている点です。Core Web Vitalsは現在も品質評価に寄与するシグナルとして残っていますが、単独で順位を決める要因ではありません（アイダイム分析）。つまり、速度だけを上げても劇的に順位が上がるわけではなく、「合格と出ているなら過度な対策は不要、不合格と出ているなら是正が必要」というのが実務的なスタンスです。不合格レベルに遅いサイトは、UXを著しく下げてしまうため、まずそこを直すべきです。
速度がビジネス指標に直結する根拠
表示速度の遅延は、SEO以前に直帰率・離脱率・CVRへ直接響きます。古いデータですが、Think with Googleの調査では、読み込み時間が1秒から3秒に伸びると直帰率は32%増加し、1秒から5秒で90%、1秒から10秒では123%増加すると報告されています（2017年・出典：Think with Google）。
CVRへの影響はさらに顕著です。Portentの調査（2022年）によると、1秒で読み込まれるB2Bサイトは、5秒かかるサイトに比べてコンバージョン率が3倍、10秒かかるサイトに比べて5倍高いという結果が出ています（出典：Portent）。速度はSEOの一要素であると同時に、問い合わせ・売上に直結する経営指標でもあるわけです。
直帰率・離脱率は表示速度以外の要因（コンテンツ構成や導線）でも変動します。速度を直しても改善しない場合は、別の原因を疑う必要があります。詳しくは「直帰率とは？SEOへの影響と改善する方法を詳しく解説」で解説しています。
（自社検証）当社では実際に、PageSpeed Insightsのスコアが35だったサイトを90まで引き上げた経験があります。この水準まで来ると、表示の体感が明確に変わり、UX起因の離脱を抑えられます。この結果から言えるのは、低スコアのサイトほど改善の伸びしろが大きく、優先的に着手する価値があるということです。
ここまでを踏まえ、まず「自社サイトが合格圏にあるのか」を判断する基準を押さえておきましょう。
Q. SEOにおいて表示速度はどの程度重要ですか？
A. 最優先はコンテンツの関連性・品質であり、表示速度はそれを前提とした品質シグナルの一つです。関連性が同程度のページが競合した際に、体験の優れたページが上位に出やすくなる「tiebreaker（同点決勝）」的な役割と理解すると実務に合います。ただし、不合格レベルに遅い場合はUXを大きく損ない、離脱やCVR低下に直結するため、是正が必要です。
「では合格・不合格はどの数値で決まるのか」を、次の章で具体的に確認します。
ページ速度の目安｜Core Web Vitals（LCP・INP・CLS）の合格基準
ページ速度の「目安」は、感覚的な秒数ではなく Core Web Vitals の3指標で定義されています。臨床検査でいう「基準値（正常範囲）」にあたるのがこの合格基準です。2026年現在の「良好」ラインは次の通りです（出典：web.dev｜Web Vitals）。
3指標の意味と合格基準を整理すると、次のようになります。
| 指標 | 測るもの | 良好（合格） | 要改善 | 不良 |
|---|---|---|---|---|
| LCP | 表示速度（最大要素の描画） | 2.5秒以下 | 2.5〜4.0秒 | 4.0秒超 |
| INP | 操作への応答性 | 200ミリ秒以下 | 200〜500ミリ秒 | 500ミリ秒超 |
| CLS | 視覚的な安定性（レイアウトのズレ） | 0.1以下 | 0.1〜0.25 | 0.25超 |
いずれの指標も、全アクセスの75パーセンタイル（上位75%が基準内）で「良好」と判定される点が重要です。一部の高速な環境だけでなく、低速な回線や端末を含めた多数派が基準を満たす必要があります。
注意点として、INP（Interaction to Next Paint）は2024年3月12日に旧指標のFID（First Input Delay）を正式に置き換えたものです（出典：Google Search Central Blog）。古いツールや記事がいまだFIDを基準にしている場合は、情報が更新されていないと判断できます。INPはクリックやタップなどの操作全体の応答時間を見るため、JavaScriptが重いサイトで悪化しやすく、3指標のなかで最も合格率が低い傾向にあります。
なお、2026年に入ってから複数のSEO媒体が「Core Web Vitalsがサイト全体で総合的に評価される傾向が強まった」と観測報告していますが、これはトラッキングツール由来の観測であり、Google公式の確認はありません（※確認中）。確定情報として扱わず、「自サイトの遅い下層ページも放置しない」という実務上の方針に落とし込むのが安全です（アイダイム分析）。
Q. ページの表示速度の目安は？
A. Core Web Vitalsの「良好」基準が目安です。LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下（いずれも全アクセスの75パーセンタイルで判定）を満たせば合格圏です。漠然と「3秒以内」と覚えるより、この3指標で判断するほうが正確です。
Q. Core Web Vitalsの3つの指標は何ですか？
A. LCP（表示速度＝最大コンテンツの描画時間）、INP（操作への応答性。2024年にFIDから移行）、CLS（視覚的安定性＝レイアウトのズレ）の3つです。それぞれ読み込み・操作・表示崩れという別々の体験を測っています。
基準値がわかったら、次は自社サイトが今どの位置にあるのかを測定します。
表示速度の測定方法｜計測ツールと使い分け
精度管理でいう「異常検知」のステップです。基準値（正常範囲）に対して、自社サイトが合格圏にあるかを数値で確認します。Googleが提供する無料ツールだけで実用上は完結します。
PageSpeed Insights は、URLを入力するだけでスコアと改善提案を表示します。0〜100のスコアに加え、実際のChromeユーザーから収集された体験データ（フィールドデータ）に基づくCore Web Vitalsの合否が確認できます。重要なのは、スコア（ラボデータ）とCore Web Vitalsの合否（フィールドデータ）は別物だという点です。スコアが高くても実ユーザーデータで不合格、という乖離は珍しくありません。判断はフィールドデータを優先します。
Google Search Console の「ウェブに関する主な指標」レポートでは、サイト全体のLCP・INP・CLSのステータス（不良／改善が必要／良好）を、似たページ群ごとにまとめて確認できます。1ページずつではなく、サイト全体の弱点を俯瞰したいときに有効です。
Lighthouse（Google Chromeの開発者ツールに内蔵）は、手元のブラウザでローカルにテストできます。改修中のページを公開前に確認する用途に向いています。より詳細に、世界各地の回線環境やTTFB（サーバーの初期応答時間）まで分析したい場合は WebPageTest（無料プランあり）も使えます。
かつて推奨されていたGoogleの「Test My Site」は、すでにサービスが終了しています。古い記事で紹介されていても、現在は利用できません。
測定したスコアと実際のユーザー行動を突き合わせると、改善の優先度がより明確になります。アクセス解析と組み合わせた見方は「GA4の使い方完全ガイド｜基本設定から分析レポートの見方まで図解」で解説しています。
Q. サイトの表示速度はどうやって測定しますか？
A. 基本はGoogleの無料ツール2つです。PageSpeed Insightsで個別ページのスコアと実ユーザーデータの合否を確認し、Search Consoleの「ウェブに関する主な指標」でサイト全体の弱点を俯瞰します。なお「Test My Site」は提供終了しているため使えません。
数値が把握できたら、計測結果に応じて是正に進みます。
📌 自社サイトの速度や改善の優先順位を専門家に診断してほしい方はこちら
→ SEO無料相談で失敗しない！プロに聞く診断内容と業者の選び方
ページ速度が遅くなる主な原因
是正の前に、なぜ遅くなるのか（ボトルネック）を切り分けます。原因は大きく4つに整理できます。
第一に 画像・動画のサイズです。最も多い原因で、特にファーストビューの大きな画像はLCPを直接悪化させます。第二に サーバーの応答速度（TTFB）です。サーバーが最初のデータを返すまでが遅いと、その後の処理がすべて後ろ倒しになります。Googleは、サーバー応答が遅いとGooglebotがクロール速度を落とし、インデックスにも影響しうると説明しています（出典：Google Search Central｜クロールバジェット）。
第三に レンダリングを妨げるCSS／JavaScriptです。描画前に読み込みが必要なコードが多いと、表示開始が遅れます。第四に サードパーティスクリプト（広告タグ・タグマネージャー・各種計測タグ）です。これらはメインスレッドを占有し、INPを悪化させる主因になります。INPの改善が難しいサイトは、まずこの外部スクリプトの量を見直すのが定石です。
原因ごとに効く対策は異なります。次の章で指標別に整理します。
表示速度の改善方法｜Core Web Vitals別の是正手順
精度管理でいう「是正」のステップです。やみくもに対策するのではなく、測定で見つかった不合格指標に対して、効く施策を当てます。改善は一度で終わるものではなく、是正後に再計測して効果を確認するループで進めます。
指標別の主な施策と難易度を整理すると、次の通りです。
| 改善施策 | 主な対象指標 | 難易度 |
|---|---|---|
| 画像のWebP化・圧縮・リサイズ | LCP | 低 |
| 画像の遅延読み込み／ファーストビュー画像のpreload | LCP | 中 |
| CSS／JavaScriptの軽量化・不要コード削除 | LCP・INP | 中 |
| サードパーティスクリプトの削減・遅延実行 | INP | 中〜高 |
| ブラウザキャッシュの活用 | LCP | 低 |
| 画像・動画・広告枠にwidth/heightを明示 | CLS | 低 |
| サーバー増強・CDN導入（TTFB改善） | LCP | 高 |
LCP（表示速度）の是正は、効果が大きく着手しやすい順に、画像のWebP化・圧縮、ファーストビュー画像のpreload指定、ブラウザキャッシュの活用、CDN導入が王道です。画像最適化の詳細は「画像SEOとは？ポイントと注意点を詳しく解説」、フォーマット変換は「次世代フォーマットwebpのSEOへの影響について｜変換方法も紹介」で解説しています。
INP（応答性）の是正は、サードパーティスクリプトの削減と、JavaScriptがメインスレッドを長時間占有しないようにすることが中心です。最も合格しにくい指標のため、計測タグや外部ツールを「本当に全ページに必要か」から見直すと効果が出やすくなります。
CLS（視覚安定性）の是正は、画像・動画・iframe・広告枠にwidth/heightを明示するのが基本です。読み込み中に後からサイズが確定して表示がガクッとズレる現象を防ぎます。比較的低コストで効きます。
なお、かつて速度改善策として推奨されたAMPは、現在は必須ではなくなっています。古い記事の指示に従ってAMPを新規導入する必要はありません。
（アイダイム分析）測定で「不合格」レベルに遅いサイトは、個別の施策を積み上げるより、サイトを設計から作り直したほうが結果的に速いケースが少なくありません。実際にあるクライアント案件では、表示に3秒前後かかっていたサイトを部分改修ではなく全面リニューアルで作り直し、別物と言えるレベルまで体験を改善しました。是正の範囲は「どこまで遅いか」で判断するのが現実的です。技術的な改修の全体像は「テクニカルSEOの基本｜効果的な対策を解説」も参考にしてください。
Q. 表示速度を上げるにはどうすればいいですか？
A. 不合格になっている指標に対して施策を当てます。LCPなら画像のWebP化・圧縮・遅延読み込み、INPならJavaScriptとサードパーティスクリプトの削減、CLSなら画像や広告枠へのサイズ指定が基本です。やみくもに全部やるより、測定で弱点を特定してから是正するほうが効率的です。
Q. INPを改善するには？
A. INPは操作への応答性を測る指標で、JavaScriptの重さに左右されます。広告タグやタグマネージャーなどサードパーティスクリプトを削減し、メインスレッドを長く占有する処理を分割・遅延させるのが中心です。3指標のなかで最も合格率が低いため、優先的に見直す価値があります。
是正後は必ず再計測し、基準値内に収まったかを確認します。この一連の流れを社内のルーティンに組み込むことが、安定した速度管理につながります。
📌 速度改善やテクニカルSEOを外部に依頼するか迷っている方はこちら
→ SEO外注で失敗しない！費用・選び方・成功戦略を徹底解説
AI検索（LLMO）時代の表示速度
検索の入口がAIへ広がるなかで、表示速度はAI検索への対応という観点でも意味を持ち始めています。一般的な方向性として、サーバー応答が速く、静的なHTMLで素早く情報を返せるページは、AIクローラーが内容を取得・引用しやすいと指摘されています。逆に、クライアントサイドレンダリングに過度に依存し初期表示が遅いページは、取得時に不利になりやすいと言われています（※確認中）。
LLMO（AI検索最適化）の実務でも、結論を冒頭に置き、構造化データで意味を明示し、軽量に速く返す、という設計はSEOと共通します。表示速度の最適化は、人間のユーザーだけでなくAIクローラーにとっても読みやすいページづくりの一部だと捉えると、投資の優先度を判断しやすくなります。検索体験そのものの変化については「「ググる」からAIエージェントへ｜Google検索が変わる時代の集客対策【2026】」で解説しています。
まとめ｜QCループで速度を管理する
ページ速度とSEOの関係は、2026年現在「Core Web Vitals（LCP・INP・CLS）という基準値に対して、自社が合格圏にあるかどうか」で考えるのが正確です。コンテンツの関連性が最優先である点は変わりませんが、不合格レベルの遅さはUXとCVRを大きく損ないます。
進め方は、臨床検査の精度管理と同じループで考えると迷いません。①基準値（LCP2.5秒・INP200ミリ秒・CLS0.1）を知る → ②PageSpeed InsightsとSearch Consoleで測定して異常を検知する → ③不合格指標に効く施策で是正する → ④再計測して基準内に収まったか確認する。このサイクルを定期的に回すことで、速度を「直して終わり」ではなく「維持できる状態」にできます。
参考情報
- Google Search Central｜ページエクスペリエンス: https://developers.google.com/search/docs/appearance/page-experience
- web.dev｜Web Vitals: https://web.dev/articles/vitals
- Google Search Central Blog｜INP導入: https://developers.google.com/search/blog/2024/03/core-web-vitals-inp
- Google Search Central｜クロールバジェットの管理: https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
- Think with Google｜モバイルページ速度ベンチマーク（2017）: https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/
- Portent｜Site Speed and Conversion（2022）: https://portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm