Core Web Vitals改善ガイド｜LCP・INP・CLSを最適化する2026年版チェックリスト

Core Web Vitalsとは、Googleが定めるユーザー体験を測る3つの指標（LCP・INP・CLS）の総称で、検索順位に影響するページ品質シグナルです。本記事では2026年時点の3指標の定義、目標値、改善優先順位、それぞれの本質と改善アプローチを「指標起点」で体系的に整理します。具体的な実装コードや計測ツールの使い方は深掘りせず、概念の理解と判断軸の獲得にフォーカスする構成です。

結論を先に述べると、Core Web Vitals改善の鍵は「3指標のうち赤い指標から、フィールドデータ（実ユーザーデータ）を基準に着手すること」に集約されます。スコア100点を目指すよりも、Googleが定める「Good」基準を75パーセンタイルで満たすことが評価軸であり、計測の正確さと改善優先度の判断が成否を分けます。なお2024年3月12日にFIDがINPへ正式置換されているため、旧情報のFID表記はすべて読み替えが必要です。

• 具体的な実装コード（Critical CSS・preload・fetchpriority・scheduler.yield等）は ページ速度改善の実装ガイド へ
• PageSpeed Insightsスコアの読み方・改善実務は PageSpeed Insights表示速度改善 へ
• ファーストビューの構成・CVR最適化は ファーストビュー改善ガイド へ

Core Web Vitalsとは何か｜指標起点の入口

Core Web Vitalsとは、Googleが定めるユーザー体験を測る3つの指標（LCP・INP・CLS）の総称で、検索順位に影響するページ品質シグナルです。2020年に発表され、2021年6月からモバイル検索、2022年2月からPC検索でランキング要因として組み込まれています。読み込み速度（Loading）、応答性（Interactivity）、視覚的安定性（Visual Stability）という3つの異なる側面を、それぞれ独立した数値で評価する点が特徴です。

Googleが定義する「ユーザー体験を測る3指標」

web.dev公式（Google）の「Web Vitals」ドキュメントによると、Core Web Vitalsは「すべてのWebページで重要なUXシグナルの中核となるサブセット」と位置づけられています。Webパフォーマンス全般を測る指標（FCPやTBTなど）の中から、ユーザー体験への影響が特に大きく、改善によってビジネス成果に直結しやすい3つが選定されました。逆に言えば、これら3指標を改善することは、ユーザーの体感品質を改善することと同義です。

3指標は「ユーザーがページを訪れてから操作するまでの体験」を時系列で分割しています。表示が始まるまでの待ち時間（LCP）、操作したときの反応の速さ（INP）、表示中の予期せぬズレ（CLS）という形で、ページ体験の異なる側面を漏らさずカバーする設計になっています。

2026年現在の3指標：LCP・INP・CLS

2026年現在のCore Web Vitalsを構成する3指標は次の通りです。LCP（Largest Contentful Paint：最大コンテンツの描画時間）、INP（Interaction to Next Paint：次のペイントまでの応答時間）、CLS（Cumulative Layout Shift：累積レイアウトシフト）。それぞれが異なる単位（秒・ミリ秒・無次元スコア）で測られ、3指標すべてが「Good」基準を満たすことが目標になります。

なぜCore Web Vitalsが検索順位に影響するのか

Google検索セントラル公式「ページ エクスペリエンスについて」は2つの文で言い切っています。1つは「単一のシグナルは存在しない（There is no single signal）」。ページエクスペリエンスという1本のスコアは存在せず、Search Consoleのページエクスペリエンスレポートも現在は提供されていません。もう1つは「Core Web Vitalsは当社のランキングシステムで使用されている」。ただし同ページは「レポートや第三者ツールで良い結果が出ても、上位表示が保証されるわけではない」とも明記します。評価には使われるが、それだけで順位は決まらない——これが公式の位置づけです。SEO施策全体の中での置き所はSEOガイドで整理しています。

