PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) は、ページを2つの異なる方法で評価する無料のGoogleツールです。実際の訪問者が実際に体験した方法（フィールドデータ）と、単一のシミュレーションテストの実行結果（0〜100のラボスコア）です。0〜100の数字は誰もが気にするものですが、Googleがランキングに使用するものではありません。赤いスコアを見ても慌てないでください。

PageSpeed Insightsとは

PageSpeed Insightsはpagespeed.web.devにあります。無料で、ログインは不要で、競合他社を含むあらゆる公開URLで動作します。URLを貼り付けると、モバイルとデスクトップの両方をテストします（モバイルがデフォルトのタブで、モバイルのスコアはほぼ常に低くなります）。

PSIが表示する2つのこと

ここが皆さんを混乱させる部分なので、シンプルに説明します。PSIは同じページに対して2つの別々のレポートを表示します。

1. フィールドデータ — 実際のユーザーが体験したこと。 これはChrome UX Report（CrUX）からのもので、過去28日間にあなたのページを訪れた実際のChromeユーザーのデータです。*「実際のユーザーが体験していることを発見」*というセクションです。ここでCore Web Vitals評価 — シンプルな合格または不合格 — が得られます。
2. ラボデータ — 1回のシミュレーションテスト。 PSIはGoogle Lighthouseをシミュレートされた携帯電話とネットワークで1回実行し、0〜100のパフォーマンススコアと修正提案のリストを出力します。

覚えておくべきこと

0〜100のスコアはランキング要因ではありません。 GoogleはフィールドのCore Web Vitals — Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shift — を実際のユーザーから測定してランキングします。0〜100のラボスコアは、別のシステムからの別の数字です。72点でもCore Web Vitalsに合格できます。

他にも人々がつまずく点がいくつかあります：

• スコアは実行するたびに変わります。 1回のシミュレーションテストなので、数字は変動します。数回実行して、3〜5ポイントの変動に一喜一憂しないでください。
• 100点は必要ありません。 100点を取る人はほとんどいません。完璧な数字を目指すのではなく、Core Web Vitalsに合格することを目指してください。
• 良いスコアは実際のユーザーにとって速いページを保証するものではなく、「悪い」スコアは実際のユーザーが苦労していることを意味しません。

正直なところ、サイトが本当に遅いのでなければ、ここから始めるべき場所ではありません。完全な内訳 — フィールドとラボ、p75のしきい値、データのフォールバック、PSIがLighthouseやSearch Consoleとどう違うか — が必要ですか？詳細タブに切り替えてください。

TL;DR — PSI（pagespeed.web.dev）は、1つのURLに対する2つの独立した分析を報告します：フィールドデータはChrome UX Reportからのもので、過去28日間の実際のユーザーを対象とし、75パーセンタイルで合格/不合格のCore Web Vitals評価を決定します。ラボデータは、単一のLighthouse実行で0〜100のパフォーマンススコアと診断情報を提供します。0〜100のスコアはラボデータであり、ランキング要因ではありません。ランキングはフィールドのCore Web Vitals（LCP/INP/CLS）を使用します。フィールドデータには十分なCrUXサンプルが必要です（URLレベル、オリジンレベルにフォールバック、それ以外は「データなし」）。ラボスコアも実行ごとに変動します — 数回実行してください。PSIはWeb UIです。Lighthouseはエンジンです。Search Consoleのレポートはまた別のCrUXビューです。

PSIは1つの画面にある2つのツール

PageSpeed Insightsについて最も重要なのは、1つの分析ではなく、1つの画面に表示される2つの分析だという点です。web.devの説明どおり、PSIは特定ページについてCrUXのフィールドデータとLighthouseのラボデータを報告します。2つは異なるシステムから取得され、異なる対象を測定し、異なる理由で重要です。混同すると、PSIに関するほぼすべての疑問が分かりにくくなります。分けて考えれば、全体を理解できます。

