サイトスピードの評価基準や注意点|チェックツールと改善策も紹介
「サイトスピードを改善したいけれど、何から手をつければいいかわからない」とお悩みではないでしょうか。2025年12月のGoogleコアアップデートで、ページエクスペリエンス(Page Experience)信号のランキングへの寄与度がさらに強化され、サイトスピードはこれまで以上に重要な指標となっています。
この記事では、2026年現在のサイトスピード評価の中心となる「Core Web Vitals」を軸に、計測方法・チェックツール・改善方法を最新情報にもとづいて解説します。サイトスピードを改善し、SEO評価と顧客体験の両方を向上させましょう。
目次
サイトスピードとは|Core Web Vitals時代の基本定義

サイトスピードとは、ユーザーがWebサイトにアクセスしてから閲覧・操作できるようになるまでの時間のことです。2026年現在、Googleはこれを「Core Web Vitals(コアウェブバイタル)」という3つの指標で評価しており、SEOランキングと顧客体験の両方に直接影響します。
Core Web Vitalsとは|2026年現在の3つの指標
Core Web Vitalsは、Googleがユーザー体験を定量化するために定めた3つの指標の総称です。2026年4月時点では、以下の3指標で構成されています。
| 指標 | 測る対象 | Good(良好)の基準 |
| LCP | 最大コンテンツの表示時間(読み込み速度) | 2.5秒以下 |
| INP | ユーザー操作への反応速度(応答性) | 200ミリ秒以下 |
| CLS | レイアウトのずれ(視覚的安定性) | 0.1以下 |
2024年3月12日、GoogleはCore Web Vitalsの一つだった「FID(First Input Delay)」を廃止し、「INP(Interaction to Next Paint)」を正式な指標へ昇格させました。FIDがページ最初の操作に対する遅延だけを測っていたのに対し、INPはページ滞在中のすべての操作に対する応答性を測るため、より現実のユーザー体験に近い評価が可能になります。
古い解説記事ではいまだにFIDが登場することがありますが、2026年時点ではINPが正式指標です。改善に取り組む際は必ずINPを基準にしてください。
サイトスピードはどう計測されるのか
PageSpeed Insightsをはじめとする計測ツールは、サイトスピードを「ラボデータ」と「フィールドデータ」の2種類のデータで評価します。
-
- ラボデータ:試験環境でGoogleが収集する推測値。Lighthouseが用いられ、再現性が高く問題の診断に向く
- フィールドデータ:実際のユーザー環境で収集される実測値。Chrome User Experience Report(CrUX)から取得され、Googleのランキング判定にも使用される
どちらか一方ではなく、両方を組み合わせて見ることが大切です。ラボデータで原因を特定し、フィールドデータで実ユーザーへの影響を確認するのが基本的な使い方です。
なぜ今、サイトスピードがこれまで以上に重要なのか
理由は大きく3つあります。
-
- 2025年12月のGoogleコアアップデートでページエクスペリエンス信号の比重がさらに高まったこと。Core Web Vitalsはもはや「同点時のタイブレーカー」ではなく、検索順位を左右する明確な評価軸に位置づけられました。
- 計測対象がChrome以外にも広がったこと。Firefox 144(2025年10月リリース)とSafari 26.2(2025年12月リリース)がINP計測に対応し、Core Web Vitalsはもはや「Chromeユーザーだけの指標」ではなくなりました。あらゆるブラウザで使われる実態がランキングに反映されるようになったわけです。
- ユーザーの離脱と直結すること。Googleが公開した調査では、モバイルサイトの表示に3秒以上かかった場合、ユーザーの約53%が離脱するとされています。表示の遅さは見る前の段階でユーザーを失うリスクを生むため、コンテンツの質と同等以上に重要です。
サイトスピードがビジネスに与える4つの影響

