PageSpeed Insights（PSI）は、Googleが提供する無料のWebページ計測ツールで、Core Web Vitalsの実データ（Field Data）とラボ環境スコア（Lab Data）の両方を同じ画面で確認できる、表示速度改善の起点となる公式ツールです。本記事ではPSIスコアの読み方、Lab／Fieldの違い、Lighthouseのカテゴリ構成、スコア改善の優先順位、頻出警告の意味、反映されないときの確認ポイントを実務手順として整理します。指標の定義や実装コードはクラスター内の他記事に分割し、本記事は「ツールとしてのPSIをどう使いこなすか」に集中します。
結論を先に述べると、PSI攻略の鍵は「Lab DataとField Dataの違いを正しく理解すること」と「改善提案（Opportunities）を上から順に着手すること」の2点に集約されます。スコアという数字を追うのではなく、PSIが提示する「実ユーザーの困りごと」と「機会の大きさ」を読み解く姿勢で、改善作業の精度は大きく変わります。
この記事は「PageSpeed Insightsというツール起点」の解説です。PSIスコアの読み方と改善実務に絞っています。
- 指標（LCP・INP・CLS）の定義・目標値・優先度は Core Web Vitals改善ガイド へ
- 具体的な実装コード（preload・fetchpriority・Critical CSS等）は ページ速度改善の実装ガイド へ
- ファーストビュー設計とCVRの最適化は ファーストビュー改善ガイド へ
PageSpeed Insightsとは｜ツールの位置づけ
PageSpeed Insightsとは、Googleが提供する無料のWebページ計測ツールで、Core Web Vitalsの実データ（Field）とラボ環境スコア（Lab）の両方を確認できます。URLを入力するだけでモバイル・PCそれぞれの表示速度を100点満点で評価し、改善余地のある項目を「Opportunities（機会）」「Diagnostics（診断）」として一覧表示します。サイト所有者・開発者・SEO担当者の改善起点になる「健康診断書」的なツールです。
Googleが提供する無料パフォーマンス計測ツール
PageSpeed Insights（以下PSI）は https://pagespeed.web.dev/ で誰でも利用できる公式ツールです。アカウント登録は不要で、URLを入力するだけで動作します。出力レポートにはCore Web Vitalsの判定、Lighthouseのパフォーマンススコア、改善提案、診断項目、アクセシビリティ・SEO・ベストプラクティスのスコアが含まれます。Google検索セントラルでも「ページエクスペリエンス評価の確認に役立つツール」として案内されており、SEO実務の標準ツールです。
PSI／Lighthouse／CrUXの関係
PSIは複数のGoogle製プロダクトを統合した「ダッシュボード」です。Lighthouseがラボ環境の擬似計測を担当し、Chrome User Experience Report（CrUX）が実ユーザーから集めた匿名フィールドデータを供給し、PSIは両方を1枚のレポートにまとめます。「Field」の数字はCrUXの集計値、「Lab」の数字はLighthouseの計測値であり、この役割分担を理解しておくと「反映されない」「数値がブレる」といったトラブルシュートが格段に楽になります。
PSIで「何が」測れるのか
PSIで取得できる情報は、Core Web Vitalsの判定（Good／Needs Improvement／Poor）、Lighthouseのカテゴリ別スコア、改善余地のあるリソース一覧、要素単位の警告などです。逆にサーバーログ・セッション単位の挙動・JavaScript実行時エラーの追跡には向きません。PSIは「特定のURLがどれくらいの体感速度で表示されているか」を判定するツールであり、サイト全体の傾向はSearch Consoleの「ウェブに関する主な指標」、深掘り分析はChrome DevToolsやWebPageTestと組み合わせるのが基本です。各指標の定義や目標値の根拠はCore Web Vitals改善ガイドを参照してください。
Lab DataとField Dataの違い｜PSI攻略の最重要ポイント
PSIレポートの「実際のユーザー環境で評価する（Field Data）」と「パフォーマンスの問題を診断する（Lab Data）」は混同されがちですが、取得元・集計方法・反映タイミングがまったく異なるデータです。違いを理解しないままスコアを追うと改善作業が空回りします。
Lab Data（Lighthouse）とは
Lab Dataは、PSIサーバー上のLighthouseが計測のたびに擬似ブラウザでURLを読み込み算出する数値です。回線速度・端末性能・キャッシュ状態をGoogle側が固定するため再現性が高く、実装直後の検証や回帰チェックに向きます。「パフォーマンス」スコア（0〜100）と内訳の5メトリック（FCP・LCP・TBT・CLS・Speed Index）として表示され、コード修正直後に再計測できるのが最大の利点です。
Field Data（CrUX）とは
Field Dataは、実際にページを訪れたChromeユーザーから匿名で集計された体感データで、Chrome User Experience Report（CrUX）が公開しています。Chrome公式ドキュメントによると、CrUXのフィールドデータは「直近28日間のローリングウィンドウ」で集計され、各指標は75パーセンタイル値で評価されます。「上位75%が体験している速度」が判定基準になるため、最遅ユーザーを切り捨てず現実的な体験品質を反映できます。Field DataはSearch Consoleの「ウェブに関する主な指標」とも同じデータソースを共有しています。
Lab DataとField Dataの比較
| 観点 | Lab Data（Lighthouse） | Field Data（CrUX） |
|---|---|---|
| 取得元 | PSIサーバー上の擬似ブラウザによる1回計測 | 実ユーザーのChromeから匿名収集 |
| 集計期間 | リアルタイム（計測のたび1回ごと） | 直近28日間のローリング集計 |
| 主要指標 | FCP／LCP／TBT／CLS／Speed Index | LCP／INP／CLS／FCP／TTFB |
| 反映タイミング | 即時（コード修正後すぐ再計測可能） | 反映に最大28日かかる |
| 用途 | 実装直後の検証・回帰チェック | 実ユーザー体験の評価・SEO判定根拠 |
| 出ない場合 | 必ず出る（合成計測のため） | トラフィック不足だと「データ不足」表示 |
| SEO評価との関係 | 直接の評価対象ではない | ページエクスペリエンス評価の根拠 |
どちらを信じればいいか
結論として、「最終的なSEO評価はField Data、日々の実装検証はLab Data」と役割を分けるのが正しい使い方です。Field DataはGoogleの「ページエクスペリエンス評価」と同じデータソースを共有するためSEO上の最終根拠ですが、反映に最大28日かかります。実装フェーズはLabで方向性を確認し、リリース後にFieldで実ユーザーへの反映を見届ける二段構えが実務的な落としどころです。目標値の根拠はCore Web Vitals改善ガイドを参照してください。
Lighthouseの6カテゴリの読み方
PSIのLighthouseレポートは、Performance（パフォーマンス）を中心にAccessibility・Best Practices・SEO・PWAの5〜6カテゴリで構成されます。表示速度改善の文脈ではPerformanceが主役ですが、他カテゴリも検索評価や運用品質に間接的に関わります。
Performanceスコアの構成と重み付け
Performanceは5メトリックの加重平均です。Chrome Developers公式「Lighthouse Performance Scoring」によると、Lighthouse 10以降の重み付けは次のとおりです。
| メトリック | 2026年現在の重み | 意味するもの |
|---|---|---|
| FCP（First Contentful Paint） | 10% | 最初のコンテンツが描画されるまでの時間 |
| LCP（Largest Contentful Paint） | 25% | メインコンテンツが描画されるまでの時間 |
| TBT（Total Blocking Time） | 30% | メインスレッドのブロック時間の合計 |
| CLS（Cumulative Layout Shift） | 25% | 累積レイアウトシフト量 |
| Speed Index | 10% | ビューポート全体が視覚的に完成するまでの速度 |
PageSpeed InsightsのPerformanceスコアは、TBT 30%・LCP 25%・CLS 25%が大半を占め、この3つの改善がスコア向上に直結します。FCPやSpeed Indexだけを改善しても10%ずつしか動かないため、点数を上げたいなら重み付けの大きい3指標から着手するのが効率的です。なおField側ではTBTの代わりにINPが表示されますが、両者は「メインスレッドの詰まり」を測る点で密接に関係し、Lab側のTBT改善はField側のINPにも効きます。
Accessibility／Best Practices／SEO／PWAの役割
Performance以外のカテゴリは独立した観点で評価されます。Accessibilityはスクリーンリーダー対応やコントラスト比、Best PracticesはHTTPS利用・古いAPI非使用・コンソールエラー、SEOはmeta description・hreflang・モバイルフレンドリー、PWAはサービスワーカー登録やマニフェストの有無を評価します。Core Web Vitalsの直接スコアには影響しませんが、検索パフォーマンス全体・ユーザー満足度に関わるためAccessibilityで赤マークが出る場合は、SEO評価以前にユーザビリティの問題があるサインとして優先対処が望ましいです。
どのカテゴリから手を付けるか
表示速度改善とSEOの両立を狙う場合はPerformance→SEO→Best Practices→Accessibilityの順でチェックするのが現実的です。両方で低スコアの場合は技術的な土台に問題があるため、基盤を整える方が優先度高です。実装手順はページ速度改善の実装ガイドでコードレベルから解説しています。
スコアの「Good／Needs Improvement／Poor」基準
PSIの総合スコアは0〜100で示され、緑・オレンジ・赤の3段階で色分けされます。この色分けはChrome Developers公式ドキュメントで定義されており、サイト間共通の評価基準として使えます。
総合スコア（0-100）の評価帯
| 総合スコア | 評価 | 表示色 | 一般的な状態 |
|---|---|---|---|
| 90〜100 | Good | 緑 | 上位優良サイト。維持を目標にする帯 |
| 50〜89 | Needs Improvement | オレンジ | 改善余地あり。多くのサイトがこの帯に分布 |
| 0〜49 | Poor | 赤 | 早急な改善が必要。離脱率・コンバージョン率にも影響 |
90以上を目指すべきか、75以上で十分か
「PSIで何点を取ればいいか」の回答は「Lab側のスコアより、Field側でPoor状態を抜けることを最優先にする」です。Lab Dataが90以上でも実ユーザー環境でPoor判定が出るケースは珍しくなく、逆にLab側が80点台でもField側で全指標がGoodならSEO上は問題ありません。まずField側の3指標（LCP・INP・CLS）が「すべてGood判定」になることをマイルストーンに設定するのが、検索評価の観点で合理的です。目標値の根拠はCore Web Vitals改善ガイドを参照してください。
モバイルとPCでスコアが大きく違う理由
PSIではほぼすべてのサイトでモバイルスコアがPCを下回ります。「PCは95点なのにモバイルは40点台で焦った」という声は頻出しますが、これはサイトの実装が悪いとは限らず、PSIモバイル計測の「前提条件」が意図的に厳しく設定されていることに由来します。
PSIモバイル計測の前提（Slow 4G＋Moto G4相当）
Chrome Developers公式ドキュメント「Lighthouse Throttling」によると、Lighthouseのモバイル計測はSlow 4G相当の回線スロットリング（往復遅延150ms・帯域1.6Mbps程度）と、Moto G4相当のCPU性能（4倍スローダウン）で実行されると明記されています。2016年発売の中位機種が基準で、「低スペック端末でも快適に動くかを判定する」設計思想です。
モバイルとPCで何点くらい差が出るのが普通か
PageSpeed Insightsのモバイルスコアは、Slow 4G回線とMoto G4相当の端末で計測されるため、PCスコアより20〜40点低くなるのが一般的です。JavaScriptを多用するサイトでは差が広がり、軽量サイトでは10点前後に収まります。モバイルが低い場合、「JSが重いタイプか・画像が重いタイプか」を切り分けると改善の焦点が定まります。
Googleの検索評価はモバイル基準（Mobile-First Indexing）
Google検索セントラルが2020年に完了を宣言した「モバイルファーストインデックス」により、現在のGoogle検索はモバイル版ページを基準にインデックスとランキングを評価する運用に統一されています。PCで90点でもモバイルでPoor判定なら、検索評価上はモバイル側が採用されます。PSIで最初に開くタブは「モバイル」側です。実装の改善手順はページ速度改善の実装ガイドを参照してください。
スコア改善の優先順位｜4ステップのチェックポイント
PSIの改善作業を効率化する最大のコツは、レポートを「上から順に読む」のではなく役割ごとに4つのステップに分解して読むことです。Lab側のスコアだけ見て「Diagnostics」の細かい項目から手を付けると効果が小さい割に工数だけが膨らみます。Field DataからDiagnosticsへ降りる正しい順序を整理します。
ステップ1：Field Dataで「実ユーザーの困りごと」を特定
最初に確認すべきは画面上部のField Dataブロックです。LCP・INP・CLSのうちPoor（赤）またはNeeds Improvement（オレンジ）判定の指標を特定します。赤がついている指標は実ユーザーの大半が不快な体験をしているサインなので、ここから優先的に手を付けるのが鉄則です。Field側がすべてGoodならLab側の改善は緊急性が低く、コンテンツや他施策に工数を回す判断もあり得ます。
ステップ2：Lab Dataの「機会（Opportunities）」を上から順に見る
次にLab Dataの「機会（Opportunities）」を確認します。これはLighthouseが「この施策で何ミリ秒短縮できるか」という推定値を添えて、効果の大きい順に並べたリストです。PageSpeed Insightsの改善は『機会（Opportunities）』を上から順に着手するのが効率的です。上位ほど「効果が大きく、典型的な改善パターン」を提示してくれます。「Eliminate render-blocking resources」「Properly size images」「Reduce unused JavaScript」などが代表例です。
ステップ3：「診断（Diagnostics）」で深掘りする
Opportunitiesでカバーされない品質課題は「Diagnostics（診断）」に表示されます。DOMサイズ過大・サードパーティ製スクリプトの影響・メインスレッドの処理時間など、定量化しにくいが地味に効いている問題群です。Opportunitiesを片付けてもスコアが伸びない場合の「次の一手」になります。両者の違いは下表のとおりです。
| セクション | 性質 | 優先度 | 対処タイミング |
|---|---|---|---|
| Opportunities（機会） | 効果の推定値あり・施策が明確 | 高 | 最初に上から順に着手 |
| Diagnostics（診断） | 品質課題の指摘・効果は要検証 | 中 | Opportunitiesを片付けた後 |
| Passed audits | 合格項目のリスト | 参考 | 後退していないかの確認用 |
ステップ4：影響度の大きい改善から実装する
改善項目を特定したら、「影響度（推定短縮ミリ秒）×実装コスト」のマトリクスで優先順位を組み直します。「画像をWebPに変換」は影響度大・コスト低のため最優先、「サーバーサイドレンダリングへの移行」は影響度大だがコスト極大で長期計画扱い、といった具合です。具体的な実装手順はページ速度改善の実装ガイドでコードレベルから整理しています。
PSIで頻出する警告メッセージの読み方
PSIで表示される警告メッセージは英語のまま掲載されることも多く、初見では戸惑いがちです。本セクションは頻出警告を表で一気に俯瞰し、各h3では1〜2文の補足のみに留めます。具体的な実装コードと対処手順はページ速度改善の実装ガイドに集約しているため、本記事は「警告の意味を素早く特定する」用途です。
警告ごとの影響指標まとめ
| 警告メッセージ | 主な影響指標 | 典型的な対処方針 |
|---|---|---|
| Eliminate render-blocking resources | FCP／LCP | クリティカルCSS分離・JSのdefer／async |
| Properly size images | LCP | srcset設定・適正サイズの画像配信 |
| Serve images in next-gen formats | LCP | WebP／AVIFへの変換 |
| Reduce unused JavaScript | TBT／INP／LCP | コード分割・動的import・サードパーティ削減 |
| Avoid large layout shifts | CLS | サイズ属性明示・アスペクト比指定 |
| Minimize main-thread work | TBT／INP | 処理分割・Web Worker・遅延実行 |
| Efficient cache policy | LCP（リピート訪問） | Cache-Controlヘッダーの長期化 |
Eliminate render-blocking resources
HTML解析中にCSSやJavaScriptの読み込みでレンダリングが止まっている状態を指す警告で、FCP・LCPに直接効きます。実装手順はページ速度改善の実装ガイドを参照してください。
Properly size images／Serve images in next-gen formats
表示サイズより大きい画像の配信、または旧フォーマット（JPEG／PNG）のままWebP／AVIFを使えていない場合の警告で、LCPに直接効くOpportunities上位の常連です。LCP要素が画像のサイトでは、画像最適化だけでスコアが10〜20点上がるケースもあります。
Reduce unused JavaScript
ダウンロード・パースされたJSのうち実行されていない部分が大きい場合の警告で、TBT・INP・LCPに影響します。INPとの関係はCore Web Vitals改善ガイドのINPセクションを参照してください。
Avoid large layout shifts
表示後に要素のサイズや位置が変わるレイアウトシフトを指摘する警告で、CLSに直結します。CLSの原因と対処の体系はCore Web Vitals改善ガイドのCLSセクションを参照してください。
Minimize main-thread work
JS実行・スタイル計算・レイアウト処理など、メインスレッドが長時間ブロックされている状態を指す警告で、TBT・INPに影響します。実装パターンはページ速度改善の実装ガイドで扱っています。
スコアが「動かない・反映されない」ときの確認ポイント
PSI実務で必ずぶつかるのが「改善したのにスコアが変わらない」「毎回数値が違う」「Search Consoleと数値が一致しない」といったトラブルです。大半はPSI／Lighthouse／CrUXの仕組みを理解していれば説明がつく現象で、闇雲に追加実装する前に原因を切り分けることで余計な工数を回避できます。
Field Dataがそもそも出ない
Field Data側に「データ不足のため、このページの実際の速度を表示できません」と出るケースです。主因はトラフィック不足・HTTPS未対応・新規公開ページで集計が間に合っていないなど。Field Dataは「同意したChromeユーザーから匿名集計されたデータ」が一定数以上必要で、立ち上げ直後の小規模サイトでは表示されないのが普通です。Lab Data側の改善とSearch Consoleでのフォローを併用するのが現実解です。
改善したのにスコアが変わらない
多くの場合、「Lab側はすでに反映済みだがField側は28日待ち」という状況です。Field Dataは過去28日間のローリング集計のため、改善実装の効果が反映されるまでに最大28日かかります。これはChrome User Experience Reportの公式仕様で、回避策はありません。Lab側のスコアが先行して上がっているなら改善は効いているので、Field反映を待つ間はSearch Consoleの「ウェブに関する主な指標」で日次推移を観察すると変化の兆しが早く掴めます。
同じページなのに計測ごとに数値が違う
Lab Dataの計測には毎回±5〜10点程度の揺らぎがあります。Googleインフラ側のサーバー混雑・外部ネットワーク遅延・サードパーティスクリプトのレスポンス時間など、計測条件が完全には固定されないためです。Lab Dataは「1回の計測で結論を出さず、5回程度計測して中央値を見る」のが現場の暗黙ルールです。極端な外れ値は計測ノイズと判断し無視して構いません。
PSIとSearch Consoleで違う数値が出る
PSIのField DataとSearch Consoleの「ウェブに関する主な指標」は同じCrUXデータを参照しますが、PSIは「URL単位／オリジン単位」、Search Consoleは「URLグループ単位」と集計切り口が違うため、結果が違う数字に見えるのが正しい挙動です。判定方針は次表のとおり整理できます。
| 症状 | 原因 | 対処 |
|---|---|---|
| Field Dataが出ない | トラフィック不足・HTTPS未対応・公開直後 | Lab側で改善を進めながらSearch Consoleで補完 |
| 改善したのに反映されない | CrUXの28日ローリング集計 | 最大28日待つ。Search Consoleで日次推移を観察 |
| 毎回数値が違う | Lab計測の揺らぎ（±5〜10点） | 5回計測して中央値を採用 |
| PSIとSearch Consoleで数値が違う | 集計単位の違い（URL vs URLグループ） | 両方を補完的に見る |
PSI以外の補完ツールと使い分け
PSIは表示速度改善の起点として優れていますが、深掘り分析・継続モニタリング・カスタム条件の計測では別ツールとの組み合わせが必要です。
Chrome DevToolsのPerformanceパネル
Chrome標準搭載の開発者ツールで、Performanceパネルからフレームレベルの詳細プロファイリングが可能です。PSIでは見えないJS実行時間やスタイル計算の内訳まで確認でき、INP・TBT周りの深掘りに最適。Lighthouseパネルからは、PSIと同じLighthouse計測をローカル環境で実行できるため、本番反映前のステージング検証に重宝します。
WebPageTest（多拠点・多回数の検証）
複数のロケーションから複数回連続でテストを実行できる老舗ツールです。地理的距離・回線条件・ブラウザ種類を組み合わせて検証でき、フィルムストリップ表示で描画タイミングを秒単位で追跡できます。海外ユーザーが多いサイトやCDNの効きを地理的に検証したい場合に有用です。
Search Consoleの「ウェブに関する主な指標」レポート
CrUXデータをサイト全体のURLグループ単位で表示する継続モニタリング用ツールです。PSIが「URL単位の瞬間スナップショット」なのに対し、こちらは「サイト全体の日次推移」を可視化できるため、施策効果を全URLにわたって追跡するなら優位です。Googleが検索評価に使うのも同じCrUXデータなので、最終的なSEO評価の根拠としても重要です。
ツール役割の比較
| ツール | 強み | 主な用途 |
|---|---|---|
| PageSpeed Insights | 手軽・Field＋Lab同時表示 | 全体俯瞰・最初のスタート地点 |
| Lighthouse（Chrome DevTools） | カスタム条件で計測可能・ローカル実行 | 実装中の検証・ステージング確認 |
| WebPageTest | 多拠点・多回数・フィルムストリップ | 深掘り分析・地理的検証 |
| Search Console | サイト全体のURLグループ別レポート | 継続モニタリング・SEO評価確認 |
よくある質問（FAQ）
Q. PageSpeed Insightsで90点取れば必ず検索順位が上がりますか？
PSIスコアの向上は検索順位を保証しませんが、Core Web Vitalsの「Poor」状態を脱することはランキング評価上の前提条件です。Googleはページエクスペリエンス評価をランキング要素の一つと公式に明言していますが、コンテンツの質・関連性・E-E-A-Tの方がはるかに大きな比重を占めます。「90点を取るために本来の改善優先度が崩れる」のは本末転倒なので、まずFieldで全指標Good判定を取り、その上でコンテンツ改善に工数を回すのが合理的です。
Q. モバイルが30点でPCが90点です。どう対処すべきですか？
モバイル低スコアはまずField Dataの3指標（LCP・INP・CLS）のうちどれがPoor判定かを確認し、その指標を悪化させているOpportunitiesを上から潰すのが定石です。Mobile-First Indexingの運用上、Googleが見ているのはモバイル側なので、ここを改善することがSEO評価への近道です。実装の優先順位はページ速度改善の実装ガイド、目標値の根拠はCore Web Vitals改善ガイドを参照してください。
Q. 改善したのにスコアが反映されません。なぜですか？
多くの場合、Lab側はすでに反映済みだがField側の28日ローリング集計を待っている状態です。Chrome User Experience Reportは過去28日間のデータを集計するため、Field反映には最大28日かかります。Search Consoleの「ウェブに関する主な指標」で日次推移を観察するのが現実的です。
Q. PSIとLighthouseのスコアが違うのですが？
PSIはGoogleサーバー上のLighthouseで計測しており、ローカルのChrome DevToolsで実行するLighthouseとは計測環境が異なります。ネットワーク遅延・サーバー位置・拡張機能の有無などが影響するため、同じページでも数値はずれて当然です。原則として「PSIを公式値、Lighthouseローカルは開発中の検証用」と役割を分けるのが推奨運用です。
Q. Field Data（実データ）が「データ不足」と表示されます。
CrUXのデータ要件を満たしていない状態で、トラフィック不足・HTTPS未対応・新規公開直後のいずれかが主因です。Field Dataは同意したChromeユーザーから一定数以上のセッションが必要で、立ち上げ間もない小規模サイトでは表示されないのが常態です。この場合はLab Data側の改善とSearch ConsoleのCore Web Vitalsレポートでフォローし、トラフィックが集まるまではLab数値を改善の指針にする運用が現実的です。
Q. PSIスコアを上げるだけで意味がありますか？
「スコアを追う目的が何か」で変わります。Field Dataの3指標をPoorからGoodへ引き上げることは、ユーザー体験の向上・離脱率の低下・SEO評価の改善に直結するため確実に意味があります。一方、Lab側のスコアを90台後半まで磨き上げる作業は、Field側がGoodならSEO上の追加効果は限定的でコストパフォーマンスは下がります。「Field側の改善を最優先、Lab側は90以上をマイルストーン、それ以上は他施策とのバランスで判断」が実務的な落としどころです。
Q. PSIで「キャッシュポリシーが効率的でない」と警告が出ます。
静的アセット（画像・CSS・JS）のCache-Controlヘッダーが短すぎる、または未設定のときに出る警告です。リピート訪問時の体感速度に影響し、特にField側のLCPで効いてきます。対処はサーバーまたはCDNでのCache-Control設定の見直しで、不変アセットには長期キャッシュ、HTMLには短めの値を設定するのが定石です。具体的なヘッダー設定例はページ速度改善の実装ガイドを参照してください。
まとめ｜PSIを「使いこなす」3つの心得
PageSpeed Insightsは「スコアを追う」ためのツールではなく、「実ユーザーの困りごとを特定し、改善の優先順位を立てる」ためのツールです。第一に、Lab／Fieldは別物として扱い、SEO評価の判断はField側、実装直後の検証はLab側と役割を分ける。第二に、改善の優先順位はOpportunitiesを上から順に着手し、効果と工数の両軸で取捨選択する。第三に、PSIだけで完結させず、Chrome DevTools・WebPageTest・Search Consoleと併用し、計測・実装・継続モニタリングのフローを整える。指標の定義はCore Web Vitals改善ガイド、実装コードはページ速度改善の実装ガイド、ファーストビュー設計はファーストビュー改善ガイドへとクラスター内で役割を分担しています。
関連クラスター記事
「指標」「実装」「ツール」「UX」の異なる切り口を組み合わせることで全体像が立体的に把握できます。
- 【指標軸】Core Web Vitals改善ガイド｜LCP・INP・CLSを最適化する2026年版チェックリスト
- 【実装軸】ページ速度改善の実装ガイド｜コードで最適化する手順
- 【ツール軸】PageSpeed Insights改善実務｜スコアの見方とチェックポイント（本記事）
- 【UX軸】ファーストビュー改善でCVRを上げる方法｜構成要素と表示速度の最適化
