PageSpeed Insightsの使い方｜自社のLPと記事を測った結果（利用者は合格・点数は49）と、点数より先に見る指標

PageSpeed Insightsは、URLを入れるだけでページの表示の速さを測れる、Googleの無料の道具です。 結果は「実際の利用者のデータ」と「診断の点数」の2段で、先に利用者のデータを確認します。 当社の計測では利用者のデータは合格（LCP 1.8秒・INP 128ミリ秒・CLS 0）でしたが、記事の診断は49点、トップはLCPを測れないエラーでした。

ただし、この合格は各ページ単体ではなく、サイトのオリジン全体に対して表示された評価です。 「49点だから利用者全員が遅い」「合格だから直さなくてよい」とは、どちらも判断できません。

本記事は2026年10月の調査と、10月27日23時36〜38分の当社計測に基づいています。 画面の表示名、採点方式、APIの条件は変わるため、最新情報はGoogle公式で確認してください。

PageSpeed Insightsとは

PageSpeed Insightsとは、実際の利用体験とテスト環境での診断から、ページの改善点を調べるツールです。

略称はPSIで、スマートフォンとパソコンそれぞれの表示や操作の状態を、URLごとに確認できます。 経営者なら改善の優先順位を決める入口に、Web担当者なら制作・開発担当者への相談材料に使えます。

Lighthouseとの違いは、PSIが結果を見せる窓口で、Lighthouseが診断を担う仕組みであることです。 PSIの点数はLighthouseで計算しますが、実際の利用者の集計まで同じ仕組みで作るわけではありません。

データの取得元と診断の仕組みについては、Google公式のPSI概要で確認できます。

使い方の手順

使い方は、URLを入れて分析し、端末とデータの集計対象を切り替えて、同じ条件の結果を記録する流れです。

1. PageSpeed Insightsの公式画面を開き、調べるページのURLを入力します。
2. 「分析」を押し、結果が表示されるまで待って、入力先と測定対象のページが一致するか確認します。
3. 「携帯電話」と「デスクトップ」を切り替え、それぞれの利用者データと診断結果を確認します。
4. 利用者データの「この URL」と「オリジン」を確認し、ページ単体かサイト全体かを記録します。
5. 下の診断で問題の指標と改善提案を開き、測定日時、端末、測定条件と一緒に保存します。

広告用LPだけでなく、検索から読まれる記事や、購入・問い合わせに近いページも対象に選びます。 トップページの点数だけでは、商品説明やフォームまでの途中にある使いにくさを把握しきれません。

実際の利用者のデータ（フィールドデータ）の見方

フィールドデータは、過去28日間の実際の利用体験を集計したもので、対象範囲を確認してから合否を読みます。

元になるのはChrome ユーザー エクスペリエンス レポート、通称CrUXというGoogleのデータです。 対象条件を満たすChrome利用者の集計であり、自社サイトの全訪問者を測ったアクセス解析ではありません。

最初に見るのは、Core Web Vitalsと呼ばれる、読み込み・操作への応答・表示の安定性の3指標です。 数値が小さいほど良好ですが、CLSには秒やミリ秒の単位がなく、時間とは分けて読み取ります。

判定は平均値ではなく、原則として各指標の75パーセンタイルが、良好の範囲に入るかで決まります。 75パーセンタイルとは、おおむね対象体験の75％がその値以下に収まる位置を示したものです。

3指標のデータがそろう場合は、すべて良好なら「ウェブに関する主な指標の評価」が合格になります。 INPが不足する場合はLCPとCLSで判定し、LCPかCLSが不足する場合は評価できません。 しきい値だけでなく、データが不足した場合の判定条件も、Google公式の説明で確認できます。

「この URL」が選べないときはオリジンを見る

当社ではトップと記事のスマホ計測で、「この URL」が灰色になり、オリジンの数値が表示されました。 ページ単体の対象データが足りなかったため、両方にLCP 1.8秒などの同じ値が出たということです。

オリジンはプロトコルとホスト名などで区切る集計単位で、ここではサイト全体の値として読んでいます。 記事ごとの速さが一致した証拠ではないため、「この記事は実測で1.8秒」とは言い換えられません。

URLもオリジンもデータ不足なら、利用者の評価自体が表示されず、速度の良し悪しも判断できません。 なお、28日間の集計は日々更新されるため、修正直後も変更前の体験がしばらく混ざった状態になります。

診断（ラボデータ）の点数と指標

ラボデータの点数は、設定された端末・通信環境で得た指標の加重平均で、利用者データの合否とは別です。

