サイトスピード計測ツールおすすめ5選｜CWV合格基準と改善方法

サイトスピード（ページ表示速度）の良し悪しは、体感ではほとんど判断できません。「なんとなく重い気がする」を客観的な数値に変えるには、計測ツールが必須です。

この記事の結論を先に示します。まずは PageSpeed Insights でURLを入力して計測し、Core Web Vitals（コアウェブバイタル）の3指標 で合否を判定し、5つの改善アクション で対処する。この「計測 → 判定 → 改善」の3ステップが基本動線です。

なお2024年3月12日、Googleは Core Web Vitals の応答性指標を FID（First Input Delay）から INP（Interaction to Next Paint）へ置き換え ました。古い記事のままFIDを目標に改善していると、現在のGoogleの評価基準とズレが生じます。本記事はINP（200ミリ秒以下が良好）を含む2026年時点の最新基準で、計測ツールの選び方・スコアの読み方・改善方法を、マーケティング担当者や制作会社が実務で使える粒度まで一気通貫で解説します。

サイトスピードがSEOとUXに与える影響(2026年最新版)

👉 このパートをまとめると！

• サイトスピードは2018年からモバイル検索の順位要因
• 2021年にCore Web Vitalsがページ体験シグナルに採用
• 表示が遅いほど直帰率が跳ね上がり機会損失に直結

サイトスピードとは、ユーザーがページにアクセスしてからコンテンツが表示され、操作できるようになるまでの読み込み速度を指します。このサイトスピードは、検索順位（SEO）とユーザー体験（UX）の両面に直接影響する、Web集客の土台となる指標です。

検索ランキング要因としてのサイトスピード

Googleは段階的に、サイトスピードを検索順位の評価対象へと組み込んできました。時系列で押さえておくべき公式アップデートは次の3つです。

• 2018年「Speed Update」：Google検索セントラルの発表により、モバイル検索の順位決定にページ速度が判断材料として加わりました。極端に遅いページが対象で、2018年7月から適用されています。
• 2021年「ページ エクスペリエンス アップデート」：Core Web Vitals（当時はLCP・FID・CLS）がページ体験シグナルとしてランキングに反映されるようになりました。
• 2024年3月12日「INPへの置換」：応答性指標が FID（First Input Delay）から INP（Interaction to Next Paint）へ置き換えられ、FIDは指標から廃止されました。

つまり、サイトスピードは2018年以降「あれば有利」ではなく「検索順位の評価対象」として扱われており、2026年時点では Core Web Vitals の3指標（LCP/INP/CLS）が合否判定の中心になっています。

表示が遅いほど離脱率は跳ね上がる

サイトスピードはUXの観点でも見過ごせません。Googleのモバイル速度に関する調査をまとめた Think with Google によれば、ページの読み込み時間が1秒から3秒に延びると直帰率はおよそ32%上昇し、1秒から5秒では約90%、1秒から10秒では約123%上昇するとされています。

具体的なシチュエーションで考えてみます。ECサイトAでは、商品ページの表示が4秒かかっていれば、ファーストビューが出る前に多くの訪問者が離脱します。一方、メディアサイトBでは、記事が表示されるまで体感で待たされると、本文が読まれる前にブラウザバックされてしまいます。せっかく広告費や制作費をかけて流入を獲得しても、表示速度が遅いだけで売上やPVに繋がる前に取りこぼしているのです。

モバイルファーストで評価される時代

現在のWeb閲覧の多くはスマートフォン経由であり、Googleもモバイル版のページを基準にインデックスと評価を行う「モバイルファーストインデックス」を採用しています。そのため、計測ツールで速度を測るときも、まずモバイルのスコアを優先して確認することが重要です。PCでは十分速くても、モバイルでは回線やCPU性能の制約で大きくスコアが落ちるケースは珍しくありません。

✍️ 専門家の経験からの一言アドバイス
【結論】：表示速度の改善は「気休め」ではなく、直帰率という数字で効果が出ます。
当社の支援事例では、トップページの LCP（最大コンテンツの描画時間）が約4秒だったサイトを画像最適化とサーバ応答改善で約2秒まで短縮したところ、モバイルの直帰率がおよそ15ポイント改善しました。計測 → 改善のサイクルは、流入を1件も増やさずに成果を底上げできる、費用対効果の高い施策です。