もう一つ重要なのは、Googleが評価に使うデータは「実ユーザーの体験データ（フィールドデータ）」のみという点です。開発環境でのスコア改善はあくまで参考であり、Chrome User Experience Report（CrUX）に蓄積される実データを動かさない限り、ランキング評価には反映されません。この点が他のSEO施策との大きな違いです。

FIDからINPへの移行｜2024年3月の変更点

FIDは2024年3月12日にINPへ正式に置き換わりました。INPはページ滞在中の全インタラクションの応答時間を測定する指標です。2024年以前に公開された解説記事や書籍ではFIDが現役指標として説明されていますが、現在のCore Web VitalsにFIDは含まれていません。古い情報を参照する際は必ずINPへの読み替えが必要です。

なぜFIDは廃止されたのか

FID（First Input Delay：初回入力遅延）は「ユーザーが最初に操作したときの入力イベント受付までの遅延」のみを測定する指標でした。Chromeチームの公式アナウンス（web.dev Blog・2024年3月12日）は、「FIDでは捉えられていなかったWebのインタラクティブ性の側面を測るため、新しい指標が必要になった」と述べています。FIDが測っていたのはページ滞在中の最初のインタラクションだけで、しかも入力イベントの受付までの遅延のみ。その後の処理時間や描画時間は評価対象外でした。たとえばクリックは即座に受け付けても、その後の処理で数秒画面がフリーズすればユーザーは「遅い」と感じますが、FIDではこれを捉えられませんでした。

INPは何が違うのか｜全インタラクションの最遅値

INPはFIDの限界を補うように設計されました。第1にページ滞在中のすべてのインタラクション（クリック・タップ・キー入力）を計測対象にします。第2に入力受付からプレゼンテーション処理（次のペイント）までの全工程を含めて測ります。第3に1ページ滞在中で最も遅かったインタラクションを代表値にします。web.dev公式「Interaction to Next Paint (INP)」によれば、外れ値の除外が働くのはインタラクションが50回を超えるページだけで、50回につき1件だけ最遅値を捨てます。大半のページは50回に届かないため、実際には「最も遅かった1回」がそのままINPです。これにより、FIDでは見えなかった「動作中のフリーズ」「重い処理によるカクつき」がスコアに表れるようになりました。

旧記事・旧情報でFIDを見たときの読み替え方

2024年3月以前の解説でFIDが現役指標として語られている場合、基本的にINPへ読み替えて構いません。ただし基準値はFIDの100ms以下からINPの200ms以下へ変わっており、しかもINPは全インタラクションの応答時間を測るため、FID時代の「メインスレッドのブロックを避ければよい」という対策のままでは足りません。

3指標の目標値とGood/Needs Improvement/Poor基準

2026年現在のCore Web Vitalsの目標値は、LCPが2.5秒以下、INPが200ms以下、CLSが0.1以下です。Googleは各指標を「Good」「Needs Improvement」「Poor」の3段階で評価し、すべての指標で「Good」を満たすことを推奨しています。閾値はweb.dev公式「Web Vitals」で公開されている標準値で、PageSpeed InsightsやSearch ConsoleもこのGood基準で判定を行います。

3指標の閾値一覧

これらの閾値はweb.dev公式「Defining the Core Web Vitals metrics thresholds」で根拠まで公開されています。閾値は不変ではなく、Web全体の高速化に応じて将来引き締められる可能性があります。実際FIDからINPへの置換も「より厳しい応答性評価」への移行であり、ユーザー期待の高度化に合わせて基準は進化し続けます。

「75パーセンタイル基準」とは何か

Googleが評価で用いるのは「実ユーザーの体験値の75パーセンタイル」です。web.dev公式は「ページやサイトの総合的なパフォーマンスを分類するために、全ページビューの75パーセンタイル値を用いる。ページビューの少なくとも75%がGoodのしきい値を満たしていれば、その指標は『Good』と分類される」と説明しています。集計期間はCrUX公式ドキュメントの通り直近28日間です。一部の高速端末ユーザーだけが満たしていてもダメで、モバイルの平均的なユーザー層まで含めて閾値を満たす必要があるため、施策はモバイル基準で進めるのが現実的です。