サイトスピードの低下は、直帰率・離脱率の上昇、コンバージョン率の低下、SEO評価の下落、ユーザー満足度の低下という4つの形でビジネスに直接ダメージを与えます。サイトスピードを改善することで、これら4つの課題をまとめて解決できます。
①直帰率・離脱率の上昇
直帰率はユーザーが最初に訪れたページだけで離脱した割合、離脱率は特定のページを最後に閲覧して離れた割合を指します。どちらもページの内容に対する不満だけでなく、サイトスピードの遅さによっても上昇することが知られています。
Googleの調査によると、ページの読み込み時間が1秒から3秒に延びると直帰率は32%上昇し、1秒から7秒に延びると113%も上昇するとされています。ユーザーは数秒のロスにも非常に敏感です。
②コンバージョン率への影響
サイトスピードはコンバージョン率にも直接影響します。Googleが公開している事例では、ページの読み込み速度を半減させるだけで売上が1%向上したことが示されています。ECサイトやリード獲得サイトでは、わずかな速度改善が大きな売上差につながります。
特に商品購入や問い合わせなどのコンバージョンを目的とするランディングページの速度は最重要です。トップページが速くても、肝心のLPが遅ければユーザーは離脱してしまいます。
③Google検索ランキングへの影響
Googleはランキング要素にサイトスピードを組み込んでいます。2025年12月のコアアップデートでこの比重がさらに高まり、Core Web Vitalsの3指標で「Poor(不良)」判定を受けるページは、競合に対してSEO上の不利を負うことになります。
特にINPは2024年3月の正式採用以降、JavaScriptの多いWebサイトで「Needs Improvement」判定を受けるケースが増えています。早めの対応が必要です。
④ユーザー満足度(UX)への影響
サイトスピードの遅さは、それ自体が「使いにくい」「信頼できない」というブランド体験につながります。ユーザーは何かを知りたい、買いたいという目的でサイトを訪れているため、その動機を待ち時間で消耗させるのは大きな機会損失です。
速いサイトは「快適」「信頼できる」という印象を残し、リピート訪問や口コミにつながります。サイトスピードは目に見えにくい指標ですが、ブランド体験の根幹を支える要素です。
サイトスピードチェックの注意点

サイトスピードを測定する際に気を付けておくべき点、事前に理解しておくべき内容をご紹介します。
パソコンとモバイルの結果の違い
サイトスピードを測定する際、モバイルとパソコンでは速度が変わるということに注意が必要です。
パソコンでサイトスピードを測定したときは早くても、モバイルの場合は遅い、またその逆のパターンもあります。
最近ではモバイルサイトが主流になってきており、パソコンのサイトをそのままモバイルに表示させることは少ないです。パソコン、モバイルそれぞれにデザインが崩れないように最適化がなされています。
ページによって変わる速度
サイトのコンテンツ内容によっても各ページ速度は変わります。
速度計測で重要なのは、申し込みや購入といったコンバージョンを目的として作られるランディングページです。トップページだけが速度が速くても、ランディングページが遅ければ意味がありません。
ランディングページの読み込みが遅いと、コンバージョンにつながる前にユーザーが離脱してしまいます。
サイト内の軽いページ(画像などが少ない)と重いページ(動画などが貼ってある)の速度を比較してみてください。
速度測定場所の指定
サイトスピード測定ツールは海外のものが多いです。
海外のツールを使用するときに注意してほしいのが、どこからの閲覧を想定してそくどを計測するのかということです。
配信しているサーバーの拠点がサイトスピードに影響します。
例えば、アメリカのサーバーからの配信と日本のサーバーからの配信では距離の違いからスピードにも差が出てしまいます。そのため、国内向けのWebサイトのスピードを測定するときは、速度測定場所を日本に設定しておきましょう。
ブラウザの設定での体感速度
サイトスピードは閲覧する側の環境によっても変わります。
ユーザーのネット回線が遅ければ、サイト制作者がどれだけ頑張って速度を上げてもユーザー側の体感速度は遅くなります。
ブラウザの設定によってもサイトスピードは変わるため、貯め込んだキャッシュや多すぎる拡張機能などで表示スピードを低下させる要因です。
速度改善をしても、ユーザーから表示が遅いと言われるのであれば、ユーザー側の設定も見直してみましょう。
速度チェックの結果は変わる
サイトスピードは測定時のサーバーの混雑具合や、環境などによって測定結果は毎回変わります。
また、Googleの速度評価指標が変わることもあります。
一度チェックしてよい結果が出ても、しばらくしたら悪くなっていたということもあります。
サイトスピードは時期や時間帯、さまざまな環境の変化で変わるということを覚えておいてください。
サイトスピードの目安|2026年の評価基準

