PageSpeed Insightsの使い方と見方：点数より先に見るところと携帯電話の結果

PageSpeed Insights（ページスピード インサイト）は、Googleが無料で公開している、ページの表示の速さを調べる道具です。pagespeed.web.dev を開き、調べたいページのURLを入れて「分析」を押すと、「携帯電話」と「デスクトップ」それぞれの結果が出ます。

結果の画面は、大きく2つの部分に分かれています。上の「実際のユーザーの環境で評価する」は、Chromeを使った実際の訪問者の過去28日間のデータ（フィールドデータ）です。下の「パフォーマンスの問題を診断する」は、Googleの側でその場で1回だけ試しに読み込んだ結果（ラボデータ）で、0〜100の点数はこちらに出ます。

見る順番は、①上の部分にデータがあるか、あれば合格しているか、②下の部分の5つの指標のうち、赤やオレンジになっているのはどれか、③その指標に効く改善項目はどれか、です。点数そのものは最後に見れば足ります。アクセスの少ないサイトでは、上の部分に「データが十分にありません」という趣旨の表示が出ますが、故障ではないので放っておいて構いません。

使い方：URLを入れて「分析」を押す

1. ブラウザで pagespeed.web.dev を開きます。Googleアカウントへのログインは要りません。
2. 入力欄に、調べたいページのURLをそのまま貼ります。
3. 「分析」を押し、結果が出るまで待ちます。
4. 結果の上にある「携帯電話」と「デスクトップ」を切り替えて、両方を見ます。
5. 日付と、主な数字（点数と5つの指標）を控えておきます。直したあとに比べるためです。

調べるページは、トップページだけでは足りません。検索から人が入ってくる記事のページ、料金やサービスのページ、問い合わせのページを1本ずつ調べます。ページごとに使っている画像や部品が違うので、結果も違うからです。

なお、調べられるのは誰でも開ける公開中のページだけです。WordPressの下書きのプレビューのように、ログインしないと見られないページは、Googleの側から開けないので調べられません。

上の部分と下の部分は何が違うか（フィールドデータとラボデータ）

2つの部分は、データの取り方がまったく違います。

上の部分は、Chrome ユーザー エクスペリエンス レポート（Chromeの利用者から集めた表示速度の統計。CrUXと略されます）がもとになっています。Googleの説明では、ここで Core Web Vitals（ウェブに関する主な指標。LCP・INP・CLSの3つ）を評価し、それぞれの75パーセンタイル（訪問を速い順に並べて4分の3の位置の値。4回に3回はこれより速いという意味）がすべて「良好」なら合格です。3つの指標の意味と基準値はコアウェブバイタルとはにまとめました。

下の部分は、Lighthouse（Googleの診断の仕組み）が、決まった端末と回線の条件で1回だけ読み込んだ結果です。Googleの説明は、フィールドデータを「特定のURLが過去にどう表示されたかの記録」、ラボデータを「1台の端末と決まった回線の条件での模擬の読み込み」としていて、両者の数字が食い違うことがあると書いています。

どちらが正しいということではありません。訪問者の実際の体験を知るのは上の部分、原因を探して直すのは下の部分、と役割が違います。Search Console の「ウェブに関する主な指標」のレポートも、上の部分と同じCrUXのデータをもとにしています（サーチコンソールとは）。

「データが十分にありません」と出たとき：アクセスの少ないサイトの見方

当社が2026年10月9日に、自社の記事のページ（「クロール済み – インデックス未登録」の記事）を調べたとき、上の部分には次の表示が出ました。

「Chrome ユーザー エクスペリエンス レポートには、このページの実際の速度データが十分にありません。」

これは、このページを開いたChromeの利用者がまだ少なく、統計にできるだけのデータがないという意味です。Googleの説明では、そのページのデータが足りないときはサイト全体（オリジン）のデータに切り替えて表示し、サイト全体でも足りないときは、実際の利用者のデータは表示されません。どのくらいのアクセスがあれば出るようになるかは、この説明には書かれていません。

この表示は、ページの不具合ではありません。直す対象ではないので、放っておいて構いません。アクセスが増えてくれば、いずれ数字が出るようになります。