改善の優先順位｜どの指標から手をつけるか

3指標を同時に改善するのが理想ですが、実務では着手順を決めないと工数が分散します。最初に押さえるべき原則は「赤い指標（Poor判定）から潰す」「フィールドデータを基準にする」「モバイルとPCを分けて評価する」の3つです。スコア値の小さい改善より、Poor判定をNeeds Improvementへ、さらにGoodへ引き上げる方が、評価面でもユーザー体験面でも投資対効果が圧倒的に高くなります。

「赤い指標」を最優先する基本原則

PageSpeed InsightsやSearch ConsoleのCore Web Vitalsレポートでは、各指標が赤（Poor）・黄（Needs Improvement）・緑（Good）の3色で示されます。赤判定の指標が1つでもあれば、そのページはCore Web Vitals全体として不合格扱いです。黄を緑に上げる労力と赤を黄に上げる労力では評価への影響度が桁違いなので、最初の一手は必ず「赤い指標から」と覚えてください。

モバイルとPCで分けて見る理由

Googleの評価はモバイル・PCで別々に行われます。Search Consoleでも「Core Web Vitals – モバイル」「Core Web Vitals – PC」が分かれて表示されるのはこのためです。一般にモバイルの方がスコアが悪く、改善余地も大きい傾向があります。Googleがモバイルファーストインデックスを採用していることもあり、優先順位はモバイルの赤い指標が最上位、次にPCの赤い指標、その後にモバイルの黄、PCの黄、という順で着手するのが効率的です。

影響範囲が広い順：LCP → INP → CLS

赤い指標が複数ある場合の典型的な着手順は、LCP → INP → CLSです。LCPは「画像最適化」「サーバー応答」「リソース配信」といった広範な領域に影響するため、改善施策がページ全体のパフォーマンスを底上げしやすいという理由があります。INPはJavaScript実装に深く依存するため改善はやや専門的ですが、対象を絞れば効果は明確です。CLSはレイアウト調整がメインで局所的な修正が中心になり、他指標と切り離して進めても影響が少ないため後回しでも構いません。

LCPの本質と改善アプローチ

LCP（Largest Contentful Paint）は、ビューポート内で最大のコンテンツ要素が描画されるまでの時間を測定する指標です。多くの場合、ヒーロー画像、メインビジュアル、大きな見出しテキストなどがLCP要素になります。Goodの基準は2.5秒以下、Poorは4.0秒超。LCP要素の特定さえできれば改善の方針は立てやすいため、3指標の中では最も「攻略しやすい」指標と言えます。

LCP要素の特定方法

LCP要素の特定にはPageSpeed Insights、Chrome DevToolsのPerformanceパネル、Web Vitals拡張機能のいずれかを使います。PSIのレポートでは「Largest Contentful Paint element」セクションでLCP対象要素のHTMLが明示されます。DevToolsではタイムライン上のLCPマーカーから対象DOMを直接ハイライトできます。PageSpeed Insightsの具体的な使い方で実務手順を解説しています。

LCPを構成する4つの時間

web.dev公式「Optimize Largest Contentful Paint」によると、LCPは4つの時間に分解できます。①Time to First Byte（TTFB）：サーバーからの応答開始まで、②リソース読み込み遅延（Resource load delay）：HTMLパースからLCPリソースの取得開始まで、③リソース読み込み時間（Resource load duration）：LCPリソースの転送時間、④要素レンダリング遅延（Element render delay）：リソース取得完了から描画完了まで。改善施策はどの時間が支配的かで変わるため、まず分解して見ることが重要です。

改善アプローチの分類