当社の記事をスマホ条件で分析すると、パフォーマンスは49点で、初期表示に関する時間が長く出ました。 点数を読む前に指標を分けると、「どこを待たせているか」を制作・開発担当者と共有しやすくなります。

2026年10月の調査時点で、Google公式の採点資料に掲載されている指標の重みは次のとおりです。 時間やCLSの値をそのまま足すのではなく、各測定値を指標別のスコアに変換してから計算します。

提案を何件消したかで直接加点される仕組みではなく、修正で指標が変わった結果として点数が動きます。 また、TBTは初期読み込み時の応答性を調べる手がかりで、実際の操作を測るINPの代わりではありません。

「合格点は何点か」への答えは、ラボの良好は90点以上、利用者の合格は3指標で判定する、となります。 各指標の配点と点数の評価区分は、Lighthouse公式の採点方法に掲載されています。

毎回点数が変わる理由には、通信経路や配信側の状態、動的なコンテンツなどの条件の揺らぎがあります。 同じURLと端末で繰り返し測り、最高点だけを採用せず、同じ指標が継続して悪いかを確認しましょう。

当社のページを測った結果

当社のトップと記事では、オリジンの利用者データが合格でも、ラボは73点・49点・エラーに分かれました。

測定はPageSpeed InsightsのWeb画面で行い、トップをスマホとパソコン、記事をスマホで確認しました。 スマホはLighthouse 13.5.0で、Moto G Power、低速4G、最初の読み込みを模擬した条件です。

トップのスマホでは、ラボのLCPとTBTに「Error! NO_LCP」が表示され、総合点は出ませんでした。 一方でFCPとSpeed Indexはともに13.0秒、CLSは0と表示され、一部の指標は取得できていました。

トップは主役となるアプリ画面を段階的に見せる作りで、その表示方法が測定に影響した可能性があります。 ただし、今回の記録だけで原因は断定できず、動きを外せば必ず解消すると結論づけることもできません。

TTFBは最初の応答が届くまでの時間で、主な内容が見えるまでのLCPとは別の待ち時間を表します。 FCPやTTFBが良好でも、その後の画像取得や描画の待ち時間まで短いとは限らないため、分けて考えます。

今回の食い違いには、オリジンと個別ページ、28日間と単発テスト、実環境と模擬環境という違いがあります。 実際の利用体験を先に見つつ、記事の15.0秒という診断値も、遅くなる条件を探す材料として扱います。

改善できる項目の読み方

インサイトと診断は原因の候補を探す欄であり、推定削減量や時間を、そのまま改善結果として扱わないことが基本です。

表示名はLighthouseの版で変わるため、古い解説と名前が違っても、対象となる処理や画像を確認します。 Lighthouse 13では旧監査の一部がインサイトへ統合され、この更新自体による採点方式の変更はありません。 診断項目の変更点は、Google公式のLighthouse 13解説に記載されています。

記事で特に大きかったのは、読み込みを止めているリクエストの推定9,920ミリ秒、約9.9秒でした。 これは実際に9.9秒短縮できたという結果ではなく、詳しく調べる対象を決めるための推定値です。

また、未使用のコードも測定中の状態に基づくため、メニューやフォームの操作に必要なものが含まれ得ます。 初期表示で使わなかったという理由だけで削除せず、主要な操作を試しながら必要性を判断してください。

記事ページ全体は3,545 KiBでしたが、ページ容量だけで点数の差を説明できるわけではありません。 どの順に取得するか、表示に何を待つか、端末がどれだけ処理するかも一緒に調べる必要があります。

直す順番

当社の結果から考える着手順は、読み込みを止めるCSS・JavaScript、画像、動きですが、まだ修正はしていません。

以下は診断に基づく改善候補であり、当社が修正して速度や点数の上昇を確認した実績ではありません。 全サイト共通の公式順位でもなく、自社の利用者データと重要な導線に合わせて、順番を調整してください。

1. 初期表示を止めているCSS・JavaScriptを調べ、不要な読み込みや後回しにできる処理を分けます。
2. 画像の大きさ・形式・読み込み方を見直し、width・heightによる表示領域の確保も確認します。
3. アニメーションの処理と表示方法を確認し、画面外の動きや、内容の表示を待たせる作りを見直します。

CSS・JavaScriptは初期表示と操作への必要性を分ける

記事の約9.9秒という推定を手がかりに、まず描画を止めるリクエストが、最初の画面に必要か調べます。 不要なコードは削減し、後で必要になる処理は必要な時点で読み込む方法を、開発担当者と検討します。

一括して遅延するとメニューやフォームが動かなくなる可能性があるため、表示と操作の両方を確かめます。 重要なCSSの埋め込みは高度な方法で、Googleも不具合の可能性を挙げており、最初から必須ではありません。 対策の選択肢と注意点は、描画を妨げるリクエストの公式解説で確認できます。