サイトが「重い」と感じたときに最初に確認する3つの観点

👉 このパートをまとめると！

• 「重さ」の原因は画像・JS/CSS・サーバ応答の3つに大別
• 各原因はCWVのどの指標に響くかが決まっている
• 計測ツールで原因の当たりをつけてから改善する

計測ツールで数値を出す前に、「サイトが重くなる原因は大きく3つに分かれる」ことを理解しておくと、計測結果のどこを見れば良いかが一気に明確になります。ここでは原因の3観点と、それぞれが Core Web Vitals のどの指標に影響するかをセットで押さえます。

画像・動画(ファイルサイズが起因、LCPに直結)

ページの読み込み速度を最も大きく左右するのが画像と動画です。テキストに比べてファイルサイズが桁違いに大きく、最適化されていない高解像度画像が1枚あるだけで表示が大幅に遅れます。

たとえば、トップページのメインビジュアルに数MBのJPEG画像をそのまま使っているケースや、サムネイル表示なのに原寸大の画像を読み込んでいるケースが典型です。画像はファーストビューの主役になりやすいため、LCP（Largest Contentful Paint＝最大コンテンツの描画時間） に直結します。計測ツールでLCPが悪い場合は、まず画像を疑うのが定石です。

JavaScript・CSS(レンダリングブロックが起因、INPに直結)

JavaScriptやCSSの量が多すぎたり、読み込みのタイミングが悪かったりすると、ブラウザがページの描画を中断してファイルの解析を優先してしまいます。これを「レンダリングブロック」と呼びます。

具体例としては、多機能なテーマやプラグインを大量に入れたWordPressサイトや、外部の解析タグ・広告タグを何本も同期読み込みしているサイトが該当します。重いJavaScriptはユーザーの操作への反応も遅らせるため、INP（Interaction to Next Paint＝操作してから次の描画までの応答時間） に直結します。ボタンを押しても反応が鈍い場合は、JavaScriptの処理負荷を疑います。

サーバ応答時間(TTFBが起因)

サーバそのものの応答が遅いと、画像やコードを最適化しても表示は速くなりません。ブラウザがリクエストを送ってから最初のデータが返ってくるまでの時間を TTFB（Time To First Byte＝最初のバイトが届くまでの時間） と呼び、サーバ性能やプラン、データベースの処理速度に左右されます。

たとえば、格安の共用サーバでアクセスが集中する時間帯に遅くなるケースや、データベースへの問い合わせが多い動的サイトでサーバ処理に時間がかかるケースが典型です。TTFBが大きい場合は、サーバ側（インフラ）の見直しが必要になります。

これら3観点は、後述の計測ツールで「どの数値を見れば原因の当たりをつけられるか」と表裏一体です。計測の前に「画像・コード・サーバのどこが怪しいか」という仮説を持っておくと、改善のスピードが格段に上がります。

サイトスピード計測ツールおすすめ5選

👉 このパートをまとめると！

• 初心者の起点はPageSpeed Insights一択
• 継続監視はSearch Console、詳細分析はGTmetrix/WebPageTest
• Test my siteは提供縮小につき現在は非推奨

ここからは、サイトスピード計測ツールのおすすめ5選を紹介します。いずれも基本機能を無料で使えるツールに絞り、特徴（何が分かるか）・無料/有料・料金・得意分野・PageSpeed Insightsとの違い の観点で統一して解説します。「結局どれを使えばいいか」は次章の早見表でまとめますが、まずは各ツールの守備範囲を把握してください。

PageSpeed Insights(計測の起点・まずこれ)

PageSpeed Insights（ページスピードインサイト、PSI） は、Googleが無料で提供するサイトスピード計測ツールです。検索意図が「とにかく今すぐ測りたい」であれば、最初に使うべき主役ツールはこのPageSpeed Insightsで間違いありません。

