ページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つ

表示速度はランキング要素です。ただし、順位を動かす力は小さいものです。Googleの公式ヘルプは「Core Web Vitals が使用されます」と明記していますが、同じページで「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう」とも書いています。

「ブログが重い」「表示が遅い」と感じて調べた場合も、直す前に順位への効き方と見る順番を知っておくと、手を付ける場所を選びやすくなります。 個人ブログなら、速度に手をつける前に確かめることが3つあります。表示回数・掲載順位・クリック率です。この3つで「今の自分に速度が効く段階か」が分かります。

その3つは Search Console のCSVに全部入っています。先に自分の数字を見てから読むほうが早いかもしれません。

Core Web Vitals とは何か(現行は3指標)

Core Web Vitals とは、ページの読み込みの速さ・操作への反応の速さ・表示の安定性を、実際に訪れたユーザーの体験として測る3つの指標です。Search Console のヘルプでは、しきい値が次のように定められています。

古い解説記事にはFID(First Input Delay)が載っていますが、FIDはINPに置き換わりました。web.dev の説明では、INPは2024年に正式なCore Web Vitalsの指標になっています。今から直すなら、見るのはINPです。INPの行に問題が出たときの確かめ方はINPの改善とは？サーチコンソールで「改善が必要」と出たら遅い操作を探すにまとめました。

LCP が遅いと出たときは、web.dev の「Largest Contentful Paint を最適化する」が、LCP の合計時間を「Time to First Byte（TTFB）」「リソース読み込みの遅延」「リソースの読み込み時間」「要素のレンダリングの遅延」の4つのサブパートに分けて見る方法を書いています(「すべてのページの LCP 値は、この 4 つのサブパートに分類できます。」)。どの部分に時間がかかっているかで手を付ける場所が変わる、と私は読んでいます。PageSpeed InsightsでLCPの要素と4つの内訳を確かめる手順はLCPの改善とは？PageSpeed Insightsで4つの内訳を確かめるに書きました。

Googleが書いていること、書いていないこと

公式ヘルプ(2026年10月21日に、9月25日更新の日本語版で確認)から、そのまま引ける文はこの4つです。

• 「Google のランキング システムでは Core Web Vitals が使用されます。」
• 「Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」
• 「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう。」
• 「Google 検索は、ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています。ただし多くの場合、検索語句に一致するヘルプフル コンテンツが多数存在するため、その中で検索結果でのランキングを上げるには、優れたページ エクスペリエンスを実現していることが重要になります。」

日本語のSEO記事でよく見る「同程度に関連性のあるページが並んだときの決め手になる」という言い回しは、このページには見当たりませんでした(2026年8月19日に日本語版・英語版の両方を開いて確認しています)。近いのは4つ目の文です。

しかも4つ目は、英語版と日本語版で強さが違います。英語版は「can contribute to success in Search, in such cases(そうした場合には成功に貢献しうる)」で、日本語版は「重要になります」です。訳の強いほうだけを根拠にしないほうが安全です。

なぜ速度は「効きにくい」のか(理由は2つある)

速度を直しても順位が動かなかった、という話には理由が2つあります。よく語られるのは1つ目ですが、個人ブログで効いているのは2つ目のほうです。

1つ目は、順序の問題です。Googleはまず関連性で並べます。検索結果にほとんど出ていないページは、速くしても出るようにはなりません。速度は「並んだ後」に働く要素なので、並ぶ前の段階では出番がないということです。

2つ目は、測定の問題です。ここがあまり書かれていません。Search Console の Core Web Vitals レポートは、CrUX(Chrome ユーザー エクスペリエンス レポート)の実ユーザーデータをもとにしています。ヘルプには、レポートが「データがありません」になる条件がこう書かれています。

「Search Console のプロパティがまだ新しいか、CrUX レポートで利用できるデータが不足しているため、選択したデバイスタイプ(パソコンまたはモバイル)に関して有意義な情報を示すことができません」

PageSpeed Insights 側にも同じ趣旨の記述があります。実ユーザーのデータが足りないページはサイト全体(オリジン)の値に切り替わり、それも足りなければ実ユーザーのデータは表示されません。

つまりアクセスが少ないブログでは、速度を直しても「測られていない」ことがあります。直した効果を自分で確認する手段がない状態で、プラグインやサーバー移転にお金と時間を投じることになります。