LCPの改善アプローチは3階層に整理できます。サーバー側ではTTFB短縮（高速ホスティングへの移行、データベースクエリの最適化、ページキャッシュ）。配信側ではCDN導入、HTTP/2 or HTTP/3、Brotli圧縮の有効化。フロントエンド側ではLCP画像のpreload、fetchpriority=”high”、適切な画像フォーマット（WebP/AVIF）、Critical CSSのインライン化など。ファーストビューに表示されるLCP候補画像には loading="lazy" を付けてはいけません。遅延読み込みによってLCPがかえって悪化します。効果が読みやすいのはCritical CSSのインライン化で、LCP・FCP・CLSの実測値をクリティカルCSS最適化の実装と事例にまとめています。画像は画像圧縮ツールでWebP・AVIF化し、解像度の出し分けはpictureタグで行うのが定石です。

INPの本質と改善アプローチ｜2026年最新仕様

INP（Interaction to Next Paint）は、ページ滞在中に発生したすべてのインタラクションの応答時間を計測し、その最遅値を代表値とする指標です。Good基準は200ms以下、Poorは500ms超。LCPがリソース最適化中心だったのに対し、INP対策はJavaScript実装の構造的見直しが必要になるため、3指標の中で最も改善難度が高い指標と言えます。

INPは「最も遅かったインタラクションの応答時間」

INPは「平均値」ではなく「最も遅かった1回」で評価される点が他指標との大きな違いです。1ページ滞在中に30回クリックして29回が高速でも、1回だけ500msかかればその500msがINPとして記録されます（外れ値の除外が働くのはインタラクションが50回を超えたときだけなので、多くのページでは最遅値がそのまま出ます）。これは「最悪体験を見過ごさない」というGoogleの設計思想の表れで、たまにしか発生しないが重い処理（例：検索フィルターの再計算、モーダルの初回表示など）を見つけて改善する必要があります。

Long Animation Frames API（LoAF）で見える化が進んだ

Chrome for Developers公式「Long Animation Frames API」によると、Chromeは2024年からLong Animation Frames API（LoAF）を提供しています。これは「50ms以上かかったフレーム」を検出するAPIで、INPで遅延が発生した「原因のスクリプト」を特定するのに役立ちます。従来のLong Tasks APIが「タスク単位」での検出に留まっていたのに対し、LoAFは「フレームの中で何がボトルネックだったか」を細かく分析できます。INP対策では、まずLoAFで遅いフレームを特定し、その中の処理を分割・遅延化していくのが王道です。

メインスレッドを空けるという原則

INP改善の本質は、メインスレッドを長時間ブロックする処理を分割し、ユーザー入力に応答する余地を作ることです。ブラウザのメインスレッドは入力イベントの処理・レイアウト計算・JavaScriptの実行など、ほとんどすべての処理を1本のスレッドで順番に処理します。長いJavaScriptタスクが走るとその間ユーザーの操作は完全にブロックされます。INP対策はこの「長いタスク」を見つけて、複数の短いタスクに分割するか、後回しにできる処理を後回しにする、という方針が基本です。

scheduler.yield()の登場と改善手段の整理

Chrome 129以降ではscheduler.yield()というAPIが利用可能になり、長いタスクの中でブラウザに制御を戻す（yieldする）処理が簡潔に書けるようになりました。これにより、ユーザー入力を割り込み処理できるタイミングを意図的に作れます。ただし全ブラウザで使えるわけではありません。MDNは scheduler.yield() を「Limited availability（広く使われているブラウザの一部で動作しないため Baseline ではない）」と分類しています。本番では globalThis.scheduler?.yield で機能検出し、未対応環境は setTimeout 等へフォールバックさせてください。INP対策の手段は次の3カテゴリに整理できます。

• 分割：長いタスクを短いタスクに分け、その間にブラウザに制御を戻す（scheduler.yield、setTimeout、requestIdleCallback）
• 遅延：初期表示に不要な処理を後回しにする（dynamic import、Intersection Observer、defer/async）
• 削除：そもそも不要なライブラリ・処理を削除する（バンドルサイズ削減、依存削減）

CLSの本質と改善アプローチ