• 特徴：計測したいページのURLを入力するだけで、モバイルとPCそれぞれのパフォーマンススコア（0〜100点）と Core Web Vitals の判定を返します。フィールドデータ（実ユーザーの計測値）とラボデータ（その場のシミュレーション値）の両方を確認でき、さらに「改善できる項目」を自動提示してくれます。
• 無料/有料：完全無料
• 料金：0円
• 得意分野：初心者の計測起点、競合サイトとの比較、改善項目の洗い出し
• PSIとの違い（基準ツールとしての位置づけ）：本ツールが基準。URL入力だけで動くため、自社サイトはもちろん、競合サイトのURLを入れて速度を比較する使い方もできます。

実践的な使い方は次の3ステップです。

• PageSpeed Insights（ https://pagespeed.web.dev/ ）にアクセスする
• 計測したいページのURLを入力して「分析」を実行する
• 「モバイル」タブのスコアと Core Web Vitals の評価、「改善できる項目」を確認する

競合比較の実践例として、自社の商品ページと、検索上位にいる競合の同種ページのURLをそれぞれPageSpeed Insightsに入力すれば、LCPやスコアの差が一目で分かります。「競合は速いのに自社は遅い」という事実は、社内で改善予算を取る際の説得材料になります。

Lighthouse(Chrome DevTools標準搭載)

Lighthouse（ライトハウス） は、Google Chromeの開発者ツール（DevTools）に標準搭載されている監査ツールです。かつてはChrome拡張機能として追加する方式が案内されていましたが、現在は Chrome DevToolsに最初から組み込まれており、追加インストールは不要 です。

• 特徴：Chromeで対象ページを開き、DevTools（F12キーまたは右クリック→「検証」）の「Lighthouse」タブから実行します。パフォーマンスだけでなく、アクセシビリティ・SEO・ベストプラクティスまで多面的に監査できます。
• 無料/有料：完全無料
• 料金：0円
• 得意分野：開発者・制作会社による詳細監査、ローカル環境や認証が必要なページの計測
• PSIとの違い：PageSpeed Insightsの分析エンジンとして使われているのがLighthouseです。スコアの見方はほぼ同じですが、Lighthouseは手元のブラウザ環境で実行するため、公開前のステージング環境や、ログインが必要な管理画面の計測にも使える点が強みです。

Google Search Console「ウェブに関する主な指標」(継続監視)

Google Search Console（グーグルサーチコンソール、GSC） の「ウェブに関する主な指標」レポートは、サイト全体の Core Web Vitals を継続的にモニタリングできる、Google公式のフィールドデータ計測ツールです。

• 特徴：実際のユーザーの計測データ（フィールドデータ）をもとに、サイト内のURLを「良好」「改善が必要」「不良」の3分類で表示します。単一ページではなく、似た構造のURLをグループ単位で評価してくれるため、サイト全体のどこに問題が集中しているかを俯瞰できます。
• 無料/有料：完全無料（サイトの所有権確認が必要）
• 料金：0円
• 得意分野：実ユーザーデータでの継続監視、改善施策後の効果トラッキング
• PSIとの違い：PageSpeed Insightsが「今この瞬間の1ページ」を測るのに対し、Search Consoleは「直近の実ユーザー全体」の傾向を追えます。改善後に「良好」のページ数が増えていくかを定点観測するのに最適で、副担当者の「継続監視したい」ニーズに応えるツールです。

GTmetrix(ボトルネックの詳細分析)

GTmetrix（ジーティーメトリックス） は、ページの読み込み過程を時系列で可視化し、ボトルネックを特定するのに長けた計測ツールです。

• 特徴：「ウォーターフォールチャート」と呼ばれる、どのファイルがいつ・どれだけ時間をかけて読み込まれたかを滝のように並べた図を確認できます。これにより「特定の画像で2秒待たされている」「外部スクリプトの読み込みが遅い」といった具体的な詰まりどころが分かります。
• 無料/有料：無料版あり（上位機能は有料プラン）
• 料金：基本計測は0円。計測ロケーションの選択や履歴保存など上位機能は有料
• 得意分野：ファイル単位のボトルネック特定、原因の深掘り
• PSIとの違い：PageSpeed Insightsが「何点か・どの指標が悪いか」を示すのに対し、GTmetrixは「どのファイルが原因か」をファイル単位で示します。スコアが悪い原因を技術的に突き止めたいときに併用すると効果的です。

WebPageTest(地域・回線・端末を指定した精密計測)