2026年現在、サイトスピードの目安は「Core Web Vitalsの3指標をすべてGood判定に収めること」です。具体的にはLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下が基準となります。PageSpeed Insightsのパフォーマンススコアは、50以上が最低ライン、90以上が目標値です。
Core Web Vitalsの「Good」しきい値の考え方
Core Web Vitalsの判定で重要なのは、「75パーセンタイル」という基準です。これは「全アクセスの75%以上でGoodの基準を満たしていること」を意味します。一部のユーザーだけに快適でも、全体として評価されません。
つまり、遅い回線や古い端末からアクセスしているユーザーの体験も含めて改善する必要があります。フィールドデータを必ず確認しましょう。
PageSpeed Insightsスコアの読み方
PageSpeed Insightsはパフォーマンスを0〜100点でスコア化します。一般的な目安は次のとおりです。
-
- 0〜49点:Poor(不良)。表示速度を低下させている原因の特定と速やかな改善が必要
- 50〜89点:Needs Improvement(改善が必要)。可能な範囲で改善を検討
- 90〜100点:Good(良好)。継続的な維持が重要
ただし、スコアにこだわりすぎず、実際のユーザー体験や収益への影響を合わせて確認することが重要です。詳しくは後述の「サイトスピード改善の心構え」で解説します。
サイトスピードチェックの注意点
サイトスピードを測定する際には、押さえておくべきポイントがいくつかあります。これらを理解していないと、計測結果を誤って解釈してしまう恐れがあります。
-
- パソコンとモバイルで結果が異なる
サイトスピードはモバイルとパソコンでまったく異なる結果が出ることがあります。現在はモバイルファーストが標準であり、Googleの評価もモバイル基準が中心です。両方の結果を確認した上で、特にモバイルの改善を優先しましょう。 - ページごとに速度は変わる
同じサイト内でも、ページのコンテンツによって速度は大きく異なります。特にコンバージョン直結のランディングページや商品詳細ページの速度は最優先で計測すべきです。画像の多いページ、動画が埋め込まれているページなど、重さのバリエーションを意識しましょう。 - 速度測定の地点を指定する
海外製の計測ツールでは、デフォルトの計測地点がアメリカなどになっていることがあります。日本国内向けのサイトであれば、必ず日本(東京など)に設定し直して計測してください。サーバー拠点と計測地点の距離が結果に影響します。 - Chrome以外のブラウザの体験も評価対象に
2026年時点で、FirefoxとSafariはINP計測に対応しており、Core Web VitalsはChrome専用指標ではありません。Safariユーザーが多いiOS環境や、Firefoxユーザーが一定数いるBtoBサイトでは、特定ブラウザだけで最適化していると見落としが生じます。 - 計測結果は毎回変動する
サイトスピードは測定時のサーバー混雑、ネットワーク環境、Googleの評価指標の更新によって結果が変わります。1回の計測値だけで判断せず、複数回・継続的に計測してください。
- パソコンとモバイルで結果が異なる
サイトスピードのチェックツール5選

サイトスピード計測の定番はGoogle公式の「PageSpeed Insights」です。それ以外に、Lighthouse・Pingdom・GTmetrix・WebPageTestがあり、目的や粒度に応じて使い分けます。
PageSpeed Insights
PageSpeed Insights(PSI)はGoogleが提供する無料の計測ツールで、最も広く使われています。Core Web VitalsのスコアやSEO項目のスコアもまとめて確認でき、Core Web VitalsのパフォーマンスはINP(Interaction to Next Paint)ベースの評価ロジックに移行済みです。
使い方は計測したいページのURLを入力するだけで、特別な設定は不要です。自社サイトはもちろん、競合サイトの計測にも使えます。
Lighthouse
LighthouseはChromeに拡張機能として追加できる速度計測ツールです。Chromeベースのブラウザで動作し、PageSpeed Insightsの計測エンジンとしても使用されているため、両者の結果はほぼ一致します。デベロッパーツールに組み込まれているため、開発中の計測に便利です。
Pingdom Website Speed Test
Pingdom Website Speed Testはブラウザ上で計測できるツールの一つです。デフォルトの計測地点がアメリカに設定されているため、日本(東京)に変更してから使用してください。ドメインのスピードやコンテンツ容量の内訳も確認できます。
GTmetrix
GTmetrixは、LighthouseやWeb Vitalsの計測指標をわかりやすく可視化するツールです。改善案の提示が直感的なため、PageSpeed InsightsやLighthouseの結果を読み解くのが難しいと感じる方に適しています。テストサーバーの位置を変更するにはユーザー登録が必要です。
WebPageTest
WebPageTestは、読み込み時間、レンダリング速度、ネットワーク使用量といった詳細なパフォーマンスデータを取得できる、上級者向けの無料ツールです。Lighthouseとの統合や競合サイトとの比較測定にも対応しており、ページ速度のボトルネックを詳しく特定したい場合に適しています。
PageSpeed Insightsの使い方4ステップ