フィールドデータ：実際のユーザーが体験したこと

上部のセクションは “Discover what your real users are experiencing” (翻訳) 「実際のユーザーが体験していることを確認する」で、Chrome UX Report（CrUX）を使用しています。web.devはCrUX APIを “low-latency access to aggregated real-user experience data at page and origin granularity” (翻訳) 「ページおよびオリジン単位で集計された実ユーザー体験データへ低遅延でアクセスできるもの」と説明し、データを “28-day rolling average.” (翻訳) 「28日間の移動平均」としています。PSIは毎日更新され、BigQueryのCrUXデータセットは毎月公開されます。

重要ないくつかの仕組み：

• Core Web Vitals評価はp75で合格/不合格が決まります。 Chromeのドキュメントでは、合格するには3つのCore Web Vitalsすべてでp75が「良好」である必要があり、それ以外は不合格と表示されます。3つの指標は、Largest Contentful Paint（良好 < 2,5秒）、Interaction to Next Paint（良好 < 200ms）、Cumulative Layout Shift（良好 < 0,1）です。PSIはまた、FCP と TTFB を「その他の指標」として表示します — 参考情報ですが、判定の一部ではありません。
• 文書化された例外が1つあり、それはINPのみです。 ページにINPを特に報告するのに十分なCrUXサンプルがない場合、PSIの現在のガイドでは、良好なLCPとCLSのp75値のみから合格/不合格を評価できるとされています。LCPまたはCLSに相当する例外はありません — これらのいずれかがデータ不足の場合、それを合格と解釈しないでください。データ不足は、INPを除くいずれの指標でも文書化された無条件の合格にはなりません。
• p75は75パーセンタイルを意味します。 表示される値は、ページビューの75%がこれより速かった体験です。web.devは、外れ値の影響を受けにくくするため75パーセンタイルを選択しました — 中央値よりも厳しい目標です。
• INPは2024年3月にFIDを置き換えました。 古いスクリーンショットや古いガイド（PageSpeed Insightsに関する私自身の以前のAhrefsの記事やCore Web Vitalsを含む）を見ている場合、それらにはまだFIDが表示されている可能性があります。評価では現在INPが使用されています。
• URL → オリジン → 「データなし」のフォールバック。 特定のURLに対して十分なCrUXデータがない場合、PSIはオリジンレベルのデータ（サイト全体で集計）にフォールバックします。CrUXデータがまったくない場合は、「データなし」 が表示されますが、Lighthouseは引き続き実行されます。web.devの説明どおり、CrUXデータを利用できるのはサイトが一定の適格性基準を満たす場合だけで、PSIの対象も公開URLに限られます トラフィックの少ないページや新しいページには、URLレベルのフィールドデータがないことがよくあります。

所見を書く前にスコープラベルを読んでください。URLレベルのCrUXは、そのURLに帰属する適格なフィールドサンプルを説明します。オリジンレベルのフォールバックはサイト全体の有用なシグナルですが、それだけではテスト対象のページを診断できません。「データなし」は、フィールドサンプルが利用できないか不十分であることを意味します — ページが合格した、不合格だった、またはトラフィックを受けなかったという意味ではありません。以下のLighthouseの結果は、その管理されたラボ実行を診断できますが、欠落しているフィールドデータのギャップを埋めるものではありません。

ラボデータ：0〜100のLighthouseスコア

下部のセクションは、シミュレートされたデバイスとネットワークでの単一のLighthouse実行であり、パフォーマンススコアと改善機会・診断情報の一覧を生成します。Googleの区分では、90以上が「良好」、50〜89が「改善が必要」、50未満が「不良」です。

ラボ実行について知っておくべきこと：