CLS（Cumulative Layout Shift）は、ページの全ライフサイクルで発生した予期せぬレイアウトシフトのうち、「最大セッションウィンドウ」のスコアを表す指標です。web.dev公式「Cumulative Layout Shift (CLS)」によれば、セッションウィンドウとは「1秒未満の間隔で連続して起きたシフトのまとまり（最長5秒）」で、その中で合計スコアが最大のまとまりがCLS値になります。「ズレを全部足し上げた累積値」は旧定義です。web.dev公式ブログの追記の通り、この方式は2021年6月2日にChromeの各ツールへ展開済みで、それ以前の解説は読み替えが必要です。Good基準は0.1以下、Poorは0.25超。視覚的な不安定さを数値化した指標で、ユーザーが「読んでいた行が突然下にズレた」「押そうとしたボタンが移動した」といった体験を防ぐ役割を持ちます。

視覚的不安定さがなぜ問題か

レイアウトシフトはユーザー体験を大きく損ないます。最も深刻なのは「誤クリック」です。たとえば「閉じる」ボタンを押そうとした瞬間にバナー画像が遅れて読み込まれてレイアウトがズレ、結果的に「申し込み」ボタンを押してしまった、というケース。ECサイトでこうした事故が起こるとユーザーは不信感を抱きます。Googleが視覚的安定性を独立した指標として位置づけているのは、こうした「予期せぬ操作」がユーザー満足度に直結するからです。

CLSを引き起こす主な原因5パターン

web.dev公式「Optimize Cumulative Layout Shift」が挙げるCLSの主な原因は4つです。①サイズ未指定の画像、②サイズ未指定の広告・埋め込み・iframe、③動的に挿入されるコンテンツ、④Webフォント。本記事ではこの公式4分類に、実務で頻出する⑤CSS Transitionの誤用（widthやheightなどレイアウトに影響するプロパティをアニメーションさせる）を加えた5パターンで整理します。原因はほぼこの範囲に収まるため、特定はそれほど難しくありません。

改善の原則｜レイアウトを「予約」する

CLS改善のキーワードは「予約」です。後から読み込まれる要素のために、最初のレンダリング時に領域を確保しておくという考え方です。画像にはwidth/height属性またはaspect-ratioを指定し、ブラウザが寸法を予測できるようにします。広告枠には min-height でプレースホルダーを置きます。Webフォントは font-display: swap でフォールバックフォントを先に表示しつつ、size-adjust ディスクリプタで再描画時のズレを最小化できます。なおCLSは全ライフサイクルが対象なので、読み込み後にスクロールやクリックで挿入される要素も忘れずに領域を予約してください。

計測ツールの全体像｜ラボデータとフィールドデータの使い分け

Core Web Vitalsの検索ランキング評価に使われるのはフィールドデータ（CrUX）のみです。ラボデータは開発時の参考値です。計測ツールを選ぶ際はまずこの違いを押さえる必要があります。計測ツールには得意領域があるため、用途に応じて使い分けるのが基本です。PageSpeed Insightsの画面の読み方そのものはPSI改善実務ガイドにまとめています。

Lab DataとField Dataの違い

Lab Data（ラボデータ）は、固定した環境（端末・回線条件）で行うシミュレーション計測です。Lighthouseが代表で、結果が安定し施策の効果を即座に確認できます。一方Field Data（フィールドデータ）は実ユーザーから集めた匿名データ（CrUX）で、Googleの評価に使われるのはこちらです。改善はラボで方向を確認し、最終評価はフィールドで行う二段構えが基本です。

代表ツールマトリクス

推移確認のツールは世代交代済みです。Chrome for Developers公式ブログ（2025年9月9日）がCrUX Dashboardの廃止を予告し、2025年11月末で停止されました。古い解説にはまだ登場しますが、これから用意するなら後継のCrUX Visを使ってください。

「数字が動かない」と感じたときの注意点