個人ブログでの優先順位(速度は最後のほう)

自分がどの段階にいるかは、Search Console の表示回数・掲載順位・クリック率で分かります。このサイトの判定も同じ3つで切り分けています。

3行目の見当をつけるための数字を1つ出します。8位の期待クリック率は1.52%です(AI Overview の影響を織り込んだ値。織り込む前の実測は1.78%)。ここが期待の半分にとどまっているページは、表示1,000回あたり7.6クリックを取りこぼしている計算になります。

7.6クリックは、速度改善で取り返せる幅より大きいことがほとんどです。同じ1時間を使うなら、タイトルのほうが先に返ってきます。

「そもそも順位が上がらない」の原因が何層に分かれるかはブログの順位が上がらない理由に、順位帯ごとに効く手が違う話は検索順位を上げる方法は順位帯で変わるにまとめてあります。記事に貼った YouTube の埋め込みがページを重くすることと、軽くする方法はブログにYouTubeを埋め込むとSEOに効く？貼る前に決めることと速度の影響に書きました。

なおモバイルユーザビリティのレポートは2023年12月1日に廃止されました。 Search Console に残っているのは Core Web Vitals と HTTPS の2つだけです(サーチコンソールのモバイルユーザビリティは廃止されました)。

測り方: PageSpeed Insights と Search Console は別物

速度の話がこじれる原因の多くは、2つのツールが違うものを見ていることにあります。

ラボデータは「制御された環境で収集される」もので、公式ドキュメントには問題のデバッグに役立つと書かれています。実際のユーザー体験を捉えるのはフィールドデータ(実ユーザーデータ)のほうだ、とも書かれています。点数だけを追いかけると、後者を見ないまま作業することになります。

2つの数字が食い違うのも正常です。Search Console のヘルプ自身が「PageSpeed Insights の特定の URL の統計情報は、Core Web Vitals のグループの結果と一致しないことがあります」と説明しています。個別URLの状態を知りたいときは、Search Console のレポートではなく個別のテストを使うのが公式の案内です。

表示速度で迷ったとき、次に読む記事は？状況別に

Core Web Vitals とその周辺の指標で、引っかかりやすい状況別の行き先です。

よくある質問

Core Web Vitals を直せば検索順位は上がりますか

上がるとは限りません。公式ヘルプは「Google のランキング システムでは Core Web Vitals が使用されます」と書く一方で、「レポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません」とも書いています。関連性が先で、速度はその後に働きます。改善する価値があるのは、関連性・順位・クリック率の側でやることが残っていない場合です。

PageSpeed Insights の点数が低いです。今すぐ直すべきですか

先に表示回数を見てください。表示回数が100回に届かないページは、そもそもCrUXに実ユーザーのデータが溜まらず、Core Web Vitals として測定されていないことがあります。直しても、直った証拠が出ません。その段階で効くのは、インデックスの確認・キーワードの見直し・記事を増やすことです。詳しくは表示回数が少ないブログで、リライトする記事をどう決めるかに書きました。点数を見て画像を軽くするか迷っているなら、どこまでやれば十分かをブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるにまとめています。点数の色や上下2つの欄が何を指すのかはPageSpeed Insightsの見方は？下の点数より上の欄を先に見るに書きました。

ブログが重い・表示が遅いと感じたら、何から確かめればいいですか

体感だけで決めず、まず PageSpeed Insights にそのページのURLを入れて、どこが重いのかを見るところから始めるのがよいと私は考えています。上の表のとおり、PageSpeed Insights はラボデータで1ページの原因を掘るのに向いています。原因が大きな画像なら、どこまで軽くすれば十分かをブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるに書きました。ただ、読者のために軽くすることと、順位のために直すことは分けて考えてください。順位の面では、この記事の優先順位の表のとおり、表示回数・掲載順位・クリック率を先に見ます。PageSpeed Insights の下の欄(Lighthouse)に並ぶ項目の名前の読み方と、どれを読むかの決め方は「レンダリングをブロックしているリクエスト」とは？PageSpeedの分析情報に書きました。

LCP や CLS を改善するには、何から見ればいいですか