PageSpeed Insightsの使い方は4ステップで完結します。①URLを入力し、②モバイル・デスクトップそれぞれの結果を確認、③フィールドデータ(実ユーザー環境)で実態を把握、④ラボデータ(診断用)で具体的な改善点を特定します。
ステップ1|計測したいURLを入力
PageSpeed Insightsにアクセスし、検索窓に計測したいページのURLを入力します。1回に計測できるのは1ページのみです。どのページを計測すべきか迷う場合は、Googleアナリティクスで「離脱率の高いページ」「直帰率の高いページ」「コンバージョン率の低いページ」を優先してください。
ステップ2|パフォーマンス・SEOなどのスコアを確認
「分析」をクリックすると、「携帯電話」「デスクトップ」のタブで結果が表示されます。結果は「パフォーマンス」「ユーザー補助」「おすすめの方法」「SEO」の4カテゴリに分かれ、それぞれが0〜100点でスコア化されます。各スコアの下に具体的な改善アドバイスが表示されるので、それをもとに対策を進めましょう。
ステップ3|「実際のユーザー環境で評価する」(フィールドデータ)の見方
「実際のユーザー環境で評価する」セクションでは、過去28日間のフィールドデータをもとに計測されたサイトスピードが表示されます。ここに表示される数値こそ、Googleが実際にランキング判定で参照するデータです。
確認できる主な指標は以下の通りです。
| 指標名 | 意味 | 概要 | 目安 |
| LCP | 最大コンテンツの表示時間 | ページのメインコンテンツが表示されるまでの時間 | 2.5秒以下 |
| INP | ユーザー操作に対する反応時間 | クリック・タップ・キー入力などすべての操作に対する応答時間 | 200ms以下 |
| CLS | ページの視覚的な安定性 | 予期しないレイアウト崩れがどのくらい生じるか | 0.1以下 |
| FCP | 最初のコンテンツの表示時間 | ページにアクセスしてから最初のコンテンツが表示されるまでの時間 | 1.8秒以下 |
| TTFB | サーバーの初期応答時間 | ブラウザがサーバーから最初の1バイトを受け取るまでの時間 | 0.8秒以下 |
※2024年3月にFIDからINPへ置き換わりました。古い解説で「FID」と書かれている箇所は、現在はすべてINPと読み替えてください。
ステップ4|「パフォーマンスの問題を診断する」(ラボデータ)の見方
「パフォーマンスの問題を診断する」セクションでは、シミュレーション環境下で収集されたラボデータが表示されます。実際のユーザー環境は反映されませんが、問題の原因を特定するために役立ちます。フィールドデータと数値が異なる場合があるので、両方を見比べて判断しましょう。
| 指標名 | 意味 | 概要 | 目安 |
| FCP | 最初のコンテンツの表示時間 | ページにアクセスしてから最初のコンテンツが表示されるまでの時間 | 1.8秒以下 |
| Speed Index | コンテンツが取り込まれるまでの時間 | ページの読み込み中にコンテンツがどのくらいで視覚的に表示されるか | 3.4秒以下 |
| TBT | 操作への応答がブロックされた時間 | コンテンツ表示後、ユーザーが操作可能になるまでにブロックされた時間 | 200ms以下 |
| CLS | ページの視覚的な安定性 | 予期しないレイアウトのずれがどのくらい生じるか | 0.1以下 |
サイトスピードの改善方法6つ