WebPageTest（ウェブページテスト） は、計測条件を細かく指定できる、最も自由度の高い計測ツールです。

• 特徴：計測する地域（サーバロケーション）、回線速度、端末（ブラウザ）を細かく指定して計測できます。Core Web Vitals を可視化するほか、ページ表示の過程を連続画像（フィルムストリップ）で確認でき、「ユーザーの目に何秒後に何が見えるか」を視覚的に把握できます。
• 無料/有料：基本機能は無料
• 料金：0円（高頻度・大量計測は有料プランあり）
• 得意分野：海外ユーザー向けサイトの計測、特定の回線・端末での再現確認
• PSIとの違い：PageSpeed Insightsの計測条件が固定なのに対し、WebPageTestは条件を自由に変えられます。たとえば「アメリカからアクセスしたときの速度」や「低速回線での見え方」を再現したい制作会社・開発者向けの精密ツールです。

なお、かつて広く紹介されていたGoogleの「Test my site（テストマイサイト）」は現在提供が縮小されており、本記事ではおすすめツールから外しています。モバイル速度の計測はPageSpeed Insightsで代替できるため、今から使うツールとしては非推奨です。

ツールの使い分け早見表と選び方(目的×ツール)

👉 このパートをまとめると！

• 「自分はどれ?」は目的から逆引きする
• 初心者はPSI+Search Consoleの2本立てが鉄板
• 詳細分析が必要になったらGTmetrix/WebPageTestを追加

5つのツールを並べても、「結局、自分の目的にはどれが合うのか」が分からなければ意味がありません。そこで、目的・状況から逆引きできるユースケース別早見表を用意しました。自分の立場と目的に当てはまる行を見れば、選ぶべきツールが一目で分かります。

結論として、初心者はまず「PageSpeed Insights」と「Search Console」の2本立てから始める のが鉄板です。PageSpeed Insightsで個別ページの問題点を洗い出し、Search Consoleでサイト全体の傾向と改善後の推移を追う。この2つだけでも、計測と継続監視は十分にカバーできます。

そのうえで、PageSpeed Insightsで原因を特定しきれない場合に GTmetrix や WebPageTest を、開発者・制作会社が手元の環境で詳細監査する場合に Lighthouse を追加する、という段階的な使い分けが効率的です。

ここまでで「測る → 選ぶ」が見えてきました。一方で、計測したスコアが「結局、合格なのか不合格なのか」を判断できなければ、改善の優先順位は決められません。次章でその合格基準を整理します。

店舗・ローカルビジネスのWeb集客でお悩みの場合は、MEO対策ツール MEO Dash! byGMO もあわせてご検討ください。

Core Web Vitalsの合格基準を理解する(LCP/INP/CLS+TTFB)

👉 このパートをまとめると！

• 合格ラインはLCP2.5秒/INP200ms/CLS0.1以下
• 判定は全アクセスの75%が良好かどうかで決まる
• INPは2024年3月12日にFIDから置き換わった最新指標

計測ツールでスコアを出したら、次は「その数値が合格か不合格か」を判定します。その判定基準となるのが Core Web Vitals（コアウェブバイタル） です。Core Web Vitals とは、Googleがユーザー体験の質を測るために定めた、読み込み・応答性・視覚的安定性に関する3つの中核指標を指します。

まず、各指標の合格基準を表で押さえてください。良好（Good）・改善が必要（Needs Improvement）・不良（Poor）の3段階で示します。

重要なのは判定方法です。web.dev によれば、Core Web Vitals は 全アクセスの75%（75パーセンタイル）で「良好」の基準を満たして初めて合格 と評価されます。一部のユーザーで速くても、4分の1以上が遅ければ不合格になる、という点を覚えておいてください。

LCP:メインコンテンツが表示される速さ

LCP（Largest Contentful Paint） は、ページのファーストビューにある最も大きなコンテンツ（多くは画像やメインビジュアル、見出し）が表示されるまでの時間です。良好の基準は2.5秒以下。ユーザーが「ページが表示された」と体感する速さに直結するため、3指標の中でも改善優先度が高い指標です。LCPが遅い主因は画像であることが多く、画像最適化が最も効きます。