• これはシミュレーションであり、モバイル実行は意図的に遅くされています。 モバイルは スロットルされた接続でミッドレンジの電話をエミュレートします。デスクトップはより高速なエミュレートされたプロファイルを使用します。 そのため、モバイルのスコアはほぼ常にデスクトップより低くなります — そして、 実際のユーザーのフィールドデータがラボの診断結果よりも良く見えることが多い理由でもあります。
• スコアは変動します。 各実行は新しいサーバーサイドのLighthouse監査です — ページ、Googleのデータセンター、ネットワーク状況、さらにはChrome/Lighthouseの バージョンも、実行間で数値を変動させる可能性があります。数回（3〜5回）実行して、 単一の実行を絶対的なものとして扱うのではなく、範囲を見ることをお勧めします。 数ポイントの変動はノイズです。
• 実行を比較する場合は、スコア以上のものを保存してください。 APIレスポンスには タイムスタンプ、要求されたURLと最終URL、フォームファクター、エミュレートされた環境、 Lighthouseバージョン、および警告が含まれています — 各スコアと一緒にそれらを保持してください。2つの 「72」は、一方が異なるLighthouseバージョンで実行されたり、もう一方が経験しなかった リダイレクトにヒットした場合、比較できません。ラベルのないスコアを平均化しないでください。ラベルを付けるか、比較しないでください。
• LighthouseバージョンはPSI APIとは独立して動きます。 PSIはAPI v5のままでしたが、その下にあるLighthouseエンジンは新しいリリースを出し続けています（ このレビューの時点でGoogleのリリースノートに記載されている最新はLighthouse 13.0、2025-10-20付け）— 監査フィールド、重み、およびバンドは、APIコントラクトが変更されなくても、 エンジンバージョンとともにシフトする可能性があります。
• 「推定節約量」は加算的ではありません。 各診断の横に表示される秒数は、 その修正が単独で行われることを前提としています。問題は相互作用します。実際の利益は ほぼ常に個々の推定値の合計よりも少なくなります。それらを方向性として扱い、合計できる予算としては扱わないでください。
• メトリックの重みはLighthouseバージョンによって変わります。 Performanceスコアは ラボメトリックの加重ブレンドです（読み込み時間メトリック、Total Blocking Time、CLSが 最も重い重みを持ちます）が、正確な重みはLighthouseリリース間でシフトします — 固定された分割を信頼するのではなく、現在のスコアリング計算機を確認してください。

最も大きな損害をもたらす神話：「スコアはランキング要因である」

それは違います。0〜100のPerformanceスコアはLighthouseラボの数値であり、 そのスコア自体をランキング入力として文書化したり、スコアの変更をランキングの変更に結び付けたりする現在の公式のGoogle検索ソースは見つかりませんでした。Googleのページ エクスペリエンスのドキュメントは代わりにフィールドCore Web Vitalsを指しています — CrUXベースの 実際のユーザーデータ、PSIのフィールドセクションがp75で表示するのと同じタイプのデータです。 （正確に言う価値のある注意点が1つあります：PSIの公開フィールド表示は、独自の適格性とフォールバックルールを持つレポートサーフェスです。Googleはランキングに供給される正確な内部パイプラインを公開していないため、「フィールドデータ」をPSIが表示するものとバイト単位で同一であると想定するのではなく、同じ種類のシグナルとして扱ってください。） ページはラボで72に留まりながら、実際のユーザーデータが良好であるため、Core Web Vitals Assessmentを合格することができます — 異なるシステムからの異なる数値です。 その派生神話 — 「良いラボスコアは良い実際のユーザーエクスペリエンスと同等である」 — も同じ理由で失敗します：ラボの条件は訪問者の条件ではありません。フィールドとラボが乖離する場合、フィールドデータがSEOにとってより関連性の高いものです。