LCP は、上で書いた4つのサブパートのどこに時間がかかっているかを見るところからだと私は考えています。web.dev のページは、PageSpeed Insights の Lighthouse の「Largest Contentful Paint 要素」の診断で、LCP を構成するタイミングの内訳が表示されると書いています。ただ、これは古い版の Lighthouse での名前です。Chrome の開発者向けサイトの「Lighthouse 13 の新機能」の置き換えの表では、largest-contentful-paint-element の監査は lcp-phases-insight という分析情報に置き換わっていて、今の分析情報のページの名前では「LCP の内訳」がこれにあたると私は読んでいます(今の PageSpeed Insights がどの版の Lighthouse を使っているかと、実際の画面の字は確かめていません)。web.dev の同じページには「場合によっては、ある部分に適用された最適化によって LCP が改善されず、節約された時間が別の部分に移動するだけになることがあります。」ともあります。LCP の要素が画像ならブログの画像圧縮はSEOに効く？を、表示中のずれ(CLS)が画像の width と height の書き忘れから来ていそうならブログの画像サイズは何px？を見てください。順位の面での優先順位は、上の表のとおり変わりません。新旧の項目の名前の対応は「レンダリングをブロックしているリクエスト」とは？PageSpeedの分析情報に書きました。

FID はもう見なくていいのですか

現行の3指標はLCP・INP・CLSです。web.dev の説明では、INPは2024年に正式なCore Web Vitalsの指標になり、FIDの役割を引き継いでいます。Search Console の Core Web Vitals レポートも、LCP・INP・CLS の3つで判定しています。古い記事を参考にするときは、指標名が置き換わっている点に注意してください。

Search Console に「データがありません」と出るのはエラーですか

エラーではありません。ヘルプには、プロパティが新しい場合か、CrUXレポートで利用できるデータが不足している場合にこの表示になる、と書かれています。個人ブログでは後者が多いはずです。個別のURLだけ確かめたいなら、PageSpeed Insights などのテストを使うようヘルプが案内しています。 データが足りないときにレポートがサイト全体(オリジン)にまとめ直す仕組みと、表の読み方はウェブに関する主な指標レポートの見方は？に書きました。

まとめ

• Core Web Vitals とは、読み込み・反応・表示の安定性を実ユーザーの体験として測る3指標で、現行はLCP・INP・CLS。FIDはINPに置き換わっている
• 公式ヘルプは「Google のランキング システムでは Core Web Vitals が使用されます。」と書く一方、「Google 検索の検索結果で上位に表示されることが保証されるわけではありません」「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう」とも書いている。ランキング要素ではあるが、関連性の前には出ない
• 「同程度に関連性のあるページが並んだときの決め手」という言い回しは公式のページ エクスペリエンスのページには見当たらなかった。近い一文はあるが、英語版は「貢献しうる」・日本語版は「重要になります」で強さが違う
• 個人ブログで速度が効きにくい理由は2つ。①関連性が先で順番が来ない ②実ユーザーデータが足りず、そもそも測られていない
• 見る順番は表示回数 → 掲載順位 → クリック率 → 速度。表示100回未満なら速度は無関係、11位以降なら中身、4〜10位でクリック率が低いならタイトルが先
• PageSpeed Insights はラボと実ユーザーデータの両方・個別URL単位、Search Console は実ユーザーデータのみ・URLグループ単位。数字が一致しないのは正常

ここから先は、私が作ったツールの話です。

速度の数字より先に、リライトレーダーに記事のURLを入れて、見出しや本文の直す点を見てみてください。表示回数・順位・クリック率から見直す記事を決めるなら、Search Consoleのデータを入れると、順番まで出ます。URLの診断で送るのは入れたURLだけで、本文は保存しません。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位4.0〜20.5位のページから手を入れる候補を順に並べます。判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで3記事分(候補が4件以上のときだけご案内)、生成の期限は購入から90日間で、月額課金はありません。CSVはブラウザの中で読み、送るのは候補ページのURLと、診断カードを出すときの狙いキーワード・順位・表示回数・CTRだけです。

⚠️ URLの診断は本文だけを読み、順位・表示回数・CTRは使いません(それらを使うのはSearch Consoleのデータを入れたときです)。表示速度もCore Web Vitalsも見ないので、速度の診断にはPageSpeed Insightsなどを使ってください。