INP:操作に対する反応の速さ(2024年3月12日にFIDから置換)

INP（Interaction to Next Paint） は、ユーザーがクリックやタップなどの操作をしてから、画面が反応して次の描画が行われるまでの応答時間です。良好の基準は200ミリ秒以下です。

このINPは、2024年3月12日に、それまで使われていた FID（First Input Delay）に代わって Core Web Vitals の正式な指標 となりました。FIDが「最初の操作の遅延」だけを測っていたのに対し、INPはページ上のすべての操作の応答性を評価するため、より実態に近い指標です。古い記事を参考にFIDを目標に改善している場合は、INPベースに切り替える必要があります。INPが悪い場合は、重いJavaScriptの削減が主な対策になります。

CLS:レイアウトのずれにくさ

CLS（Cumulative Layout Shift） は、ページ読み込み中に発生する予期しないレイアウトのずれの大きさを示す指標です。良好の基準は0.1以下。たとえば、ボタンを押そうとした瞬間に画像や広告が後から表示されてレイアウトがずれ、誤タップしてしまう体験がCLSの悪化です。画像・広告枠にサイズ（width/height）をあらかじめ指定することで改善できます。

TTFB:サーバ応答の速さ(補助指標)

TTFB（Time To First Byte） は Core Web Vitals そのものではありませんが、LCPやINPの土台となる補助指標です。目安は0.8秒以下。TTFBが遅いと、どれだけ画像やコードを最適化しても全体が遅くなるため、サーバ側の改善余地を見極める手がかりになります。

Core Web Vitals の3指標をより深く理解したい場合は、各指標の意味と改善策を網羅的に解説した記事もあわせて参照してください。LCPの改善方法だけを集中的に深掘りしたい場合は、LCP改善に特化した記事が役立ちます。

PageSpeed Insightsスコアの読み方と目安

👉 このパートをまとめると！

• スコアは0-49赤/50-89橙/90-100緑の3段階
• フィールドデータが実態、ラボデータは改善の手がかり
• 目標はPerformance90以上+CWV3指標すべて良好

PageSpeed Insights を使いこなすうえで、スコアの読み方と目標値の理解は欠かせません。数値の意味が分かれば、「どこまで改善すれば十分なのか」というゴールが明確になります。

スコアレンジ:0-49/50-89/90-100の3段階

PageSpeed Insights のパフォーマンススコア（Performance）は0〜100点で表示され、色と数値で速さの目安が分かります。

• 0〜49(赤)：遅く、要改善のレベル
• 50〜89(オレンジ)：標準的だが改善の余地あり
• 90〜100(緑)：速い部類

90点以上の緑が出れば、速度面では合格ラインと言えます。ただしスコアはあくまで総合点であり、内訳である Core Web Vitals の各指標がすべて「良好」になっているかをセットで確認することが大切です。

フィールドデータとラボデータの違い

PageSpeed Insights の結果には、性質の異なる2種類のデータが表示されます。この違いを理解していないと、改善効果の判断を誤ります。

• フィールドデータ（実際のユーザーの環境）：直近の一定期間に実際にそのページを訪れたユーザーの計測値を集計したものです。Googleが検索評価に用いるのは、このフィールドデータです。実態を表しますが、データが蓄積されるまで反映に時間がかかります。
• ラボデータ（シミュレーション）：計測したその瞬間に、Googleが管理された条件下でシミュレーション計測した値です。改善作業の前後で即座に変化を確認できるため、改善中の手応えを掴むのに向いています。

実務では、改善作業中はラボデータで手応えを確認し、最終的な合否はフィールドデータ（およびSearch Console）で判断する、という使い分けが基本です。

目標値:Performance 90以上+CWV3指標すべて良好

目指すべきゴールは明確です。PageSpeed Insights のパフォーマンススコア90以上、かつ Core Web Vitals の3指標（LCP/INP/CLS）すべてが「良好」 の状態です。スコアだけ高くてもCWVのどれかが不良なら、ユーザー体験としては不十分。両方を満たして初めて、速度面で検索評価とUXの双方に貢献できます。