そして、フィールドのCore Web Vitalsでさえ、かなり小さなランキング入力です。Google自身の 人々はそれらを軽視しています — Gary Illyesはページエクスペリエンスを主要なシグナルというよりはタイブレーカーに近いと呼んでいます。私の正直な立場は変わっていません：Core Web VitalsがSEOに大きな影響を与えるとは思っていません。サイトが極端に遅い場合を除いて、コンテンツやリンクよりもそれらを修正することを一般的に優先しません。ユーザーのため、そして本当に遅いケースのために修正してください — 赤い数字へのパニックからではありません。

PSIレポートを実際に読む方法

1. まずフィールドデータを読む。 Core Web Vitals アセスメントで 合格 か 不合格 か？それがSEOに関わる判定です。「データなし」と表示された場合は、CrUXのトラフィックがまだ十分でないということです。ラボデータのみで作業していることになります。
2. モバイルとデスクトップを別々に確認する。 モバイルがデフォルトで、通常は弱い方です。また、Googleはモバイルファーストでインデックスするため、モバイルが主に重要です。
3. 次にラボ診断を使って原因を特定する。 ラボデータは、根本的な問題（レンダリングをブロックするリソース、過大な画像、レイアウトシフトの原因、長時間タスク）を見つけて修正するための迅速なフィードバックループです。
4. 修正してから待つ。 フィールドデータは28日間のローリングウィンドウなので、今日リリースした修正がCore Web Vitalsアセスメントに完全に反映されるまで最大28日かかることがあります。ラボデータで修正を即座に確認し、フィールドデータで実際にユーザーに影響があったかを確認します。
5. 競合他社をベンチマークする。 PSIは公開URLならどこでも動作するため、競合他社のページを実行して、自社のフィールドCore Web Vitalsと比較できます。これはほとんどのガイドが言及しないユースケースです。

PSIと混同されがちなツールとの比較

• PSIとLighthouseの比較。 Lighthouseはエンジンであり、PSIはLighthouseを実行し、その上にCrUXフィールドデータを重ねるWeb UIです。Lighthouseを自分で実行すると（Chrome DevToolsまたはCLIで）、ラボ監査は得られますが、自分のマシンとネットワーク上で、フィールドデータなしで実行されます。
• PSIとSearch ConsoleのCore Web Vitalsレポートの比較。 どちらもCrUXベースなので、どちらも実際のユーザーを反映します。違いは、Search Consoleは類似したURLをグループ化し、サイト全体でスケールしてレポートするのに対し、PSIはURLごと（またはオリジンレベルのフォールバック）です。GSCとPSIが一致しないように見える場合、通常はグループ化が原因です。
• PSIとChrome DevTools / WebPageTest / DebugBear / Ahrefs Site Auditの比較。 これらはより多くの設定（カスタムデバイス、ロケーション、スロットリング）を提供し、場合によっては実ユーザーモニタリングも提供します。PSIの強みは、無料で、セットアップ不要で、Google自身のCrUXデータセットに結びついていることです。

PSI API（一括テスト用）

Web UIを1つのURLずつ使う必要はありません。PageSpeed Insights API（ベース https://www.googleapis.com/pagespeedonline/v5）は、同じデータをプログラムで返します。主要なパラメータ：url（必須）、strategy（mobile または desktop）、category（performance、accessibility、best-practices、seo）。レスポンスはUIと同じように分割されます：loadingExperience（URLレベルのフィールドデータ）、originLoadingExperience（オリジンレベルのフィールドデータ）、lighthouseResult（ラボ監査）。これが、手動でクリックする代わりに、スケジュールでURLのバッチをテストする方法です。

このAPIで永続的なフィールドデータ自動化を構築しないでください。 Google自身のAPIドキュメントは現在、PSI APIにCrUXの実世界データを含めることを廃止する予定であるという通知で始まり、自動化ツールを専用のCrUX APIまたはCrUX History APIに誘導しています。Lighthouseラボ監査にはPSI APIを使い続けてください。その部分は影響を受けません。ただし、一括フィールドデータ取得をスケジュールする場合は、PSIレスポンスのloadingExperience/originLoadingExperienceではなく、CrUX固有のAPIに対して構築してください。

