PageSpeed Insights（PSI）は、Googleが提供する無料のページ計測ツールです。実ユーザーのChromeから匿名で集めたCore Web Vitalsの実測値（Field Data）と、Googleのサーバー上でLighthouseが計測のたびに走らせる擬似計測（Lab Data）を、同じ画面に並べて表示します。
ただし、読み進める前に押さえておくべき前提が1つあります。2025年10月20日、PSIはLighthouse 13へ更新され、レポートの中身が作り替わりました。長年PSI改善の起点だった「Opportunities（改善できる項目）」というセクションは廃止され、現在は「Insights」という17項目の並びに置き換わっています。ウェブ上に残るPSI解説の大半は、この画面が存在した時代に書かれたものです。
この記事は現行レポートを前提に「どこから読み、どの数字を信じ、その計測結果を信じてよいかをどう判定するか」までを扱います。記載した仕様は、Lighthouseの公開設定ファイルとGoogleの公式リリースノートを直接確認したものです。
- 指標（LCP・INP・CLS）の定義・目標値・優先度は Core Web Vitals改善ガイド へ
- 具体的な実装コード（preload・fetchpriority・Critical CSS等）は ページ速度改善の実装ガイド へ
- ファーストビュー設計とCVRの最適化は ファーストビュー改善ガイド へ
PageSpeed Insightsとは｜ツールの位置づけ
PageSpeed Insightsとは、URLを入力するだけでページの表示速度を診断できるGoogleの無料ツールです。pagespeed.web.dev でアカウント登録なしに利用でき、モバイルとPCそれぞれについて、Core Web Vitalsの合否判定と0〜100点のスコア、そして改善の手がかりになる項目の一覧を返します。
PSI／Lighthouse／CrUXの関係
PSIは単体の計測エンジンではなく、Google製の2つのプロダクトを1枚にまとめたダッシュボードです。ラボ環境の擬似計測はLighthouseが担当し、実ユーザーの体感データはChrome UX Report（CrUX）が供給します。画面上の「Field」がCrUXの集計値、「Lab」がLighthouseの計測値です。PSIが使うLighthouseのバージョンはPSIのリリースノートで公表され、レポート下部にも表示されます。
PSIで測れること・測れないこと
PSIが返すのは「ある1つのURLが、どれくらいの体感速度で表示されているか」です。サーバーログの分析・セッション単位の行動追跡・JavaScriptの実行時エラーの調査には向きません。サイト全体の傾向はSearch Console、フレーム単位の深掘りはChrome DevToolsと組み合わせます。各指標の定義と目標値はCore Web Vitals改善ガイドにまとめています。
2025年10月、PSIのレポートは作り替わった
手順の前に画面の前提を揃えます。ここを知らないまま古い解説を読むと、存在しない項目を探し続けることになります。
「Opportunities」は廃止され「Insights」になった
Chrome for Developersのinsight移行アナウンスのとおり、GoogleはLighthouseの監査項目とDevTools Performanceパネルのinsightを共通化してきました。Lighthouse 12で表示の既定値がinsight側に切り替わり、Lighthouse 13で旧監査がレポートからもJSONからも削除されています。
現在のPerformanceレポートは「Metrics（指標）」「Insights」「Diagnostics（診断）」の3グループ構成です。「Opportunities（機会）」というグループはLighthouse 13の設定ファイルに1件も存在しません。一方でLighthouse 13はスコアの計算式を変更していません。公式ブログが明記しているとおりPerformanceスコアは監査項目ではなく指標から算出されるため、点数の意味は従来と同じです。変わったのは改善のヒントの並べ方だけです。
旧監査名で検索しても出てこない理由
過去の記事や社内ドキュメントに出てくる監査名は、次のように置き換わっています。左の名前で検索しても現行レポートには現れません。対応表はLighthouse 13の公式リリース記事に掲載されたものです。
| いま使われていない旧監査名 | 置き換わった現行のInsight |
|---|---|
| render-blocking-resources | レンダリングをブロックしているリクエスト |
| uses-responsive-images／modern-image-formats／uses-optimized-images／efficient-animated-content | 画像配信を改善する |
| prioritize-lcp-image／lcp-lazy-loaded | LCPリクエストの検出 |
| largest-contentful-paint-element | LCPの内訳 |
| layout-shifts | レイアウトシフトの原因 |
| redirects／server-response-time／uses-text-compression | ドキュメントリクエストのレイテンシ |
| critical-request-chains／uses-rel-preconnect | ネットワークの依存関係ツリー |
| uses-long-cache-ttl | 効率的なキャッシュ保存期間を使用する |
| third-party-summary | サードパーティ |
| uses-http2 | 最新のHTTP |
| work-during-interaction | INPの内訳 |
| offscreen-images／first-meaningful-paint／font-size／no-document-write／preload-fonts／third-party-facades | 置き換えなしで削除 |
とくに注意したいのが最下段です。「offscreen-images（オフスクリーン画像の遅延読み込み）」は代替なしで廃止されました。公式の理由は「オフスクリーン画像はブラウザ側ですでに優先度が下げられており、遅延読み込みは通信量の削減には効いてもLighthouseの計測値には影響しにくいため」です。この項目の消化を目標に置いていたなら、目標ごと差し替えが要ります。
Lab DataとField Dataの違い｜PSI攻略の最重要ポイント
レポート上部の「実際のユーザー環境で評価する（Field Data）」と、その下の「パフォーマンスの問題を診断する（Lab Data）」は、取得元・集計方法・反映タイミングがまったく異なるデータです。ここを混同したままスコアを追うと、改善作業が空回りします。
Lab Data（Lighthouse）とは
Lab Dataは、PSIのサーバー上でLighthouseが計測のたびに擬似ブラウザでURLを読み込み、その場で算出する数値です。回線速度・端末性能・キャッシュ状態をGoogle側が固定するため再現性が比較的高く、Performanceスコア（0〜100）とその内訳のメトリック群として表示されます。コードを直した直後に測り直せることが最大の利点です。
Field Data（CrUX）とは
Field Dataは、実際にページを訪れたChromeユーザーから匿名で集計された体感データで、Chrome UX Report（CrUX）が公開しています。Chrome公式ドキュメントによると、CrUXのデータは直近28日間のローリングウィンドウで集計され、各指標は75パーセンタイル値で評価されます。最も遅い層を切り捨てずに現実的な体験品質を反映できる設計です。Search Consoleの「ウェブに関する主な指標」も同じCrUXを参照しています。
比較表とどちらを信じるべきかの結論
| 観点 | Lab Data（Lighthouse） | Field Data（CrUX） |
|---|---|---|
| 取得元 | PSIサーバー上の擬似ブラウザによる1回計測 | 実ユーザーのChromeから匿名収集 |
| 集計期間 | リアルタイム（計測のたび1回ごと） | 直近28日間のローリング集計 |
| スコアに算入される指標 | FCP／LCP／TBT／CLS／Speed Index | スコアではなくGood／要改善／不良の判定 |
| 表示される指標 | 上記＋INP（Lighthouse 13.1以降・スコア非算入） | LCP／INP／CLS／FCP／TTFB |
| 反映タイミング | 即時（コード修正後すぐ再計測可能） | 反映に最大28日かかる |
| 出ない場合 | 必ず出る（合成計測のため） | トラフィック不足だと「データ不足」表示 |
| SEO評価との関係 | 直接の評価対象ではない | Core Web Vitalsの判定根拠 |
結論は「実ユーザーへの反映を見届けるのはField、日々の実装検証はLab」という役割分担です。Fieldは反映まで最大28日かかるため、実装フェーズはLabで方向性を確認し、リリース後にFieldで着地を確認する二段構えが現実的です。
Lighthouseの4カテゴリとスコアの読み方
現在のPSIレポートは、Performance・Accessibility・Best Practices・SEOの4カテゴリで構成されます。5つ目にあったPWAカテゴリは、2024年5月10日のLighthouse 12.0への更新とともに廃止されました。「PSIのPWAスコア」を追う運用ルールが残っているなら、それは2年前に消えた指標です。
Performanceスコアの構成と重み付け
Performanceは5つの指標の加重平均です。Chrome for Developers「Lighthouse performance scoring」に記載された重み付けは次のとおりで、Lighthouse 13でも変更されていません。
| メトリック | 重み | 意味するもの |
|---|---|---|
| FCP（First Contentful Paint） | 10% | 最初のコンテンツが描画されるまでの時間 |
| LCP（Largest Contentful Paint） | 25% | メインコンテンツが描画されるまでの時間 |
| TBT（Total Blocking Time） | 30% | メインスレッドのブロック時間の合計 |
| CLS（Cumulative Layout Shift） | 25% | 累積レイアウトシフト量 |
| Speed Index | 10% | ビューポート全体が視覚的に完成するまでの速度 |
PerformanceスコアはTBT 30%・LCP 25%・CLS 25%で8割を占めるため、点数を動かしたいならこの3つから着手するのが効率的です。FCPとSpeed Indexは各10%しか持っていません。なおINPについては、Lighthouse 13.1以降のMetricsグループに並びますが重みは0＝スコアには算入されません。Lab側のTBTはあくまで「メインスレッドの詰まり」を測る代理指標であり、Core Web VitalsとしてのINPはField側で判定されます。両者は連動しやすいものの、同一の指標ではありません。
Performance以外の3カテゴリの役割
Accessibilityはスクリーンリーダー対応やコントラスト比、Best PracticesはHTTPSの利用・非推奨APIの不使用・コンソールエラー、SEOはmeta descriptionやモバイルフレンドリー要件を評価します。いずれもPerformanceスコアには影響しません。ただしAccessibilityで赤い項目が並ぶ場合は、検索評価以前にユーザビリティの問題があるサインです。
総合スコア（0〜100）の評価帯
| 総合スコア | 評価 | 表示色 | 一般的な状態 |
|---|---|---|---|
| 90〜100 | Good | 緑 | 上位優良。維持を目標にする帯 |
| 50〜89 | Needs Improvement | オレンジ | 改善余地あり。多くのサイトがこの帯に分布 |
| 0〜49 | Poor | 赤 | 早急な改善が必要 |
この3段階はChrome for Developersのスコアリング解説で定義された共通基準です。「何点を目指すか」の実務的な答えは「Lab側の点数より、Field側の3指標が不良（Poor）を抜けることを先に置く」になります。Labが90以上でもFieldで不良判定が出ることは珍しくなく、逆にLabが80点台でもFieldが全てGoodなら体験としては問題ありません。目標値の根拠はCore Web Vitals改善ガイドで扱っています。
モバイルとPCでスコアが大きく違う理由
ほぼすべてのサイトで、PSIのモバイルスコアはPCを下回ります。実装が悪いとは限らず、モバイル計測の前提条件が意図的に厳しく設定されていることに由来します。
モバイル計測の前提（Slow 4G＋中位Android端末）
Lighthouse 13の設定ファイルでは、モバイル計測の既定値はSlow 4G相当の回線スロットリング（往復遅延150ms・下り1.6Mbps）と、412×823ピクセル・moto g power (2022) のユーザーエージェントによるエミュレーションです。基準端末として広く紹介されてきたMoto G4は、すでに置き換えられています。
CPUスロットリングには注意が必要です。Lighthouseの既定値は4倍ですが、PSI本番環境の係数は2024年12月5日に調整されており、既定値と同じとは限りません。PSIのリリースノートは「PSI本番環境で典型的な低いCPUベンチマークを踏まえて係数を調整した。一般にモバイルのLab TBTは上昇し、Field DataとPCスコアには影響しない」と説明していますが、調整後の具体的な倍率は公表されていません。「PSIは常に4倍スローダウン」と断定した解説は、この更新以前の情報です。
モバイルとPCの差はどこまでが正常か
Googleは「差が何点なら正常」という基準を公表していません。本サイトの運用では、差の大きさではなくボトルネックの種類で切り分けています。モバイルだけ極端に低いときは、JS実行時間（TBT）が主因か画像の重さ（LCP）が主因かを先に判別してください。画像側が主因なら、配信サイズの最適化はpicture要素とsrcsetによる画像出し分け、圧縮はブラウザ完結の画像圧縮ツールで確認できます。
検索の評価はモバイル版ページが基準になる
Google検索セントラルは2023年10月31日の公式ブログでモバイルファーストインデックスへの移行完了を告知しました。現在のGoogle検索はモバイル版ページを基準にクロールとインデックスを行います。PCで90点でもモバイルが不良判定なら、見られているのはモバイル側です。PSIで最初に開くべきタブもモバイルです。
現行レポートを4ステップで読む
PSIを上から順に読むと、効果の小さい項目に工数を吸い取られます。Field Data → Metrics → Insights → Diagnostics の順に降りるのが現行レポートでの正しい読み方です。
ステップ1：Field Dataで実ユーザーの困りごとを特定する
最初に見るのは画面最上部のField Dataです。LCP・INP・CLSのうち、不良（赤）または要改善（オレンジ）の指標を特定します。CrUXは75パーセンタイルで判定するので、赤が付いた指標は実ユーザーの4人に1人以上が基準を割っているという意味です。Fieldが全てGoodなら、Lab側の磨き込みは緊急ではありません。
ステップ2：Metricsで、どの指標が点数を削っているかを見る
旧Opportunitiesが担っていた「効果の大きい順」という入口は、現行レポートにありません。代わりの入口がMetricsです。Performanceスコアは指標から計算されるので、重み（TBT 30%・LCP 25%・CLS 25%）と実測値を突き合わせれば、どこが点数を削っているかが一意に決まります。ここで当たりを付けてから、次のInsightsへ降ります。
ステップ3：Insightsを、狙った指標に効くものだけ開く
Insightsは17項目が並びますが、効果の大きい順には並んでいません。旧Opportunitiesの「推定短縮ミリ秒による並べ替え」は無くなり、各insightが「どの指標のどの区間が長いか」を分解して見せる形になりました。上から順に潰すのではなく、ステップ2で決めた指標に効くinsightだけを開くのが正しい使い方です。対応は次章の早見表にまとめました。
ステップ4：影響度と実装コストで並べ替えてから着手する
候補が出そろったら「影響度×実装コスト」で並べ替えます。画像フォーマットの変換は影響度が大きくコストが小さいので先頭、レンダリング方式の変更はコストが極大なので長期計画、といった判断です。Critical CSSのインライン化を実際に適用して計測した記録はCritical CSSインライン化の実測ケーススタディにあります。
Insights 17項目とDiagnosticsの読み方
PSIの日本語表示では、Insightsの項目名も日本語になります。ここでは実際に表示される日本語名で17項目を一覧化します。項目名はLighthouse 13の設定ファイルと日本語ロケールファイルで確認したものです。
Insights 17項目の早見表
| 表示名（日本語） | 主な影響指標 | 典型的な対処方針 |
|---|---|---|
| レンダリングをブロックしているリクエスト | FCP／LCP | クリティカルCSSの分離・JSのdefer／async |
| LCPの内訳 | LCP | TTFB・読み込み・描画のどこが長いかを特定 |
| LCPリクエストの検出 | LCP | LCP画像のpreload・fetchpriority・遅延読み込み解除 |
| 画像配信を改善する | LCP | 適正サイズ配信・WebP／AVIF化・圧縮 |
| ドキュメントリクエストのレイテンシ | FCP／LCP | サーバー応答の短縮・リダイレクト削減・テキスト圧縮 |
| ネットワークの依存関係ツリー | LCP | 連鎖リクエストの短縮・preconnect |
| 効率的なキャッシュ保存期間を使用する | 再訪時のLCP | Cache-Controlの長期化 |
| 最新のHTTP | LCP | HTTP/2・HTTP/3への移行 |
| レイアウトシフトの原因 | CLS | 幅高さの明示・アスペクト比指定・挿入要素の領域確保 |
| ビューポートをモバイル向けに最適化する | CLS／INP | meta viewportの適正化 |
| フォント表示 | FCP／CLS | font-displayの指定・フォント読み込みの見直し |
| INPの内訳 | INP | 入力遅延・処理時間・描画のどこが長いかを特定 |
| 強制リフロー | INP／TBT | レイアウトの読み取りと書き込みの分離 |
| 重複するJavaScript | TBT／INP | バンドル内の重複排除 |
| 以前のJavaScript | TBT／INP | 不要なpolyfill・過剰なトランスパイルの削減 |
| サードパーティ | TBT／INP／LCP | タグの削減・遅延読み込み・読み込み位置の見直し |
| DOMサイズを最適化する | TBT／INP | 要素数の削減・リストの仮想化 |
「サードパーティ」が上位に出るなら、まずタグの読み込み位置を疑ってください。Google Tag Managerの設置位置がレンダリングに与える影響はGTMの設置位置と表示速度の関係で検証しています。個別のinsightをどう直すかはページ速度改善の実装ガイドの担当で、本記事は「どのinsightを開くか」までを担います。
Diagnosticsはスコアに直接は効かない情報
Insightsの下に並ぶDiagnosticsについて、Lighthouseは説明文で「これらの数値はPerformanceスコアに直接は影響しない」と明示しています。中身は、CSS／JavaScriptの最小化、未使用CSS／JavaScriptの削減、過大なネットワークペイロード、JavaScriptの実行時間、メインスレッド処理、長時間タスク、合成されていないアニメーション、画像のwidth／height未指定、バックフォワードキャッシュの阻害などです。
つまりDiagnosticsを潰しても点数は動かないことがあります。ただし「未使用JavaScriptの削減」のように結果としてTBTを押し下げる項目もあるため、Insightsを片付けても伸び悩むときの次の一手として使うのが適切です。
そのPSIの数字を信じてよいか｜5回計測の振れ幅で判定する
最後に、その数字を根拠に「改善した／していない」と言ってよいかを自分で判定する手順を用意します。Lab Dataは1回ごとの合成計測なので、コードを1行も変えなくても数値は上下します。振れ幅を知らないまま前後比較をすると、ノイズを成果と読み違えます。
手順｜モバイルで5回続けて計測し、振れ幅を出す
- 対象URLを pagespeed.web.dev でモバイル指定のまま計測する
- Performanceスコアと TBT の2つを記録する
- コードを一切変えないまま、間を空けずに合計5回繰り返す
- 5回のスコアの最大値から最小値を引く。これがそのURLの振れ幅
- 5回の中央値を「現在値」として採用する（平均値は外れ値に引っ張られるため使わない）
合否ライン｜振れ幅が「信じてよい変化量」を決める
| 振れ幅（5回の最大−最小） | 判定 | この計測でできること |
|---|---|---|
| 0〜5点 | 合格 | 中央値をそのまま基準値にしてよい |
| 6〜10点 | 条件付き合格 | 基準値には使えるが、10点未満の変化を「改善した」と判断してはいけない |
| 11点以上 | 不合格 | 計測が不安定。まずサードパーティスクリプトを切り分ける |
この3段階はGoogleが定義した基準ではなく、本サイトが施策の可否を判断するために置いている運用基準です。数字そのものより「自分のサイトの振れ幅を先に測り、それを下回る変化は成果と呼ばない」という運用に意味があります。振れ幅が11点以上になるのは、広告や計測タグの応答時間が計測ごとに大きく変動しているのが典型的な原因です。
施策の効果はこう判定する
- 振れ幅以下の変化＝効果なしと同義。実装を戻すか、別の指標を狙い直す
- 振れ幅を超える改善＝Lab上は効果あり。ただしまだSEO上の成果ではない
- 28日後にFieldの3指標がGood化＝ここで初めて実ユーザーに届いた成果と言える
思ったとおりに動かないときの切り分け
| 状況 | 意味 | 次の一手 |
|---|---|---|
| Labは改善・Fieldは未変化（28日以内） | 正常。CrUXは28日ローリング集計 | 待つ。Search Consoleで日次推移を見る |
| 28日を過ぎてもFieldが動かない | Labで直した箇所が、実ユーザーのボトルネックではない | Field側で不良の指標に戻り、その指標のinsightを開き直す |
| Labのスコア自体が動かない | 変化量が振れ幅に埋もれている | 先に振れ幅を下げる。またはTBTなど個別指標の変化で判断する |
| Fieldが「データ不足」のまま | CrUXの母数が足りていない | Lab運用に切り替え、中央値の推移で管理する |
切り分けはここで止めます。各insightの中身を実際にどう直すかは、この記事の担当範囲ではありません。特定できた項目を持ってページ速度改善の実装ガイドへ進んでください。
スコアが「動かない・反映されない」ときの確認ポイント
前章の切り分け表で扱いきれない、仕組み由来のトラブルをまとめます。大半はPSI・Lighthouse・CrUXの役割分担を知っていれば説明がつく現象です。
Field Dataがそもそも出ない
「データ不足のため、このページの実際の速度を表示できません」と出るケースです。主因はトラフィック不足、または公開直後で集計が間に合っていないことです。Field DataはCrUXへの計上条件を満たすだけの訪問が必要で、立ち上げ直後の小規模サイトでは表示されないのが普通です。URL単位の代わりにオリジン単位の集計値が表示されることもあります。
自分のブラウザでは速いのにPSIが遅いと言う
自分の環境では2回目以降の読み込みがブラウザキャッシュに当たるため速く感じますが、PSIのLighthouseは毎回キャッシュを持たない状態から計測します。体感とPSIが食い違うときは、まず自分の環境をキャッシュなしに揃えて比べてください。手順はスーパーリロードとキャッシュクリアの手順にまとめています。CDN側のキャッシュを更新し忘れ、PSIだけが古いファイルを見ているケースもここで見つかります。
PSIとSearch Consoleで違う数値が出る
両者は同じCrUXを参照しますが、PSIは「URL単位またはオリジン単位」、Search Consoleは「似た構造のURLをまとめたグループ単位」で集計します。切り口が違うので、数値が一致しないのが正しい挙動です。個別ページの現状確認はPSI、サイト全体の推移監視はSearch Consoleと使い分けてください。
PSI以外の補完ツールと使い分け
PSIは起点として優れていますが、深掘りと継続監視には別のツールが要ります。
| ツール | 強み | 主な用途 |
|---|---|---|
| PageSpeed Insights | Field＋Labを1画面で確認できる | 全体俯瞰・改善の起点 |
| Chrome DevTools | フレーム単位のプロファイリング・ローカル実行 | 実装中の検証・ステージング確認 |
| WebPageTest | 多拠点・多回数・フィルムストリップ | 地理的検証・回線条件の比較 |
| Search Console | サイト全体のURLグループ別レポート | 継続モニタリング |
Chrome DevToolsとの組み合わせが最短ルート
Insights方式への統合によって、PSIに出るinsightとDevTools Performanceパネルに出るinsightは同じものになりました。PSIで当たりを付け、DevToolsで同じinsightを開いてトレースを見る流れが最短です。手順はChrome DevToolsでの検証ガイドにまとめています。公開前のステージング環境や、まだCrUXデータが無いページの検証にも使えます。
よくある質問（FAQ）
Q. レポートに「Opportunities（改善できる項目）」が見当たりません。
設定ミスではなく、廃止されたためです。Lighthouse 13で旧監査がレポートからもJSONからも削除され、PSI本番へは2025年10月20日に反映されました。現在のPerformanceレポートは「Metrics」「Insights」「Diagnostics」の3グループ構成です。
Q. PageSpeed Insightsで90点を取れば検索順位は上がりますか？
上がるとは言えません。Google検索セントラルの「ページ エクスペリエンスの概要」は、単一の「ページエクスペリエンス シグナル」は存在せず、中核のランキングシステムが複数のシグナルを見ていると説明しています。さらに、レポートで良好な結果が出ても上位表示は保証されず、SEOのためだけに満点を狙うのは時間の使い方として最善ではないかもしれない、とも述べています。
Q. モバイルが30点でPCが90点です。どう対処すべきですか？
まずField Dataの3指標（LCP・INP・CLS）のうちどれが不良判定かを確認し、その指標に効くinsightだけを開くのが定石です。モバイル計測は低スペック端末と低速回線を前提にしているため差が出るのは正常ですが、モバイルファーストインデックスの運用上、Googleがクロールしているのはモバイル版ページです。実装の優先順位はページ速度改善の実装ガイドを参照してください。
Q. 計測するたびにスコアが違います。何回測ればいいですか？
本サイトでは5回続けて計測し、最大値と最小値の差を「振れ幅」、中央値を「現在値」として扱っています。振れ幅を超えない変化は成果として数えません。振れ幅が11点以上になる場合は計測自体が不安定なので、サードパーティスクリプトの切り分けを先に行います。詳細な手順と合否ラインは本文の「そのPSIの数字を信じてよいか」の章にまとめています。
Q. 改善したのにスコアが反映されません。なぜですか？
Lab側は反映済みでも、Field側は28日ローリング集計の途中である場合がほとんどです。CrUXは直近28日間のデータを集計するため、実装の効果がField Dataに現れるまで最大28日かかります。Lab側が振れ幅を超えて改善しているなら実装は効いているので、Search Consoleの「ウェブに関する主な指標」で日次推移を見ながら待つのが現実的です。
Q. PSIとローカルのLighthouseでスコアが違うのですが？
計測環境が違うためです。PSIはGoogleのサーバー上で実行され、ローカルのChrome DevToolsは手元のCPU・回線・拡張機能の影響を受けます。CPUスロットリングの係数もPSI本番環境で個別に調整されているため、数値はずれて当然です。報告に使う公式値はPSI、実装中の検証はローカルと役割を分けてください。
Q. PWAのスコアが出なくなりました。不具合ですか？
不具合ではありません。PSIのリリースノートによると、2024年5月10日のLighthouse 12.0への更新でPWAカテゴリはAPIレスポンスごと削除されました。現在のPSIが返すカテゴリはPerformance・Accessibility・Best Practices・SEOの4つです。PWA関連の確認はChrome DevToolsのApplicationパネルなど別の手段を使ってください。
まとめ｜PSIを使いこなす3つの心得
PSIは「スコアを追う」ためのツールではなく、実ユーザーの困りごとを特定し、改善の順番を決めるためのツールです。第一に、画面の前提を最新に保つこと。Opportunitiesは廃止され、PWAカテゴリも存在しません。第二に、LabとFieldを役割で分けること。第三に、自分のサイトの振れ幅を先に測ること。それを下回る変化を成果と呼ばなければ、無駄な追加実装は起きません。
この記事は「PSIという画面の取扱説明書」を担当しています。指標の定義と目標値はCore Web Vitals改善ガイド、実装コードはページ速度改善の実装ガイド、ファーストビュー設計とCVRはファーストビュー改善ガイドが担当します。