サイトスピード改善の主な手法は、画像最適化・リソース軽量化・JavaScript最適化・CSS最適化・キャッシュ活用・サーバー(TTFB)改善の6つです。優先順位は、TTFB → 画像(LCP対策)→ JavaScript(INP対策)→ レイアウト(CLS対策)の順に取り組むことで、Core Web Vitalsの改善効果を最大化できます。
①画像の最適化(LCP対策の本丸)
画像はLCPの主要因となるケースが多く、Webサイト全体の50%以上で「LCP要素=画像」と言われています。まず取り組むべきはここです。
-
- WebPやAVIFなどの次世代フォーマットに変換する。JPEGやPNGより25〜35%ほど軽量
- <picture>要素やsrcset属性でレスポンシブ画像を配信し、デバイスに合ったサイズだけを送る
- loading=”lazy”属性で、画面外の画像を遅延読み込みする
- width・height属性を必ず指定し、レイアウトのずれ(CLS)を防ぐ
これらは比較的低コストで実装でき、効果も大きい施策です。
②不要なリソースの軽量化
HTMLやCSSに残った不要なコード、コメント、改行はサイトスピードを低下させます。未使用のCSSルール、未使用のJavaScript関数、過剰なホワイトスペースを削除し、ビルドツールでミニファイ(圧縮)しましょう。Tree Shaking(未使用コードの自動削除)を導入することで、手作業なしにコードを最適な状態に保てます。
③JavaScriptの最適化(INP対策の本丸)
INPの改善で最も効果が大きいのがJavaScriptの最適化です。重いJavaScriptがメインスレッドを長時間占有すると、ユーザー操作への応答が遅れて「カクつく」体験につながります。
-
- scriptタグにdefer属性やasync属性を付けて、HTMLの解析をブロックしないようにする
- コード分割(Code Splitting)で、必要なときに必要なスクリプトだけを読み込む
- 第三者スクリプト(広告、解析タグなど)を見直し、不要なものを削除または遅延読み込みする
- 重い計算処理はWeb Workersに移して、メインスレッドの負荷を下げる
特にWordPressや各種ページビルダーを使ったサイトでは、JavaScriptが肥大化しがちです。INPで「Needs Improvement」が出ている場合は、まずここを見直してください。
④CSSの最適化
CSSもサイトスピードに大きく影響します。読み込みをブロックしないために、以下のポイントを実践しましょう。
-
- ファーストビューに必要なCSS(Critical CSS)のみをHTMLにインライン化し、残りは外部ファイルで非同期読み込みする
- 使われていないCSSルールを削除する
- CSSファイルをミニファイし、ファイルサイズを縮小する
⑤キャッシュの活用
キャッシュとは、Webページのデータを一時的に保存しておく仕組みのことです。同じページに再アクセスした際、保存済みデータを読み込むため、ページの表示が高速化します。ブラウザキャッシュとCDNキャッシュの2層構成が標準的なアプローチであり、再訪問ユーザーの表示速度を確実に向上させることができます。
⑥サーバー応答時間(TTFB)の改善
TTFB(Time to First Byte)はサーバーがリクエストを受け取ってから最初の1バイトを返すまでの時間で、すべての改善施策の土台となる指標です。ここが遅いと、他をどれだけ最適化しても効果が薄れてしまいます。
-
- CDN(Cloudflare、Fastlyなど)を導入し、ユーザーに近いエッジサーバーから配信する
- サーバーサイドキャッシュを有効にする
- ホスティングプランやサーバースペックを見直し、より高性能な環境に移行する
TTFBが800ミリ秒を大きく超えている場合は、他の改善より先にサーバー応答時間の改善に取り組むことを推奨します。
サイトスピード改善で押さえるべき注意点