ウェブパフォーマンスにおける位置づけ

PSIは測定ツールであり、目的地ではありません。それが表面化する指標（Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shift）はCore Web Vitalsであり、それらのハブ（しきい値、各指標の意味、改善方法）が次に進むべき場所です。LighthouseはPSIが実行するラボエンジンであり、CrUX（Chrome UX Report）はすべてのPSIレポートの上部に供給されるフィールドデータソースです。これら3つを理解すれば、PSIは謎の箱ではなくなります。

AIまとめ

Advancedバージョンの簡潔な見解:

• PSIは1つのUIに2つのツールを統合。 Chrome UX Reportからのフィールドデータ（実際のユーザー）と、同じURLに対する単一のLighthouse実行からのラボデータを、pagespeed.web.devで提供。無料、ログイン不要、任意の公開URL、モバイル＋デスクトップ対応。
• フィールドデータはCore Web Vitals評価を駆動 — 合格/不合格、75パーセンタイル、LCP（<2,5秒）、INP（<200ms）、CLS（<0,1）にわたる。28日間のローリングウィンドウ、毎日更新。FCPとTTFBは表示されるが、判定にはカウントされない。
• ラボデータは0〜100のパフォーマンススコア（90以上が良好、50〜89が改善が必要、<50が不良）に診断情報を加えたもの。モバイルはスロットリングされ、デスクトップよりスコアが低くなる。
• 0〜100のスコアはランキング要因として文書化されていません。 GoogleのランキングシステムはフィールドのCore Web Vitals（CrUXベースの実ユーザーデータ — PSIのフィールドセクションが表示するのと同じタイプのデータ。ただし、Googleは正確な内部パイプラインがPSIの公開表示と同一であるとは公表していない）を使用。ページが72点でもCWVに合格できる — 異なるシステムからの異なる数値。
• CrUXのフォールバック： URLレベル → オリジンレベル → 「データなし」（Lighthouseは引き続き実行）。トラフィックが少ないページや新しいページには、URLレベルのフィールドデータがないことが多い。
• スコアは実行ごとに変動 — 3〜5回実行すること。「推定削減量」は加算されません。 100点は必要ありません。
• 最初にフィールドデータを読む（合格/不合格）、次にラボ診断を使って原因を特定。修正を公開し、フィールドデータに反映されるまで最大28日間待つ。
• PSIとLighthouseの比較（エンジン vs. UI＋フィールド）、およびSearch ConsoleのCWVレポートとの比較（こちらもCrUXベースだが、スケールでグループ化）。CWVは全体的にマイナーなランキング入力。

公式ドキュメント

GoogleおよびChrome / web.devチームからの一次情報源のドキュメント。

Google / PageSpeed Insights

• PageSpeed Insightsツール — ツール自体。
• PageSpeed Insights API — 概要 — PSIが行うこと、2つのデータタイプ、0〜100のスコア帯。
• PSI API — runPagespeedリファレンス — パラメータ（url、strategy、category）とレスポンス構造。

Chrome UX Report（フィールドデータのソース）

• PageSpeed InsightsでのCrUXの使用 — フィールドセクションの仕組みと合格/不合格の評価。
• CrUXの方法論 — 対象条件、オプトイン、含まれるページ。
• CrUX API — PSIのフィールドデータを支える28日間のローリング平均。
• CrUXの概要 — CrUXがページエクスペリエンスのランキングシグナルにどのように貢献するか。

web.dev / Core Web Vitals

• Core Web Vitalsツールとは？ — CrUX/Lighthouseツール群の中でのPSIの位置付け。
• Core Web Vitals — LCP/INP/CLSのしきい値と75パーセンタイルのルール。
• Core Web Vitalsのしきい値の定義 — p75の理由。
• Core Web VitalsとGoogle検索 — ランキングシグナルのコンテキスト。

ソースからの引用