Chrome User Experience Report公式ドキュメントによると、CrUXの集計期間（collection period）は常に直近28日間です。今日改善を本番反映しても、効果が数値に出そろうまで約28日かかります。改善直後にPSIのフィールド値を見て「変わっていない」と早合点しないでください。Search ConsoleのCore Web Vitalsレポートも同じ基準で集計されます。改善後1〜2週間は推移を観察し、4週後に最終評価する流れが現実的です。

改善ワークフロー｜診断→仮説→実装→再計測

Core Web Vitalsの改善は単発の作業ではなく、診断→仮説→実装→再計測のサイクルを回すPDCA活動です。施策を闇雲に投入してもボトルネックを外していなければ数値は動きません。逆に、フィールドデータで悪い指標を特定し、ラボで原因を絞り込み、ピンポイントで施策を打てば、少ない工数で大きな改善が得られます。

4ステップの全体像

1. 診断：Search ConsoleとPSIで「どの指標が、どのページで悪いか」を特定する
2. 仮説：DevToolsやWeb Vitals拡張機能でラボ計測し、ボトルネックを推定する
3. 実装：仮説に基づきコード変更を行い、ステージング環境でラボ値を再計測する
4. 再計測：本番反映後、フィールドデータが28日かけて変化するのを待ち、効果を確認する

各ステップで使うツールと参考記事マップ

• 診断ステップ：Search Console＋PageSpeed Insights。詳細は PageSpeed Insights改善実務
• 仮説ステップ：Chrome DevTools Performanceパネル＋Web Vitals拡張機能。パネルの操作は Chromeデベロッパーツールの使い方
• 実装ステップ：preload・fetchpriority・Critical CSS・scheduler.yield等。コードは ページ速度改善の実装ガイド
• UX設計ステップ：ファーストビュー構成の最適化は ファーストビュー改善ガイド
• 再計測ステップ：CrUX VisまたはSearch Console、28日後を待つ

改善できたかを判定する合否ライン

改善作業の終わりを決められないと、Core Web Vitals対応は無限に続きます。次の3つが揃った時点で「その指標は合格」と判定して手を離してください。

ラボ値だけがGoodになった段階では合格ではありません。Googleが評価に使うのはフィールドデータだけだからです。逆に、フィールド値がGoodに変わったなら、ラボスコアが100点でなくても、その指標の作業はそこで終わりです。

判定でつまずくのは、ほぼ「ラボとフィールドが食い違うとき」です。症状ごとに読み分けてください。

判定に迷ったら、「フィールド値が28日経っても動かないなら、それはまだ直っていない」と考えて診断ステップに戻ってください。ここで止めれば十分で、この先の深追いは不要です。

よくある質問（FAQ）

Q. Core Web Vitalsは検索順位に直接影響しますか？

ランキングシステムには使われますが、それだけで順位が決まるわけではありません。Google検索セントラル公式は「単一のシグナルは存在しない」としたうえで「Core Web Vitalsは当社のランキングシステムで使用されている」と明記し、同時に「レポートや第三者ツールで良い結果が出ても、上位表示が保証されるわけではない」と述べています。現実的な目標は満点を取ることではなく、Poor判定を残さず全指標でGoodを確保しておくことです。

Q. FIDはもう完全に廃止されたのですか？

はい、廃止済みです。2024年3月12日にCore Web Vitalsの構成指標から外れてINPへ置き換わり、さらにweb.dev公式ブログ「Chrome ends support for First Input Delay」（2024年9月）の通り、PageSpeed InsightsとそのAPI、CrUX API／History API、CrUX Dashboard、BigQuery（202409データセット以降）、Web Vitals拡張機能からもFIDが削除されました。Google公式ツールでFIDの数値を見ることはもうできません（PerformanceObserver APIのfirst-inputエントリは残るため自前計測は可能です）。FIDの「Good：100ms以下」に対しINPは「Good：200ms以下」と基準値も異なるため、過去のFID改善実績はINP基準で計測し直す必要があります。

Q. モバイルとPC、どちらのスコアを優先すべきですか？