✍️ 専門家の経験からの一言アドバイス
【結論】：スコア改善は順位・流入の改善に繋がり得ます。ただし「速くしたら必ず1位」ではない点に注意してください。
当社が支援したあるコンテンツサイトでは、PageSpeed Insights のパフォーマンススコアが40前後で Core Web Vitals も不良の状態でした。画像最適化・JavaScript削減・キャッシュ設定を実施し、スコアを85前後まで、CWVを全項目「良好」まで引き上げたところ、検索評価の改善とコンテンツ強化が相まって、対象ページ群のオーガニック流入が約1.6倍に増加しました。速度改善は単独で順位を保証しませんが、コンテンツ品質と組み合わさることで効果を後押しする、確かな下地になります。

計測スコアを改善する5つのアクション

👉 このパートをまとめると！

• 改善は画像最適化→JS/CSS削減→キャッシュの順が王道
• 各アクションは効くCWV指標が決まっている
• 最初の一手は費用対効果が高い画像最適化から

計測して合否を判定したら、最後は改善の実行です。ここでは、表示速度を改善するための代表的な5つのアクションを、「課題 → 具体施策 → 期待される改善指標」のセットで解説します。やみくもに着手せず、効果の大きい順に取り組むのが鉄則です。

アクション1:画像最適化(主にLCPを改善)

• 課題：最適化されていない画像は、ページ全体の読み込みを最も重くする要因です。
• 具体施策：次世代フォーマット（WebP/AVIF）への変換、表示サイズに合わせた適切なリサイズ、ファーストビュー外の画像の遅延読み込み（lazy loading）を実施します。
• 期待される改善指標：LCP。メインビジュアルが軽くなることで、最大コンテンツの描画が速くなります。

アクション2:JavaScript・CSSの削減と遅延読み込み(主にINP/TBTを改善)

• 課題：過剰なJavaScriptやCSSがレンダリングをブロックし、操作への反応も遅らせます。
• 具体施策：不要なコードの削除、ファイルの圧縮（minify）、defer／async属性による読み込みの遅延・非同期化で、描画をブロックしないようにします。
• 期待される改善指標：INP（および総ブロック時間TBT）。操作への反応速度が向上します。

アクション3:ブラウザ・サーバキャッシュの活用(主にTTFBを改善)

• 課題：毎回すべてのデータを取得し直すと、再訪問時や同一サイト内の回遊が遅くなります。
• 具体施策：ブラウザキャッシュの有効期限設定、サーバ側・CDN側のキャッシュ活用で、データの再利用を促します。更新頻度の低い画像は長め、更新頻度の高いファイルは短めに有効期限を設定するのがコツです。
• 期待される改善指標：TTFB。サーバ応答とデータ取得が速くなります。

アクション4:CDNの導入(地域最適化・TTFBを改善)

• 課題：サーバから物理的に遠いユーザーほど、データ到達に時間がかかります。
• 具体施策：CDN（コンテンツ・デリバリー・ネットワーク）を導入し、世界各地のキャッシュサーバからユーザーに近い拠点で配信します。
• 期待される改善指標：TTFB（地域最適化）。特に全国・海外にユーザーがいるサイトで効果が大きくなります。

アクション5:サーバ応答時間の改善(主にTTFBを改善)

• 課題：サーバそのものの処理能力が不足していると、根本的に表示が遅くなります。
• 具体施策：上位のサーバプランへの移行、データベースのクエリ最適化、不要なプラグインの整理などでサーバ処理を軽くします。
• 期待される改善指標：TTFB。応答の土台が改善し、他施策の効果も底上げされます。

✍️ 専門家の経験からの一言アドバイス
【結論】：最初の一手は「画像最適化」が最も費用対効果が高い、というのが当社コンサルタントの一致した見解です。
多くのサイトでLCPの悪化要因は画像に集約されており、WebP/AVIF化と適切なリサイズ、遅延読み込みを行うだけで、コードに手を入れずとも体感速度が大きく変わるケースが少なくありません。まずは画像から着手し、それでも基準に届かない場合にJavaScript・CSS、サーバ側へと進むのが、最短で成果を出す改善の順番です。

LCPの改善をさらに掘り下げたい場合は、LCP改善に特化した解説記事で、具体的な手順と判断基準を確認することをおすすめします。

FAQ:サイトスピード計測でよくある質問