画像は容量と取得開始と表示領域を確認する

画像を小さく圧縮しても、取得開始が遅かったり、取得後に非表示で待ったりすれば、LCPは残ります。 LCPの内訳を見て、応答、取得開始、転送、描画のどこが遅いかを、容量の調整と分けて調べましょう。

特にLCP画像への遅延読み込みは、必要な画像の取得開始を遅らせるため、公式が避けるよう案内しています。 画面の下にある画像を後から読み込む考え方と、最初に見せる主役の画像は分けて設計してください。 画像の取得方法と表示領域の対策は、LCP改善ガイドとCLS改善ガイドが根拠になります。

当社の別の画像検証では、2016×1344のPNG、2,097,169バイトを、幅1200pxのWebPに変換しました。 画質82の設定で79,682バイト、元の約4％でしたが、これは今回のページを修正した前後比較ではありません。

動きはファイル容量と描画負担を分ける

トップで指摘された9件のアニメーションは、対象を開き、どの動きが描画に負担をかけるかを調べます。

画面外の動きを止める、最初の説明を先に見せるなど、目的を保った調整を確認用ページで試します。 動きを変える場合も、今回のNO_LCPがその作業で解消するとは決めず、再測定で確かめる必要があります。

モバイルだけ遅いときの見方

モバイルだけ遅い場合は、端末性能と通信条件、表示する画像や要素の違いを、パソコンと分けて確認します。

今回のスマホ診断は低速4Gなどを模擬しており、普段のパソコンで快適に見えることとは条件が違います。 端末別の採点も異なるため、パソコンの点数との差だけで、スマホ用ページの不具合とは断定できません。

スマホ側に点数がないことを0点と扱わず、取れた指標と提案、実機での状態を使って調べます。

アクセス解析で端末別の流入や購入・問い合わせも確認し、事業への影響が大きい対象から着手します。 その際、モバイルの利用者データが合格でも、特定の記事や操作の問題まで解消されたとは考えないでください。

PageSpeed InsightsをSEOと成果の改善に使う方法

SEOと成果の改善では、点数だけを目標にせず、検索流入から購入・問い合わせまでの体験を確認します。

GoogleはCore Web Vitalsをランキングに使用すると説明していますが、良好でも上位表示は保証しません。 満点だけを追うより、必要な情報が伝わり、操作が進み、成果につながるかも合わせて判断しましょう。 検索順位とページ体験の関係は、Google検索の公式解説で確認できます。

よくある質問（FAQ）

よくある疑問は、点数の評価、測定の揺らぎ、エラー、API、認証付きページに分けると判断しやすくなります。

合格点は何点ですか

ラボのパフォーマンスは90点以上が良好で、50〜89点は改善が必要、0〜49点は不良の区分です。 利用者の「合格」は別の判定なので、今回のようにオリジンは合格、記事の診断は49点でも矛盾しません。

毎回点数が変わるのはなぜですか

通信経路、配信側の状態、動的な表示内容などが変わるため、コードを変えなくても結果は揺らぎます。 同じURL・端末区分で繰り返し測り、最高点を選ぶより、指標と原因候補の傾向を確かめてください。

エラーのNO_LCPは何を意味しますか

NO_LCPは、その実行でLCPを取得できなかったことを示し、ページが必ず表示不能という意味ではありません。 当社のトップもLCPとTBTがエラーでしたが、表示を確認し、取れた指標を残して再現条件を調べる対象です。 段階的な表示の影響は候補にとどめ、点数を0点扱いしたり、動きが原因だと断定したりしないでください。

APIは登録不要で使えますか

APIキーなしでも使えますが、当社は登録不要の共有枠で日次上限を示す429エラーとなり、Web画面で測りました。 自分の呼び出しが少なくても利用できるとは限らず、頻繁な自動実行では公式がAPIキーを勧めています。

今回確認した公式資料には、キーなし枠の具体的な回数や、全利用者に共通する料金条件の記載はありません。 具体値を前提にせず、利用するプロジェクトの割り当てを確認し、上限時の再試行も設計してください。

また、PSI APIでのCrUX提供は終了予定と案内されており、実利用者の継続取得には別の設計が必要です。 APIの最新条件と実利用者データの移行先は、Google公式のAPI開始ガイドで確認してください。

Basic認証のページも測れますか

今回測ったのは公開ページであり、Basic認証付きページの対応可否や、認証を渡す方法は検証していません。 本記事の結果をそのまま当てはめず、認証を保って検証できる方法を、制作・開発担当者と確認してください。