逐語的な記述。それぞれソースページの該当箇所にリンクされています。

Google / Chrome / web.dev — PSIの仕組み

• “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (翻訳) 「PSIは、特定のページについてCrUXのフィールドデータとLighthouseのラボデータを報告するツールです。」 — web.dev。 引用元へ移動
• “PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.” (翻訳) 「PSIは公開URLでのみ利用できます。一般公開されていない開発サイトでは使用できません。」 — web.dev。 引用元へ移動
• フィールドセクションは “Discover what your real users are experiencing.” (翻訳) 「実際のユーザーが体験していることを確認する」と説明されています。 — Chrome開発者向け資料「PSIでCrUXを使用する」。 引用元へ移動
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” (翻訳) 「合格するには、3つのCore Web Vitalsすべてでパーセンタイルが『良好』に分類される必要があります。それ以外の場合、評価は『不合格』と表示されます。」 — Chrome開発者向け資料「PSIでCrUXを使用する」。 引用元へ移動
• CrUX APIは “low-latency access to aggregated real-user experience data at page and origin granularity” (翻訳) 「ページおよびオリジン単位で集計された実ユーザー体験データへの低遅延アクセス」を “28-day rolling average.” (翻訳) 「28日間の移動平均」として提供します。 — Chrome開発者向けCrUX API資料。 引用元へ移動

web.dev — しきい値

• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (翻訳) 「測定に適したしきい値は、モバイル端末とデスクトップ端末に分けたページ読み込みの75パーセンタイルです。」 — web.dev、Core Web Vitals。 引用元へ移動
• “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance.” (翻訳) 「サイトへのページビューの少なくとも75パーセントが『良好』のしきい値を満たす場合、そのサイトは『良好』なパフォーマンスに分類されます。」 — web.dev、しきい値の定義。 引用元へ移動

業界 — スコアとランキングの区別 (伝聞であり、Googleの見解ではない)

• “The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings.” (翻訳) 「PageSpeed InsightsのパフォーマンススコアはSEOへ直接影響しません。一方、実ユーザーのCore Web Vitals評価はGoogleのランキングへ影響します。」 — Matt Zeunert、DebugBear。 出典
• “Core Web Vitals are the only metrics Google explicitly uses for grading.” (翻訳) 「Core Web Vitalsは、Googleが評価に使用すると明示している唯一の指標です。」および “Running the same URL just minutes apart can yield different scores.” (翻訳) 「同じURLでも数分間隔で実行すると、異なるスコアになることがあります。」 — Ryan Sullivan、SiteCare。 出典

PSIレポートの早見表

PSIの各セクション: フィールドデータかラボデータか、そしてその意味

Core Web Vitalsの「良好」しきい値 (フィールドデータ、p75)

Lighthouseスコアのバンド (ラボデータ)

• 90–100 — 良好 · 50–89 — 改善が必要 · <50 — 不良

フィールドデータのフォールバック

• URLレベルのCrUX → 十分でない場合はオリジンレベル → ない場合は**「データなし」**（Lighthouseは引き続き実行されます）。

早わかり

• フィールドデータは直近28日間のローリング集計で、毎日更新されます → 修正が反映されるまで最大28日かかることがあります。
• 0〜100のスコアは変動します — 3〜5回実行し、3〜5ポイントの変動は無視してください。
• 「推定削減量」は合算できません — 各修正が単独で行われることを前提としています。
• モバイルがデフォルトのタブで、通常はデスクトップより低いスコアになります。
• INPは2024年3月にFIDを置き換えました。

PSI関連ツール