その間は、下の部分（ラボデータ）を頼りに見ます。ただし、1回の模擬の読み込みなので、実際の訪問者の体感とずれることがあります。数字の大小に一喜一憂せず、「どの指標が、どれくらい悪いか」を見る使い方が向いています。

点数より先に、5つの指標の色を見る

下の部分の点数は、5つの指標から計算されています。Chromeの公式の説明に載っている Lighthouse 10 の重みと、携帯電話で緑（速い）とされる範囲は次のとおりです。

点数は、0〜49が赤、50〜89がオレンジ、90〜100が緑です。点数が同じでも、どの指標が足を引っ張っているかで、直すところはまったく変わります。だから、点数より先に指標の色を見ます。

Chromeの公式の説明は、ほかにも大事なことを二つ書いています。一つは、点数に影響するのは指標だけで、改善項目（改善案や診断）の結果は直接は影響しない、ということ。改善項目は、指標を良くするための手がかりという位置づけです。もう一つは、100点の「完璧」なスコアを取るのは非常に難しく、期待されるものではない、ということです。

また、何も変えていなくても、測るたびに点数は上下します。Googleの説明は、回線の状態や、試験に使う機械の混み具合などで、ばらつきが出るとしています。1回の結果で判断せず、2〜3回測って傾向を見てください。

当社の記事ページの例：点数77で、何を直すべきか

ここからは、当社の記事ページ（/gsc-crawled-not-indexed/）を2026年10月9日に1回だけ調べた結果で、判断の流れを示します。上に書いたとおり測るたびに数字は上下するので、細かい値より、どの指標が悪いかの傾向として読んでください。携帯電話のパフォーマンスは77、ユーザー補助96、おすすめの方法100、SEO100でした。

携帯電話の数字を、上の表の範囲に当てはめます。LCPの4.8秒は、Chromeの説明で赤（4秒以上）の範囲です。FCPの2.5秒はオレンジ（1.8〜3秒）。TBTの150ミリ秒、CLSの0、Speed Indexの3.0秒は緑の範囲に入っています。

つまり、77点を押し下げているのは、主にLCPとFCP、言い換えると「表示の始まりが遅く、一番大きな要素が出るまでがさらに遅い」ことです。最初の表示が2.5秒、そこから一番大きな要素が出るまでにさらに2.3秒かかっています。直すべきなのは、この二つです。反対に、TBTとCLSは今の時点では直す理由がありません。デスクトップでは、どの数字も携帯電話よりずっと小さく、問題は携帯電話の側にあると分かります。

次に、改善項目として出たものを、どの指標に効くかで仕分けます。当社の記事ページでは、携帯電話で次の8つが出ました。

最初に見るのは「レンダリングをブロックしているリクエスト」です。Chromeの説明では、ページの最初の表示を妨げているリクエストのことで、LCPを遅らせることがあるとされています。FCPとLCPの両方に効く可能性があるので、順番の一番目に置きます。使っていないCSSやJavaScriptの削減も、表示の前に読み込む量を減らす話なので、その次です。

「効率的なキャッシュ保存期間を使用する」は、画像やCSSなどの控えを訪問者のブラウザに長く持たせる設定のことです。Chromeの説明は、長い保存期間はページへの「再訪問」を速くする、としています。初めての訪問者には効かないので、検索から初めて来る人に向けた記事ページでは、優先度は下がります。サーバーやプラグインの設定で決まるもので、「変更が反映されないときにキャッシュを消す」話とは別物です（キャッシュの消し方はWordPressで変更が反映されないとき）。

最後の「コントラスト比」は、速度ではなく、ユーザー補助（読みやすさ）の項目です。点数77とは関係ありませんが、読みにくい色は読者にとって困るので、速度の話とは別に直します。

この記事ページの改善項目には、画像に関する項目は入っていませんでした。画像が重いページでは「画像配信を改善する」という項目が出ます。その場合の直し方は画像の最適化にまとめました。

携帯電話とデスクトップで結果が違う理由と、どちらを優先するか

