PageSpeed Insightsの見方入門
PageSpeed Insights（PSI）は、実ユーザーの体験（フィールドデータ）と、検査用の計測（ラボデータ）を1つの画面で確認できる定番ツールです。本記事では「どこを見ればいい？」「スコアはどう扱う？」「何から直す？」を、公式の考え方（CrUX / Lighthouse / Core Web Vitals）に沿って整理します。
PageSpeed Insightsとは？（まず結論）
PageSpeed Insights（PSI）は、URLを入力するだけで ①実ユーザーの体験（フィールドデータ / CrUX）と ②検査用の計測（ラボデータ / Lighthouse）をまとめて見られるツールです。
- フィールド：過去28日間の実ユーザー体験（75パーセンタイル）を中心に評価されます。
- ラボ：一定条件での模擬計測。原因を掘るのに強い（再現テスト向き）。
結論：SEO/UXの改善はフィールド（実ユーザー）を基準に、ラボ（原因特定）で直すのが王道です。
PSIの全体構成：フィールドとラボ
PSIは大きく2ブロックです。
- 実際のユーザーが体験している内容（フィールドデータ）
- Core Web Vitalsの合否（Pass/Fail）
- INP / LCP / CLS（＋FCPやTTFBなど、画面によって表示）
- 「良好 / 改善が必要 / 不良」の分布
- ラボ診断（Lighthouse）
- パフォーマンススコア（0〜100）
- 主要指標（FCP, LCP, Speed Index, TBT, CLS など）
- 改善提案（Opportunities/Diagnostics など）
最重要：フィールドデータ（CrUX）で見るべき場所
フィールドデータは「実際のChromeユーザーの体験」を集計したものです。 ここで最初に見るべきは次の3点です。
- このURLにフィールドデータがあるか（新規/低トラフィックだと表示されないことがあります）
- ページ単位か、オリジン単位か（サイト全体の集計にフォールバックする場合があります）
- 分布（良好/改善/不良）と75パーセンタイル値（多くの人が困っている側を重視）
覚え方：フィールドは「結果」、ラボは「原因」。
結果（フィールド）が悪いのに原因を直さない／原因（ラボ）だけ直して結果が変わらない、が一番もったいないです。
Core Web Vitals（INP/LCP/CLS）の基準と合否
Core Web Vitalsは、Googleが「ページ体験」を測る中核指標として示している3つです。 PSIでは、フィールドデータの75パーセンタイルが基準値を満たすかで、合否（Pass/Fail）を判定します。
| 指標 | 何を測る？ | 良好（目安） | 不良（目安） |
|---|---|---|---|
| LCP | 最大要素が表示されるまで（読み込み体感） | 2.5秒以内 | 4.0秒超 |
| INP | 操作してから次の描画まで（反応の良さ） | 200ms以内 | 500ms超 |
| CLS | 表示のズレ（視覚的安定性） | 0.1以内 | 0.25超 |
ざっくり言うと、「表示が早い」「反応が良い」「ガタつかない」の3点セットです。 ブログは画像や広告、外部スクリプトで悪化しやすいので、改善の優先度がつけやすい領域でもあります。
ラボデータ（Lighthouse）：スコアと主要指標の見方
ラボはLighthouseで計測され、パフォーマンス / アクセシビリティ / ベストプラクティス / SEOなどのカテゴリスコアが表示されます。 ただし、ブログ運用でまず注目すべきはパフォーマンス（Performance）です。
パフォーマンススコアの目安（Lighthouse）
- 90〜100：良好
- 50〜89：改善が必要
- 0〜49：不良
ラボでよく見る主要指標（意味だけ押さえる）
- FCP：最初の内容が表示されるまで
- LCP：最大要素の表示（CWVにも直結）
- TBT：JSなどでメインスレッドが塞がっている時間（操作遅延の原因になりやすい）
- CLS：レイアウトのズレ（CWVにも直結）
- Speed Index：表示が進む体感の速さ
コツ：ラボのスコアは「通知表」です。
次章の“優先順位”に沿って、指標→原因→打ち手の順に落とし込みましょう。
改善の優先順位（迷ったらこの順）
PSIの提案は大量に出ます。初心者が迷いにくい優先順位は次の通りです。
- フィールドのCore Web VitalsがFailなら、まずPassを狙う（INP/LCP/CLS）
- LCP改善（画像・ヒーロー要素・レンダリングブロック）
- INP改善（重いJS、長いタスク、サードパーティ）
- CLS改善（画像/広告枠のサイズ固定、フォント、遅延挿入）
- その後に細かな“点数改善”（軽微な診断項目を潰す）
そして「モバイル」と「デスクトップ」では結果が違いがちです。 SEOとUXの観点ではモバイルを優先して改善するのが基本です。
よくある誤解（スコアに振り回されない）
- 誤解：スコア100が正義 → 現実：目的は“ユーザーが困らないこと”。まずCWVの合否を見ます。
- 誤解：ラボが良い＝実ユーザーも良い → 現実：フィールドとラボは一致しないことがあります。
- 誤解：PSIの提案は全部やるべき → 現実：影響が大きい順にやる方が成果が出やすいです。
- 誤解：1回の計測で結論 → 現実：計測にはブレがあるので、同条件で複数回・改善前後で比較します。
よくある指摘と“打ち手”の例
ここからは、PSIの「Opportunities/Diagnostics」に出やすい内容を、ブログ運用向けに“翻訳”します。
1) 画像が重い（LCPに直撃）
- 症状：次世代フォーマット、適切なサイズ、圧縮の指摘
- 打ち手：WebP/AVIF、レスポンシブ画像（srcset）、遅延読み込み（lazy）、ヒーロー画像は優先読み込みを検討
2) レンダリングをブロックするリソース
- 症状：CSS/JSが描画を止める
- 打ち手：不要CSS削減、重要CSSの最小化、JSのdefer/async、フォント最適化（表示遅延を避ける）
3) JSが重い（INP/TBTに影響）
- 症状：メインスレッド作業が多い、長いタスク
- 打ち手：不要なライブラリ削除、遅延ロード、サードパーティ（広告/解析/ウィジェット）の棚卸し
4) レイアウトのズレ（CLS）
- 症状：広告・埋め込み・画像でガタつく
- 打ち手：画像/広告枠の幅高さを確保、後挿し要素の抑制、フォント読み込みの影響を減らす
5) サーバー応答が遅い（TTFB）
- 症状：初期応答が遅く、他の指標にも波及
- 打ち手：キャッシュ、CDN、DB/プラグインの見直し、重い処理の削減
現場の近道：「画像」「サードパーティ」「JS」の3点を棚卸しすると、ブログは一気に改善することが多いです。
PSIとSearch Consoleの使い分け
PSIは1URLを深掘りするのが得意です。一方で、サイト全体を見渡すならSearch ConsoleのCore Web Vitalsレポートが便利です。
- PSI：特定ページを計測 → どこが遅い/悪いかを特定 → 打ち手に落とす
- Search Console：サイト全体で「不良URL群」を把握 → 優先して直すページ群を決める
まとめ：PSIは「現状把握→原因特定→優先度付け」の道具
- PSIはフィールド（実ユーザー）とラボ（Lighthouse）をセットで見られる
- まずはフィールドのCore Web Vitals（INP/LCP/CLS）の合否と分布を見る
- 改善はLCP→INP→CLSの順に、影響の大きい原因から直す
- スコア100にこだわるより、「ユーザーが困らない」状態を安定させるのが成果につながる