• PageSpeed Insights（pagespeed.web.dev）— ツール自体：フィールドデータ（CrUX）+ ラボデータ（Lighthouse）、モバイルとデスクトップ、任意の公開URLに対応。
• Google Lighthouse — PSIが実行するラボエンジン。Chrome DevTools（Lighthouseパネル）でローカルに実行するか、CLI経由で自分のデバイス/ネットワーク上でラボ監査を実行（フィールドデータなし）。
• Google Search Console — Core Web Vitals レポート — もう一つのCrUXベースのビュー。類似URLをグループ化し、プロパティ全体のフィールドデータを報告。
• CrUX Vis / CrUX API / BigQuery — PSIの背後にあるフィールドデータに直接アクセスし、経時的なトレンドを確認。（旧CrUX Dashboard（Looker Studio）は2025年11月末に廃止されました — Google自身のリリースノートと専用の廃止告知の両方が日付を確認し、後継としてCrUX Vis（cruxvis.withgoogle.com）を指しています。Dashboardの使用を指示するガイドがあれば、それは古い情報です。）
• PSI API — 多数のURLをプログラムで一括テスト（url、strategy、category）。レスポンスはloadingExperience、originLoadingExperience、lighthouseResultに分割されます。GoogleはこのAPIからCrUX実ユーザーデータの提供を段階的に廃止する計画を発表しており、永続的なフィールドデータ自動化には専用のCrUX APIまたはCrUX History APIを推奨しています — PSI APIのフィールドオブジェクトが長期的に存続することを前提にパイプラインを構築しないでください。
• Ahrefs Site Audit および WebPageTest / DebugBear — より多くの設定が必要で、場合によっては単一のLighthouse実行を超えた実ユーザーモニタリングを提供。

優先順位を歪めるPageSpeed Insightsの誤用

• 0〜100のスコアをランキング要因として扱うこと。 スコアはLighthouseのラボ実行1回分です。ランキングに関連するCore Web Vitalsの評価はCrUXフィールドデータから得られます。
• オリジンフォールバックをURLのパフォーマンスとして読むこと。 URLのサンプル数が不足している場合、PSIはオリジンレベルのデータを表示することがあります。ページ自体が合格または不合格だと主張する前に、スコープラベルを確認してください。
• ラボ実行1回に反応すること。 サーバーレスポンスと合成環境は変動します。一致する実行を繰り返し、範囲または中央値を使用してシグナルとノイズを区別してください。
• 改善機会の削減量を合算すること。 監査の見積もりは重複しており、各修正が独立して行われることを前提としています。それらを約束された合計ではなく、方向性を示す手がかりとして扱ってください。
• デプロイがフィールドデータを即座に変更することを期待すること。 CrUXは28日間のローリングビューです。即時の診断にはラボセクションを、時間経過による確認にはフィールドセクションを使用してください。
• モバイルとデスクトップのスコアを同じ条件であるかのように比較すること。 各プロファイルをそれ自体およびオーディエンスに対して評価し、数値を単一の尺度として扱わないでください。

PSIに「データなし」と表示される場合

症状： フィールドセクションにCrUXの結果がないが、Lighthouseレポートは実行される。

考えられる原因： URLとオリジンがCrUXの対象条件またはサンプル量の要件を満たしていないか、ページが新しいかトラフィックが少ない。

修正と確認： フィールドの結論をでっち上げないでください。当面の作業にはラボ診断を使用し、代表的な高トラフィックのテンプレートを確認し、後で戻ってURLレベルまたはオリジンレベルのフィールド結果が表示されるかどうかを確認してください。

PSIとSearch Consoleの結果が一致しない場合

症状： PSIでは健全に見えるURLがSearch Consoleのグループでは不良である、またはその逆。

考えられる原因： PSIはURLレベルまたはオリジンレベルのデータを表示する一方、Search Consoleは類似URLをグループ化します。デバイス、スコープ、ローリングウィンドウのタイミングも異なる場合があります。

修正と確認: モバイル/デスクトップを一致させ、PSIのデータ範囲を検査し、Search Consoleグループから複数のURLをサンプリングしてから、どちらかのレポートが間違っていると結論付けます。

ラボスコアが実行間で変動する

