ページの読み込み速度とは、ユーザーがURLにアクセスしてから、ページの主要な内容が表示され、操作できるようになるまでの速さです。GoogleはこれをCore Web Vitals（LCP・INP・CLS）で評価し、良好の基準をLCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下としています。ただし判定に使うのはツールのスコアではなく、実際のChromeユーザーの実測データです。
当社に来る速度の相談は「PageSpeed Insightsが赤いと言われた」という形が多く、改善策の一覧をそのまま実行しても数値が動かない場合があります。基準値の確認、見る数字の選び方、原因の切り分け、誰が直すのかを、当社の実測とGoogleの公式資料を分けて示しながら順に扱います。
この記事でわかること
- 目安はLCP 2.5秒： INP 200ミリ秒以下・CLS 0.1以下を合わせた3指標が合格ラインで、判定は実ユーザーの75パーセンタイルで行われます。
- スコアと合否は別物： 当社が同日に測ったクライアント5社のうち4社は、Googleが順位判定に使う実測データそのものが存在しませんでした。
- 画像から入ると外す： 画像の対策を終えても数値が1秒も動かず、真因が日本語Webフォントだった案件があります。
ページの読み込み速度はSEOにどう影響するか
関連性が同じくらいのページが並んだとき、どちらを上位にするかを分ける材料として働きます。
速度が単独で順位を決めるという説明と、順位には関係ないという説明が、どちらも流通しています。公式の資料では、速度は評価に使われるが単独の決定要因ではない、という位置づけが一貫しています。
順位への影響は「同点決勝」。関連性が最優先という公式の立場
Googleは単独のシグナルではないと明記しており、体験が劣っても関連性が高いページは上位に出ます。
【公式仕様】Google Search Centralのページエクスペリエンスの解説には「There is no single signal.」と書かれています。あわせて「Google Search always seeks to show the most relevant content, even if the page experience is sub-par.」とも記載されており、体験が劣っていても関連性が高い内容は表示されるという立場です（出典：Google Search Central｜ページエクスペリエンス）。
同じ資料には「Core Web Vitals are used by our ranking systems.」ともあり、無視してよいとは言っていません。一方でCore Web Vitals以外のページエクスペリエンスの要素は「don’t directly help your website rank higher in search results」と明記され、効く部分と効かない部分が分けて説明されています。
（アイダイム分析）実務上の扱いは「合格していないなら直す、合格しているなら追加で磨かない」に落ち着きます。関連性の高い内容が先にある前提で、そこが弱いまま速度を磨いても順位は動きません。
3指標すべて合格しているサイトはモバイルで48%しかない
合格が多数派ではありません。CrUXに載っているサイトのうち、モバイルで3指標すべて良好なのは48%です。
【公式仕様】HTTP ArchiveのWeb Almanac 2025は、2025年7月のCrUXデータで、3指標すべてが「良好」だったのはモバイル48%・デスクトップ56%と報告しています。指標別ではLCPがモバイル62%、INPが77%、CLSが81%です。モバイルの通過率は2023年の36%、2024年の44%から改善しています（出典：Web Almanac 2025 Performance）。
分母には注意が必要です。CrUXに収録されるのは、公開されていて発見可能で、かつ一定の訪問者数があるページとサイトだけです（後述）。48%は「Webサイト全体の48%」ではなく「CrUXに載っているサイトの48%」で、個別ページの話へも広げられません。
速度が本当に効くのは順位ではなく問い合わせ到達率
順位よりも、フォームまでたどり着ける人の数に効きます。当社は速度をSEOの話として扱っていません。
（実務知見）2026年9月に運用を引き継いだBtoB企業のサイトで、モバイルの表示に9.5秒以上かかる状態を確認しました。このとき社内の優先順位表に書いた判断は「速度は順位要因としては弱くても、9.5秒台は問い合わせ到達率の問題であり、SEOの話にしてはいけない」です。順位が動くかで優先度を決めると、この状態を後回しにしてしまいます。
離脱や直帰は速度以外でも動くので、直しても改善しない場合は別の原因を疑います。見方は「直帰率とは？GA4での確認方法・業種別目安・SEOへの影響と改善策【2026年版】」で解説しています。
Q. 表示速度を改善すれば検索順位は上がりますか。
A. 合格していない状態から合格へ移す改善なら効く場合がありますが、すでに合格しているページのスコアを上げても順位は動きにくいです。Googleは速度を単独の決定要因ではないと明記しており、優先されるのは内容の関連性です。合格しているのに順位が低い場合、原因は速度の外にあります。
順位への効き方が整理できたところで、次は合格・不合格を分ける数値そのものを確認します。
ページ速度の目安｜Core Web Vitals（LCP・INP・CLS）の合格基準
LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下が良好の基準です。感覚的な秒数では決まりません。
臨床検査の精度管理でいう「基準値（正常範囲）」に当たるのが、この合格基準です。基準値が無いと異常を判定できません。「なんとなく遅い」では直す対象が決まりません。
3指標の意味と、良好・要改善・不良の境目を並べると次のようになります。
| 指標 | 測るもの | 良好 | 要改善 | 不良 |
|---|---|---|---|---|
| LCP | 表示速度（最大要素の描画） | 2.5秒以下 | 2.5〜4.0秒 | 4.0秒超 |
| INP | 操作への応答性 | 200ミリ秒以下 | 200〜500ミリ秒 | 500ミリ秒超 |
| CLS | 視覚的な安定性（レイアウトのズレ） | 0.1以下 | 0.1〜0.25 | 0.25超 |
境目の数値は2026年9月時点で変わっていません（出典：web.dev｜Web Vitals）。
ページ速度・表示速度・読み込み速度・サイト速度は同じものを指す
呼び方が違うだけで、指しているのは同じ体験です。英語ではsite speedやpage speedと書かれます。
検索する側は「ページ速度」「表示速度」「ページの読み込み速度」「サイト速度」「ホームページ速度」と、いろいろな言い方をします。別の指標ではなく、どの言い方でも行き着く基準はCore Web Vitalsの3指標です。
ひとつだけ区別しておく語があります。「サイト速度」「ホームページ速度」は全体の話に聞こえますが、判定はページ単位が基本で、データが足りない場合にサイト単位へ束ねられます。
理想は何秒か｜LCP 2.5秒が基準、体感の目標は2秒台前半
理想はLCP 2.5秒以下です。ただし75パーセンタイルで測るため、目標は2秒台前半に置くと安全です。
「3秒以内」という覚え方はGoogleの基準ではありません。基準はLCP 2.5秒で、しかも上位75%の閲覧が収まる必要があります。平均で2.5秒でも、遅い端末や回線の閲覧が足を引っぱると不合格になります。
（アイダイム分析）そのため実務では2.0〜2.3秒を目標に置きます。基準ぴったりを狙うと、広告タグの追加やプラグインの増加ですぐ線をまたぎます。基準値の内側に余白を取るのは、精度管理で許容範囲を狭めに設定するのと同じ発想です。
なおINPとCLSに「秒数」という言い方は合いません。INPは操作から応答までのミリ秒、CLSはズレの量を表す数値です。3指標をまとめて「◯秒」とは言えません。
判定は75パーセンタイル。モバイルとデスクトップは別に見る
上位75%の閲覧が基準内に収まる必要があり、モバイルとデスクトップは別々に判定されます。
【公式仕様】web.devのWeb Vitalsの解説は、3指標の目標を「75パーセンタイルのページ読み込みで、モバイルとデスクトップに分けて」満たすことを推奨しています（出典：web.dev｜Web Vitals）。
【実測】当社が2026年9月9日にクライアントサイト5社のトップページを同日に測った結果、5社すべてでモバイルのスコアがデスクトップより22〜34ポイント低く出ました。デスクトップだけを見ると全社が良好の範囲に見えます。
モバイル側の対処は「モバイル最適化とは？SEOへの影響とCore Web Vitals改善手順を解説【2026年最新】」で扱っています。
Q. ページの読み込み速度の理想は何秒ですか。
A. LCPが2.5秒以下であれば合格です。ただし判定は上位75%の閲覧が基準内に収まるかで行われるため、余白を取って2秒台前半を目標にすると線をまたぎにくくなります。「3秒以内」という覚え方はGoogleの基準ではありません。
基準が確認できたところで、その基準をめぐって広まっている誤解を1つ片づけておきます。
「2026年3月にLCPが2.0秒へ変わった」は公式には確認できない
2026年9月時点で、しきい値は2.5秒のままです。変更を告げる公式の記載は見つかりません。
複数の英語のSEOメディアが「2026年3月のGoogleの発表でLCPの良好が2.5秒から2.0秒へ引き下げられた」「INPがLCP・CLSと同じ重みの主要ランキングシグナルへ昇格した」と書いています。当社はこれを裏づける一次情報を確認できませんでした。
確認した範囲は3つです。1つ目、Google Search Centralのブログで2026年3月に公開された投稿は4本あり、内容はGooglebotのクロールの解説、クローラーのIPレンジファイルの移転、Search Central Liveのカナダ開催、同アジア太平洋の開催案内で、Core Web Vitalsに触れたものはありません。2つ目、LCPの公式ドキュメントは2025年9月4日の更新時点で「2.5 seconds」と記載しています（出典：web.dev｜LCP）。3つ目、web.devのWeb Vitalsの解説には、安定版のCore Web Vitalsは年1回を超えて変更されず、変更する場合は指標の公式ドキュメントとchangelogで明示すると書かれています。
（アイダイム分析）当社はこの記事で基準を2.5秒として扱います。ただし「その情報は誤りだ」と断定はしません。Googleが将来しきい値を見直す可能性はあり、そのときは公式ドキュメントとchangelogに載ります。新しい数値を見たら、その2か所を見に行けば足ります。
指標の重み付けはGoogleが公開していないため、「INPがLCPと同じ重みになった」という説明も裏づけられません。実務で言えるのは、INPは3指標のうちJavaScriptの重さに最も左右されるという性質までです。
表示速度の測定方法｜スコア（ラボ値）と合否（フィールド値）は別物
PageSpeed Insightsは1画面に2種類の数字を出します。順位判定に使われるのは上段だけです。
上段が実際のChromeユーザーの実測（フィールド値）で、下段の0〜100のスコアが1回の測定結果（ラボ値）です。ラボ値は低速な端末と回線を仮定して測るため、閲覧者が速い環境中心のサイトでは実態よりかなり悪く出ます。混同すると、直す必要のないものを直すことになります。
なお画面遷移をJavaScriptで行うサイト（SPA）では遷移後の指標を測れませんでしたが、Chrome 151から既定で有効になっています（出典：Chrome for Developers｜Soft navigations）。
Search Consoleの「ウェブに関する主な指標」レポートも元データは同じ実測です。使い分けは、個別ページがPageSpeed Insights、サイト全体の弱点がSearch Console、公開前の確認が開発者ツール内蔵のLighthouseです。ツールの見方は「pagespeed insights（ページスピードインサイト） 改善方法をSEOのプロが解説！」で扱っています。
データが足りないサイトは、そもそもCrUXに載っていない
訪問者数が一定に届かないページとサイトは、Googleの実測データセットに収録されません。
【公式仕様】CrUXの収録条件は2つです。1つは公開されていて発見可能であること（200以外のステータス、X-Robots-Tag: noindex、noindex のmetaタグは対象外）。もう1つは「A page is determined to be sufficiently popular if it has a minimum number of visitors.」で、最小の訪問者数は非公表ですが、統計的な分布に自信が持てるサンプル数を確保するために設定されていると説明されています。この最小値はページとサイトで同じです（出典：Chrome for Developers｜CrUX methodology）。
Search Consoleのヘルプも同じ趣旨で「If a URL group does not have a minimum amount of reporting data for both LCP and CLS, the URL is omitted from the report.」と書かれ、その場合は上位のサイト単位のグループへ束ねられます（出典：Search Console ヘルプ｜ウェブに関する主な指標レポート）。
つまり、Search Consoleに自社のページが出てこないのは故障ではありません。データが集まるだけのアクセスがまだ無い、という状態です。
当社が5社を同日に測った結果｜4社はフィールドデータが無かった
クライアント5社のトップページを同日に測り、4社で実測データが取得できませんでした。
【実測】2026年9月9日、PageSpeed Insights APIで、当社が運用または検収に入っているクライアントサイト5社のトップページを、モバイルとデスクトップの両方、ラボ値とフィールド値の両方で取得しました。社名は伏せます。
| サイト | 端末 | ラボ値のスコア | ラボ値のLCP | フィールド値（実ユーザー） |
|---|---|---|---|---|
| A社 | モバイル／デスクトップ | 58／88 | 8.3秒／1.6秒 | データなし |
| B社 | モバイル／デスクトップ | 54／90 | 9.0秒／1.1秒 | データなし |
| C社 | モバイル／デスクトップ | 66／99 | 5.7秒／1.0秒 | データなし |
| D社 | モバイル／デスクトップ | 59／88 | 9.0秒／1.9秒 | データなし |
| E社 | モバイル／デスクトップ | 37／71 | 12.5秒／2.2秒 | LCP 0.95秒・INP 138ミリ秒・CLS 0＝3指標すべて良好 |
読み取れることが3つあります。1つ目、4社はフィールドデータがページ単位もサイト単位も存在せず、Googleが順位判定に使うデータそのものがありません。2つ目、E社はラボ値では最も低い37点・LCP 12.5秒・CLS 0.291でしたが、実ユーザーの実測では3指標すべて良好でした。3つ目、5社すべてでモバイルがデスクトップより低く出ています。
（アイダイム分析）E社の乖離は珍しい事故ではありません。ラボ値は低速な端末と回線を仮定した1回の測定で、実際の閲覧者はそれより速い環境が中心だったということです。ラボ値は「どこが重いか」を探すには有効で、「直すべきか」を決める材料には向きません。
フィールドデータが出ていないサイトは、速度を後回しにしていい
当社は、実測データが出ていないサイトの速度改善を後回しにします。判定材料が存在しないためです。
（実務知見）判断の順番はこうです。フィールドデータが出ていないのは、CrUXの収録条件を満たす訪問者数がまだ無いということです。Googleが順位判定に使うデータが無い状態なので、速度で順位が動く余地も小さいと当社は見ています。そして一定のアクセスが付けばデータは出ます。SEOの運用を始めれば、当社の経験ではその水準に届きます。届いてから対処すれば間に合うと考えています。
そこにすら届かないサイトには、速度より先に手を入れる対象があります。検索に拾われていない、検索されている問いに答えるページが無い、という状態です。順番を逆にすると、誰も見ていないページを速くする作業に予算を使います。
（アイダイム分析）例外は2つあります。1つは公開前のサイトで、公開してから遅さを直すより、公開前に土台を直すほうが安く済みます。もう1つは、フィールドデータが無くてもラボ値で明らかに遅い状態（モバイルの表示に8秒以上かかるなど）で、これは順位ではなく問い合わせ到達率の問題として扱います。
アクセスの実態と突き合わせる手順は「GA4の使い方完全ガイド｜基本設定から分析レポートの見方まで図解」も参考にしてください。
Q. PageSpeed Insightsのスコアが低いのに「良好」と出るのはなぜですか。
A. 別のデータを見ているためです。0〜100のスコアは低速な端末と回線を仮定した1回の測定（ラボ値）で、「良好」の判定は実際のChromeユーザーから集めた実測（フィールド値）です。順位判定に使われるのは後者なので、スコアが低くても「良好」なら合格しています。
見る数字が決まったら、次は遅い原因を切り分けます。
ページの読み込み速度が遅くなる原因
描画を止めているものを名指しできれば直せます。原因は画像・フォント・サーバー・スクリプトの4つです。
原因を特定せずに改善策の一覧を上から実行すると、数値が動かないまま工数だけが消えます。症状から原因へ降りる対応を先に整理します。
| 症状 | 疑う原因 | 最初に見る数字 |
|---|---|---|
| 最初の画面が出るまで長い | 描画を妨げるCSS・Webフォント | レンダリングブロックの削減余地（ミリ秒） |
| 画面は出るが大きな画像が遅れて出る | ファーストビューの画像サイズ | LCPの対象要素と画像のバイト数 |
| 何も表示されない時間が長い | サーバーの初期応答 | TTFB（サーバー応答時間） |
| タップしても反応が遅れる | JavaScript・広告タグ・計測タグ | メインスレッドの合計ブロック時間 |
| 読んでいる途中で表示がズレる | サイズ未指定の画像・広告枠 | CLSと、ズレを起こした要素 |
同じ「遅い」でも、最初に見る数字が違います。この表の右列を先に取るのが、遠回りしない順番です。
画像と動画（最も多いが、直しても動かないことがある）
ファーストビューの大きな画像はLCPを直接悪化させます。ただし直しても数値が動かない場合があります。
画像はLCPの対象要素になりやすく、圧縮・リサイズ・次世代フォーマットへの変換が効きます。ただしLCPの対象要素が画像でない場合や、画像より前に描画を止めているものがある場合は、軽くしても数値は動きません。PageSpeed InsightsのLCPの対象要素の表示を先に見て、何が最大要素になっているかを確認してから着手します。
手順は「画像SEOとは？Google画像検索で上位表示する7つの対策と手順」と「WebPのSEO効果とは？表示速度と変換方法【2026年版】」で扱っています。
日本語Webフォント（ウェイトを複数読むと合計が膨らむ）
日本語フォントは収録文字が多いため、ウェイトを3種類読むと合計が重くなります。
欧文フォントと違い、日本語フォントは収録する文字数が桁違いに多くなります。太さ（ウェイト）ごとにファイルが分かれるため、標準・太字・極太の3種類を読むと合計が膨らみます。読み込み方が同期だと、フォントが揃うまで文字が描画されません。
【実測】2026年9月に検収へ入ったBtoB企業のサイトでは、Google Fontsの日本語フォントをウェイト3種・サブセットなしで同期読み込みしていました。CSSだけで90キロバイト、フォントファイルが78・25・20・20キロバイトで、Lighthouseはレンダリングブロックの削減余地として6,000ミリ秒を出していました。同じサイトのサーバー応答は10ミリ秒でした。
（アイダイム分析）サーバー応答が10ミリ秒であれば、遅いのはサーバーでもレンタルサーバーの契約プランでもありません。この切り分けができていないと、サーバーの増強という費用のかかる対策に進んでしまいます。
サーバー応答（TTFB）とクロールへの影響
サーバーが最初のデータを返すまでが遅いと、その後の処理がすべて後ろへずれます。
TTFBが遅い分だけLCPも後ろへ動きます。原因はサーバーの性能、データベースの重さ、プラグインの処理、キャッシュの不在です。
【公式仕様】Googleは、サーバーの応答が遅くなるとGooglebotがクロールの速度を落とすと説明しています（出典：Google Search Central｜クロール バジェット管理）。表示だけでなくインデックスにも影響します。
レンダリングを妨げるCSS・JavaScriptとサードパーティスクリプト
描画の前に読み込みが必要なコードが多いと、表示が始まる時点そのものが後ろへずれます。
CSSとJavaScriptは、読み込みと解析が終わるまで描画を止める場合があります。これがレンダリングブロックで、Lighthouseは削減できるミリ秒数を出します。前項のフォントもこの系統です。
広告タグ、タグマネージャー、ヒートマップ、チャットツールなどのサードパーティスクリプトは、メインスレッドを占有してINPを悪化させます。INPが合格しないサイトは、ここが「本当に全ページに必要か」を見直すと効きやすくなります。点検項目は「テクニカルSEOとは？基礎と実践チェックリスト【2026年版】」にまとめています。
原因の型が分かったところで、実際に切り分けを外した例を1つ挙げます。
画像をWebP化しても1秒も動かなかった案件で、真因はフォントだった
画像の対策を終えても数値は動かず、描画を止めていたのは日本語Webフォントでした。
【実測】2026年9月2日、当社が検収に入ったBtoB企業のサイト（社名と業種は伏せます）で、トップページのモバイルの表示に9.5秒、デスクトップで1.8秒かかっていることを確認しました。スコアはモバイル57点、デスクトップ84点です。商品ページでも同じ傾向でした。
このとき制作会社へ渡した項目は、画像への幅と高さの指定、遅延読み込み、商品画像の次世代フォーマット化、静的ファイルのキャッシュ設定です。改善策の一覧としては標準的な内容です。
【実測】3日後の2026年9月5日に再計測しました。画像への幅と高さの指定と次世代フォーマット化は完了していましたが、モバイルのLCPは9.5秒で、1秒も動いていませんでした。スコアも57点のままです。
原因はレンダリングブロックの内訳を見て特定できました。Lighthouseが6,000ミリ秒の削減余地を出しており、その中身が日本語Webフォントの同期読み込みでした。サーバー応答は10ミリ秒だったので、サーバーもテーマも容疑から外れます。
（実務知見）この案件で学べるのは、改善策の順番ではなく症状から原因へ降りる手順が要るということです。測る、内訳を見る、描画を止めているものを名指しする、という3段を踏まずに施策の一覧から入ると、正しい作業をしても数値が動きません。画像の対策は無駄ではありませんが、それだけでは合格ラインに届きませんでした。
（アイダイム分析）当社も一度同じ取り違えをしています。2026年9月に別のクライアントの施策の優先順位を検討した際、ラボ値のLCPを検索クリック減の主な原因として位置づけかけました。外部レビューで「LCPはラボ値であり、Core Web Vitalsの評価軸は実ユーザーデータなので、クリック減の主因と位置づける根拠はない」と指摘され、この位置づけを取り下げています。ラボ値とフィールド値の混同は、日常的に起きます。
表示速度の改善方法｜Core Web Vitals別の是正手順
合格していない指標に対して、効く施策だけを当てます。全部を並べて着手する必要はありません。
精度管理でいう「是正」の段です。一度で終わらせず、直したら再計測して基準内に入ったかを確認する繰り返しになります。
指標別の施策と、難易度、実務で誰が手を動かすかを並べると次のようになります。
| 施策 | 主な対象指標 | 難易度 | 実務で手を動かす側 |
|---|---|---|---|
| 画像の圧縮・リサイズ・次世代フォーマット化 | LCP | 低 | 制作会社 |
| Webフォントのウェイト削減・サブセット化・非同期化 | LCP | 中 | 制作会社 |
| 画像の遅延読み込み・ファーストビュー画像の先読み指定 | LCP | 中 | 制作会社 |
| CSS・JavaScriptの軽量化と不要コードの削除 | LCP・INP | 中 | 制作会社 |
| サードパーティスクリプトの削減・遅延実行 | INP | 中〜高 | SEO会社と制作会社 |
| 画像・動画・広告枠への幅と高さの指定 | CLS | 低 | 制作会社 |
| ブラウザキャッシュと静的ファイルのキャッシュ設定 | LCP | 低 | 制作会社かサーバー管理者 |
| サーバー増強・CDN導入 | LCP | 高 | サーバー管理者 |
実際に手を動かすのは制作会社側が多くなります。誰に何を渡すかは次の章で扱います。
LCPの是正
LCPは、画像の軽量化と、描画を止めている読み込みを外すことで下がります。
着手は削減余地の大きいものからです。レンダリングブロックが数千ミリ秒出ているなら画像より先で、フォントのウェイトを減らす、サブセットを使う、非同期にするといった対応が効きます。
画像側は圧縮とリサイズ、次世代フォーマットへの変換、ファーストビュー画像の先読み指定が中心です。下部の画像は遅延読み込みにしますが、LCPの対象要素を遅延読み込みにすると逆に悪化します。
INPの是正
INPは、JavaScriptとサードパーティスクリプトを減らすと下がります。
3指標のうちJavaScriptの重さに最も左右されるのがINPです。処理がメインスレッドを長く占有すると、タップへの応答が遅れます。
実務では計測タグと外部ツールの棚卸しから入ります。全ページに要るか、遅延実行できるか、同じ目的のタグが重複していないかを見ます。長い処理は分割して間に描画の機会を作ります。
CLSの是正
CLSは、画像・動画・iframe・広告枠にwidthとheightを書けば収まります。
読み込みの途中でサイズが確定して表示がずれる現象を防ぐのが目的です。領域を先に確保すれば、後から中身が入っても位置が動きません。
Webフォントの切り替えでも文字の大きさや行送りが変わってずれます。読み込み方を見直すと、LCPとCLSが同時に落ち着くことがあります。
合格ラインに届かなくても、改善した分だけ成果は動く
合格ラインに届かない改善でも成果は動きます。Googleが公開した事例がそれを示しています。
【公式仕様】Googleがweb.devで公開している事例では、LCPを8.3秒から5.7秒へ31%改善した結果、売上が8%、リード到達率が15%、カート到達率が11%伸びたと報告されています（出典：web.dev｜Vodafone case study）。
注目したいのは、改善後の5.7秒が合格ライン2.5秒に届いていない点です。合格していない状態のままでも、遅さが減った分だけ成果が動いています。
（アイダイム分析）この事例は2021年の公開で、対象は海外の大規模なEC事業者です。日本の中小企業へ数字をそのまま当てられません。読み取るべきは伸び率ではなく、「合格ラインに届かないから意味がない」が成り立たないという点です。当社側で速度改善だけを実施して順位や問い合わせ数が動いた実測はまだなく、取れた時点で記事へ足します。
改善する側の話が済んだので、次は誰がその作業をするのかを整理します。
速度改善は誰の仕事か｜制作会社・SEO会社・サーバーの切り分け
画像とフォントとキャッシュは制作会社、計測と優先順位付けはSEO会社の担当になります。
速度が放置される理由は、技術的な難しさとは別にあります。担当が決まっていないことです。制作会社は納品が仕事、SEO会社は順位が仕事なので、その間にある「公開後のテンプレートの改修」が誰の担当か曖昧になります。
（実務知見）2026年9月にBtoB企業のサイトの検収を出したときは、残課題10項目を制作会社4項目、当社3項目、両者3項目に割りました。画像の対策、テンプレートの改修、キャッシュ設定は制作会社、構造化データの整理と計測は当社、タイトルや説明文とフォームの設定は両者です。速度の項目は制作会社側に偏ります。
（実務知見）伝え方も変えています。「PageSpeed Insightsのスコアを上げてください」という依頼はしません。スコアは相手が着手できる指示にならないためです。代わりに「描画を止めている読み込みを外してください」「このフォントのウェイトを1つにしてください」と作業の単位で渡します。クライアントから「スコアを上げてほしい」と言われた場合も、スコアに付き合わず、やってもらうことを具体で置き直してから話します。
AI検索時代の表示速度
AI検索向けの速度基準は公表されていません。設計はSEOと同じで、軽く速く返すことに尽きます。
結論を先に置き、構造を明示し、軽く速く返す設計は、人間の読者に向けた設計とAIクローラーに向けた設計で共通します。速度のためだけに別の作業が発生する関係にはなっていません。
（アイダイム分析）速度改善は、AI検索対策という枠で予算を分けて考える対象ではありません。順位のためでもAI検索のためでも、やることは同じです。検索の入口の変化は「【図解】「ググる」からAIエージェントへ｜Google検索が変わる時代の集客対策【2026】」で扱っています。
まとめ｜測る数字を決めてからQCループを回す
見る数字をフィールド値に固定してから、測る・原因を特定する・直す・再計測するを回します。
判断の順番でまとめます。基準値はLCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下で、判定は上位75%の閲覧、モバイルとデスクトップは別に見ます。測る段ではスコア（ラボ値）と合否（フィールド値）を分け、フィールドデータが出ていないサイトは速度より先に着手する対象があります。原因は症状から入って最初に見る数字を決め、画像より先にレンダリングブロックの内訳とサーバー応答を見ます。是正は合格していない指標だけに当て、誰が手を動かすかを作業の単位で渡します。再計測はしますが、フィールド値は28日ぶんの実測で動くので直した当日には変わりません。
（アイダイム分析）速度を「直して終わり」にせず「維持できる状態」にするには、この4段を定期的に回すのが現実的です。基準値を決め、異常を検知し、是正し、再計測する流れは、臨床検査の精度管理と同じ構造です。
ページの読み込み速度のよくある質問
本編で扱いきれなかった周辺の疑問をまとめます。
Q. Search ConsoleとPageSpeed Insightsで数値が食い違うのはなぜですか。
A. 集計の単位と時点が違うためです。どちらも元データはCrUXで、CrUXは28日の移動平均として集計されています（出典：Chrome for Developers｜CrUX API）。PageSpeed Insightsは指定したURL（データが足りなければサイト単位）、Search Consoleは似たページをまとめたグループ単位で出すため、同じ日に見ても一致しません。
Q. ページエクスペリエンスとCore Web Vitalsは同じものですか。
A. 同じではありません。Core Web Vitalsはページエクスペリエンスに含まれる一部で、Googleは「Core Web Vitalsはランキングシステムに使われている」と書く一方、それ以外のページエクスペリエンスの要素は順位を直接上げるものではないと明記しています。速度以外の体験を整えても順位には効かない、という線がここで引かれています。
Q. サーバーを変えれば表示速度は速くなりますか。
A. サーバーの初期応答（TTFB）が遅い場合にかぎり効きます。応答が数十ミリ秒で返っているなら、遅い原因はサーバーの外にあるので増強しても数値は動きません。当社が2026年9月に実測した案件では応答が10ミリ秒で、真因は日本語Webフォントの読み込み方でした。
参考情報
- Google Search Central｜ページエクスペリエンス: https://developers.google.com/search/docs/appearance/page-experience
- Google Search Central｜大規模なサイトのクロール バジェット管理: https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
- web.dev｜Web Vitals: https://web.dev/articles/vitals
- web.dev｜Largest Contentful Paint (LCP): https://web.dev/articles/lcp
- web.dev｜Interaction to Next Paint is officially a Core Web Vital: https://web.dev/blog/inp-cwv-launch
- web.dev｜Vodafone case study: https://web.dev/case-studies/vodafone
- Chrome for Developers｜CrUX methodology: https://developer.chrome.com/docs/crux/methodology
- Chrome for Developers｜CrUX API（28日の移動平均）: https://developer.chrome.com/docs/crux/api
- Chrome for Developers｜Soft navigations: https://developer.chrome.com/docs/web-platform/soft-navigations-experiment
- Search Console ヘルプ｜ウェブに関する主な指標レポート: https://support.google.com/webmasters/answer/9205520
- Web Almanac 2025｜Performance（HTTP Archive）: https://almanac.httparchive.org/en/2025/performance