同じページなのに、当社の例ではLCPが携帯電話で4.8秒、デスクトップで0.8秒でした。この差は、試験の条件の違いから来ています。Googleの説明では、携帯電話の試験は中くらいの性能の端末（Moto G4）を想定し、モバイル回線の速さに絞って読み込みます。デスクトップは、有線でつないだパソコンを想定しています。

どちらを優先するかは、実際の訪問者がどちらで来ているかで決めます。お店や暮らしの困りごとのように、スマホで探されることが多い業種なら、携帯電話の結果を優先します。会社の担当者が仕事中に探すような業種では、パソコンが多いこともあります。GA4の「デバイス カテゴリ」で、自社のサイトの割合を確かめてから決めてください（GA4とは）。

自分のスマホで開いて速く感じても、安心はできません。自分の端末は新しく、Wi-Fiにつながっていて、一度開いたページの控えも残っています。初めて来る訪問者は、もっと遅い条件で開いているかもしれません。

改善項目は、自分で直せるものと頼むものに分ける

改善項目を開くと、どのファイル（URL）が該当するかが一覧で出ます。そのURLを見ると、原因がテーマなのか、プラグインなのか、外部のサービスなのか、見当がつきます。WordPressのサイトなら、次のように分けると進めやすくなります。

• 画像：大きすぎる画像の差し替えは、自分でできます。
• 使っていないプラグイン：止めて削除するのは自分でできます。止める前にバックアップを取ってください（WordPressのバックアップ方法）。
• テーマやプラグインのCSS・JavaScriptの読み込み方：表示崩れが起きやすいので、制作会社か詳しい人に頼むのが無難です。CSSやJavaScriptをまとめて縮める「最適化」のプラグインもありますが、入れたら全ページの表示と問い合わせフォームの動きを確かめます。
• キャッシュ保存期間やサーバーの応答：サーバーの設定なので、サーバーの管理者に相談します。

ページが重い原因の切り分け方と、直す順番はホームページが重い・表示が遅いときの原因と直す順番に書きました。

直したあとに確かめること

1. 同じページを、同じ「携帯電話」の結果で、2〜3回測ります。直す前の控えと比べます。
2. キャッシュのプラグインやサーバーのキャッシュを使っているなら、消してから測ります。古い控えが返っていると、直したものが反映されていない結果が出ます。
3. 表示が崩れていないか、問い合わせフォームが送れるかを、スマホとパソコンで確かめます。当社も見た目に関わる変更は、AIにブラウザ（Playwright）で320〜1920pxの複数の画面幅を撮影させ、横のはみ出しやエラーがないかを確かめてから反映しています。
4. 上の部分（実際のユーザーの環境）は過去28日間の集計なので、直してもすぐには変わりません。下の部分で改善を確かめ、上の部分はひと月ほど後に見ます。

表示速度は、問い合わせまでの道のりの一つ

点数が上がっても、それだけで問い合わせが増えるわけではありません。表示が遅くて読まれずに帰られているのか、読まれても選ばれていないのかで、手を付けるところは変わります。速度は、検索から問い合わせまでの道のりの途中にある一つの関門です（ホームページから問い合わせを増やす方法）。

当社は、ホームページの運営に加わり、問い合わせが来るところまでを見ています。表示速度も、その途中で詰まっているところがあれば直す対象の一つです。改善項目のどれから手を付けるか、自社で直すか頼むかの判断に迷ったら、相談するからURLを添えてお知らせください。

参考にした公式の説明

• Google for Developers「PageSpeed Insights について」
• Chrome for Developers「Lighthouse のパフォーマンス スコアリング」
• Chrome for Developers「First Contentful Paint」
• Chrome for Developers「Largest Contentful Paint」
• Chrome for Developers「Total Blocking Time」
• Chrome for Developers「Speed Index」
• Chrome for Developers「Render blocking requests」（英語）
• Chrome for Developers「Use efficient cache lifetimes」（英語）
• web.dev「ウェブに関する主な指標」

※内容は2026年10月時点の各公式の説明で確かめたものです。PageSpeed Insights の画面の表示や改善項目の名前は、版によって変わることがあります。当社の数字は、2026年10月9日に当社の記事ページを1回計測した結果です。