症状: PSIを繰り返すと、スコアやメトリック値が大幅に異なる。

考えられる原因: サーバーレスポンスの変動、サードパーティリクエスト、または通常の単回実行のラボノイズによってトレースが変化した。

修正と確認: 同じストラテジーを複数回実行し、個々のメトリックとリクエストウォーターフォールを比較し、スコアだけでなく繰り返し発生するボトルネックを調査します。

Lighthouseでは修正が見えるが、フィールドデータには反映されない

症状: ラボメトリックはすぐに改善するが、フィールドのCore Web Vitals評価は変わらない。

考えられる原因: CrUXの28日間のローリングウィンドウにリリース前の訪問がまだ含まれているか、修正がフィールドデータセットに含まれるユーザーやテンプレートに効果がなかった。

修正と確認: デプロイとラボトレースを今すぐ確認し、リリース日を注記してから、レポート期間全体を通してフィールド分布を監視します。

APIからPSI結果を1つ取得する

APIはフィールドセクションとラボセクションを別々に公開しています。独自のAPIキーとURLを指定します:

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

テスト日、ストラテジー、データ範囲が監査可能なように、生のレスポンスを保持します。

フィールドスコープをラボスコアから分離する

jqを使用して、URLフィールドカテゴリ、オリジンフォールバックカテゴリ、Lighthouseスコアを1つの数値にまとめるのではなく抽出します:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

フィールド値が欠落していることはゼロを意味しません。それは、そのスコープがレスポンスで利用できなかったことを意味します。

サンプルを隠さずにラボ実行を繰り返す

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

すべてのサンプルまたは文書化された要約を報告します。最良のスコアだけを選択しないでください。

自分でテスト: PageSpeed Insights

PSIを正しく読むための5つの簡単な質問。各質問に回答を選び、確認してください。

時間をかける価値のあるリソース

関連記事

• Google PageSpeed Insights初心者向けガイド — 私のAhrefs解説（注：FIDからINPへの移行前の記事です）。
• Core Web Vitals完全ガイド — フィールドデータとラボデータの比較、およびCWVが実際にどの程度重要かについての見解。
• テクニカルSEO初心者ガイド — パフォーマンスが全体像のどこに位置するか。

公式資料

• PageSpeed InsightsでCrUXを使用する — フィールドセクションに関するChrome自身の解説。
• Core Web Vitalsツールとは？ — PSI、Lighthouse、CrUX、Search Consoleの関係。

他の情報源

• How To Use PageSpeed Insights — Matt Zeunert (DebugBear); スコアと診断に関する高度な技術的詳細。
• PageSpeed Insights: Google’s Highly Misunderstood Diagnostic Tool — Ryan Sullivan (SiteCare); 優れた神話の打破。
• Core Web Vitals Ranking Factor Is More Than A Tiebreaker — Search Engine JournalによるGary Illyes氏のコメントの報道で、CWVの影響を文脈に位置付けています。
• Google Page Experience Update Is More Than A Tie Breaker — SE Roundtable; Barry Schwartz氏による、Google担当者がページエクスペリエンスシグナルをどのように特徴付けてきたかについての報道。

引用に値する統計

• ほぼ誰も100点を取れない。 テストされたページのうち、完璧な100点を取れるのはわずか**約2%**で、50点でもすでに上位25%に入る — 90点未満で焦っている人にとっては有益な情報です。 出典
• フィールドデータは28日間の移動平均です。 修正がCore Web Vitals評価に完全に反映されるまで最大約28日かかることがあります — その間はラボデータを使って迅速なフィードバックを得ましょう。 出典
• 「良好」のしきい値は75パーセンタイルです。 Googleはp75で評価するため、「訪問の大部分が目標レベルのパフォーマンスを経験した」ことになります — つまり、合格ラインのLCP 2,5秒でも、4分の1の訪問者はそれ以上待ったことになります。 出典

変更履歴