原則としてモバイルを優先します。Googleはモバイルファーストインデックスを採用しており、検索評価はモバイル版を基準に行われるためです。リソースが限られる場合は「モバイルの赤い指標」から着手し、「PCの赤」「モバイルの黄」「PCの黄」の順に下げていくのが効率的です。

Q. CrUXのデータが反映されません。なぜですか？

CrUXの集計期間は常に直近28日間なので、改善を本番反映してもデータが置き換わるまで約28日かかり、直後の変動は限定的です。また、CrUXは十分なデータ量があるページしか掲載しないため、トラフィックの少ないページではフィールドデータ自体が出ません。その場合はサイト全体のオリジン値で判定します。

Q. INPが200msを超えています。何から改善すべきですか？

まずChrome DevToolsのPerformanceパネルまたはLong Animation Frames API（LoAF）で「どのインタラクションが遅いか」「どのスクリプトがメインスレッドをブロックしているか」を特定します。多くの場合、サードパーティ製のタグ（広告・アナリティクス・チャットウィジェット）か、自社実装のイベントハンドラ内の重い処理が原因です。原因スクリプトを特定したら、処理の分割（scheduler.yield）、遅延読み込み（dynamic import）、不要な処理の削除、の3アプローチで対応します。Performanceパネルの操作手順はChromeデベロッパーツールの使い方、外部タグの読み込み位置が原因のケースはGTMタグをhead上部に設置するべき理由で扱っています。

Q. Core Web Vitalsの目標値は今後変わりますか？

変わる可能性はあります。実際FIDからINPへの置換は「より厳しい応答性評価」への移行でした。web.dev公式「Defining the Core Web Vitals metrics thresholds」によると、Googleは閾値の条件に「既存のWebコンテンツで達成可能であること」を置き、確認基準として「CrUXで少なくとも10%のオリジンがGood基準を満たすこと」を求めています。閾値はWeb全体の実力に紐づいており、Web全体が高速化すれば引き締める余地が生まれる構造です。施策は今の閾値をぎりぎり超えるのではなく、余裕を持たせておくと基準変更に耐えやすくなります。

Q. PageSpeed Insightsで100点を目指す必要はありますか？

必要ありません。Googleが見るのはフィールドデータであり、PageSpeed Insightsのラボスコア（0〜100点）そのものはランキング要因ではないからです。実務的にはラボスコアが80点以上、かつフィールドデータでGoodがついていれば十分です。100点に拘るより、コンテンツ品質や内部リンク構造の改善に時間を使う方が投資対効果は高くなります。

まとめ｜継続計測こそ最大の施策

Core Web Vitalsの3指標（LCP・INP・CLS）は、ユーザー体験の異なる側面を独立に測る設計になっています。改善の鉄則は「赤い指標を優先」「モバイル基準で判断」「フィールドデータで最終評価」の3点。それぞれの「まず手を付けるべき1施策」は次の通りです。

• LCP：LCP要素を特定し、画像最適化＋preload＋fetchpriorityで読み込みを優先化する
• INP：DevToolsで重いスクリプトを特定し、分割・遅延・削除のいずれかで対応する
• CLS：画像・広告・フォントに「予約領域」を設定し、レイアウトを安定させる

Core Web Vitalsは「一度改善して終わり」ではなく、コンテンツ追加・デザイン変更・外部スクリプト追加のたびに数値が動く生もののKPIです。月次でSearch ConsoleのCore Web Vitalsレポートを確認し、Poor判定が出たら都度対応する運用体制が現実解です。指標を離れて表示速度そのものを底上げしたい場合はWebパフォーマンス高速化ガイドが入口になります。

関連クラスター記事

表示速度・Core Web Vitalsをテーマにしたクラスターの他の記事もご覧ください。本記事は「指標起点」の解説で、以下の3記事と役割を分担しています。

• 【実装軸】ページ速度改善の実装ガイド｜コードで最適化する手順
• 【ツール軸】PageSpeed Insights表示速度改善｜スコアの見方とチェックポイント
• 【UX軸】ファーストビュー改善でCVRを上げる方法｜構成要素と表示速度の最適化