👉 このパートをまとめると！

• スコアは計測条件で変動するのが正常
• モバイル優先で改善するのが基本方針
• 速度は順位の一要因で、コンテンツ品質と両輪

最後に、サイトスピード計測でよく寄せられる疑問に回答します。

Q1. PageSpeed Insightsのスコアが計測のたびに変わるのはなぜですか?

ラボデータが、計測時のサーバ負荷やネットワーク状況、CPUの瞬間的な状態に影響されるためです。ラボデータは毎回ある程度ブレるのが正常で、1回の数値に一喜一憂する必要はありません。傾向を見たい場合は、複数回計測した平均で判断するか、実ユーザーの集計値であるフィールドデータやSearch Consoleの推移で評価してください。

Q2. モバイルとPCはどちらを優先して改善すべきですか?

原則としてモバイルを優先します。Googleはモバイル版を基準に評価する「モバイルファーストインデックス」を採用しており、現在のWeb閲覧の多くがスマートフォン経由だからです。モバイルは回線やCPU性能の制約でスコアが落ちやすく、改善インパクトも大きいため、まずモバイルのスコアとCore Web Vitalsを基準に対処するのが効率的です。

Q3. 無料ツールだけで十分ですか?有料ツールは必要ですか?

多くのサイトは、PageSpeed Insights・Lighthouse・Search Consoleという無料ツールだけで計測から継続監視まで完結できます。有料プラン（GTmetrixやWebPageTestの上位機能）が必要になるのは、計測ロケーションを細かく変えたい、計測履歴を保存して定点観測したい、といった高度な要件がある制作会社・開発者のケースです。まずは無料ツールから始めて問題ありません。

Q4. スコアが90点を超えれば検索順位は上がりますか?

スコア90点はあくまで「速度面で良好」という到達点であり、それだけで順位上昇を保証するものではありません。サイトスピードは検索順位を決める多数の要因の一つです。コンテンツの品質や検索意図との一致、被リンクなど他の要因が満たされて初めて、速度改善が順位やCVRの後押しとして効いてきます。速度は「土台」と捉えるのが適切です。

Q5. 重い原因がサーバ側か自サイト側か、どう見分ければよいですか?

まず TTFB（最初のバイトが届くまでの時間）を確認します。TTFBが0.8秒を大きく超えている場合はサーバ側（プランやデータベース、インフラ）の問題が疑われます。一方、TTFBは速いのにLCPやINPが悪い場合は、画像やJavaScript・CSSなど自サイト側のコンテンツに原因があります。GTmetrixのウォーターフォールチャートを使うと、どのファイルで時間がかかっているかをファイル単位で特定でき、原因の切り分けがより正確になります。

まとめ

👉 このパートをまとめると！

• サイトスピードは「計測→判定→改善」の3ステップ
• PSIで測りCWVで判定し5アクションで改善する
• 改善後はSearch Consoleで継続監視する

サイトスピードの良し悪しは体感では判断できないため、計測ツールで客観的な数値に変えることが出発点です。本記事で解説した流れを、改めて3ステップで整理します。

• 測る：PageSpeed Insights でURLを入力し、モバイルのスコアと Core Web Vitals を計測する。初心者はPageSpeed InsightsとSearch Consoleの2本立てから。
• 判定する：Core Web Vitals の合格基準（LCP 2.5秒以下／INP 200ms以下／CLS 0.1以下）で合否を判断する。INPは2024年3月12日にFIDから置き換わった最新指標である点に注意。
• 改善する：画像最適化を最初の一手に、JavaScript・CSS削減、キャッシュ活用、CDN導入、サーバ応答改善の5アクションで対処する。

そして、改善はやって終わりではありません。Search Consoleの「ウェブに関する主な指標」で「良好」のページ数が増えているかを継続監視し、効果を定点観測することが、安定した速度と検索評価を保つ鍵になります。

サイトスピードの改善は、流入を1件も増やさずに直帰率やCVRを底上げできる、費用対効果の高い施策です。本記事のツールと基準を使って、まずは自社サイトの現在地を計測することから始めてください。

店舗ビジネスのWeb集客・MEO対策については MEO Dash! byGMO もあわせてご相談いただけます。