サイトスピード改善を進める際は、「ネットワーク環境による測定値の揺らぎ」「スコアへの反映にはタイムラグがある」「すべての指標を改善する必要はない」といった前提を正しく理解しておくことが重要です。
計測値はネットワーク環境で変動する
サイトスピードの測定結果はネットワーク環境に大きく左右されます。1回だけの計測では正確な状況を把握できないため、時間帯や日を変えて複数回測定することを推奨します。
公開直後のサイトはフィールドデータが出ないことがある
Webサイトを公開して間もない場合や、アクセス数が少ないサイトでは、Chrome User Experience Reportに十分なデータが蓄積されておらず、フィールドデータが表示されないことがあります。この場合はラボデータを参考に改善を進めましょう。
スコアと実際の体感が乖離することもある
PageSpeed Insightsのスコアが50以下でも、実際のユーザー体験が良好なケースがあります。一方で、スコアが高くても実ユーザー環境では遅く感じられることもあります。スコアはあくまで指標の一つとして捉え、フィールドデータや実機での体感も合わせて総合的に判断することが重要です。Speed Kitのような計測・自動化ツールを活用することで、スコアだけでなく実際のパフォーマンス改善と収益への影響を可視化できます。
すべての改善項目を実施する必要はない
PageSpeed Insightsは多数の改善項目を提示しますが、すべてを実装するには膨大な時間と専門技術が必要です。LCP・INP・CLSへの寄与度が高い項目から優先して対処しましょう。画像最適化やJavaScriptの遅延読み込みは効果が大きく、Speed Kitのような自動化ツールで対応できる項目です。
フィールドデータは1週間ごとに更新される
PageSpeed Insightsのフィールドデータはリアルタイムでは更新されず、Google公式ドキュメントによると毎週更新されます。改善を加えてもすぐに数値へ反映されないため、再計測は1週間以上空けてから行いましょう。
サイトスピード改善で陥りがちな3つの誤解と心構え

サイトスピード改善で重要なのは、「100点満点を目指さない」「他のSEO要素とのバランスを取る」「継続的にモニタリングする」という考え方を持つことです。
100点満点は目指さない/優先順位を決める
PageSpeed Insightsで100点を取ることはゴールではありません。スコアを50から80に上げる場合と、95から100に上げる場合では、投入する工数に対するROIがまったく異なります。Core Web Vitalsの3指標がGood判定に入ることを目標に、現実的な範囲で改善しましょう。
他のSEO要素とのバランスを取る
SEOにはサイトスピード以外にも、コンテンツの質、内部リンク構造、被リンク、E-E-A-Tなど多数の要素があります。サイトスピードだけに固執せず、各要素の優先順位をバランスよく判断することが、SEO効果を最大化する確実な方法です。
継続的にモニタリングする
サイトスピード改善は一度きりの施策ではありません。コンテンツの追加、プラグインの更新、新機能の実装など、サイトの変化に応じてパフォーマンスは変動します。Search ConsoleのCore Web Vitalsレポートや実ユーザー監視(RUM)ツールで定期的にチェックし、リグレッション(性能後退)を早期に検知する仕組みを整えましょう。
まとめ|Core Web Vitalsを軸に顧客体験とSEOを同時に改善しよう

2026年のサイトスピード改善は、「Core Web Vitalsへの対応」と「ビジネス指標(CVR)の改善」を両立させることがゴールです。LCP・INP・CLSの3指標をフィールドデータで確認し、Poor判定を受けている指標から優先的に手を入れていくのが王道です。
2026年4月時点では、ページエクスペリエンス信号の重みは増しており、Core Web Vitalsへの対応は競合との差別化要因にもなっています。本記事で紹介した6つの改善方法と心構えを参考に、自社サイトの現状を点検してみてください。
本メディアを運営する株式会社ギャプライズでは、Webマーケティング、サイト改善、サイト集客など、さまざまな課題に対応するサービスを展開しています。ABテストツールやサイトパフォーマンスに関するご相談も承っておりますので、ぜひお気軽にお問い合わせください。
今本 たかひろ/MarTechLab編集長
料理人→旅人→店舗ビジネスオーナー→BPO企業にてBtoBマーケティング支援チームのPLを4年半経験し、2023年2月よりギャプライズへジョイン。フグを捌くのもBtoBマーケティングを整えるのも根本は同じだという思考回路のため、根っこは料理人のままです。家では猫2匹の下僕。虎党でビール党。
