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表記はすべて読み替えが必要です。

この記事は「指標起点」のCore Web Vitals解説です。LCP・INP・CLSの定義、2026年時点の目標値、改善優先順位を体系的に整理しています。クラスター内の他記事と役割を分担しており、本記事では実装コードや計測ツールの操作手順は扱いません。

具体的な実装コード（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）の定義によると、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」基準を満たすことが目標になります。

指標	正式名称	測定するもの	単位
LCP	Largest Contentful Paint	ビューポート内で最大のコンテンツが描画される時間	秒
INP	Interaction to Next Paint	ページ滞在中の全インタラクションの応答時間（最遅値）	ミリ秒
CLS	Cumulative Layout Shift	ページ読み込み中に発生した予期せぬレイアウトのズレ量	無次元スコア

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

Google検索セントラル公式によると、Core Web Vitalsは「ページエクスペリエンス」評価の一部としてランキングシステムに統合されています。コンテンツ品質に大きな差がない場合のタイブレイカー（順位の引き分け解消要因）として作用するため、単独でドラスティックな順位変動を起こすことは稀ですが、競合との僅差を分ける要因として確実に効いてきます。特にモバイル検索ではユーザーの体感速度が滞在時間や直帰率に直結するため、ビジネス成果への寄与は無視できません。

もう一つ重要なのは、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 Developers Blog（2024年3月）の公式アナウンスでは、FIDの限界として「ページ滞在中の最初のインタラクションしか測れず、しかも入力イベントの受付時間のみで、その後の処理時間や描画時間を含まないため、ユーザー体験の実態を反映しきれない」と説明されています。たとえばクリックは即座に受け付けても、その後の処理で数秒画面がフリーズすればユーザーは「遅い」と感じますが、FIDではこれを捉えられませんでした。

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

INPはFIDの限界を補うように設計されました。第1にページ滞在中のすべてのインタラクション（クリック・タップ・キー入力）を計測対象にします。第2に入力受付からプレゼンテーション処理（次のペイント）までの全工程を含めて測ります。第3に1ページ滞在中で最も遅かったインタラクション（実質的には98パーセンタイル、つまり上位2%程度の遅い値を除外した最遅値）を代表値として記録します。これにより、FIDでは見えなかった「動作中のフリーズ」「重い処理によるカクつき」がスコアに表れるようになりました。

観点	FID（旧）	INP（現）
計測対象	最初の入力イベントのみ	滞在中の全インタラクション
計測範囲	入力受付までの遅延のみ	入力→処理→次の描画まで全工程
代表値	1ページ滞在中の最初の値	1ページ滞在中の最遅値（実質98パーセンタイル）
Good基準	100ms以下	200ms以下

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

2024年3月以前の解説でFIDが現役指標として語られている場合、基本的にINPへ読み替えて差し支えありません。ただしFIDが「Good：100ms以下」だったのに対しINPは「Good：200ms以下」と基準値が異なるため、しきい値だけはINP基準で再確認する必要があります。また、FID時代に「メインスレッドのブロックを避ければよい」と説明されていたINP対策は、INPでは「全インタラクションのレスポンス時間」を測るためより広範な対応が求められる点に注意してください。

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公式で公開されている標準値で、PageSpeed InsightsやSearch ConsoleもこのGood基準で判定を行います。

3指標の閾値一覧

指標	Good	Needs Improvement	Poor	測定対象
LCP	2.5秒以下	2.5〜4.0秒	4.0秒超	最大コンテンツの描画
INP	200ms以下	200〜500ms	500ms超	全インタラクションの応答
CLS	0.1以下	0.1〜0.25	0.25超	視覚的な不安定さ

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

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

Googleが評価で用いるのは「実ユーザーの体験値の75パーセンタイル」です。web.dev “How Core Web Vitals are calculated”によると、過去28日間の実ユーザーデータを集計し、上位75%のユーザー（つまり下位25%の遅い体験を除いた値）の最悪値で判定します。「ユーザーの3/4が良い体験をしていればGood」という考え方です。一部の高速端末ユーザーだけが満たしていてもダメで、モバイルの平均的なユーザー層まで含めて閾値を満たす必要があるため、施策はモバイル基準で進めるのが現実的です。

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

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

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

PageSpeed InsightsやSearch ConsoleのCore Web Vitalsレポートでは、各指標が赤（Poor）・黄（Needs Improvement）・緑（Good）の3色で示されます。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はレイアウト調整がメインで局所的な修正が中心になり、他指標と切り離して進めても影響が少ないため後回しでも構いません。

業種別の優先度傾向

サイト種別により最も影響を受ける指標は変わります。あくまで一般的傾向ですが、ECサイトは商品画像が多いためLCPがボトルネックになりやすく、メディアサイトは広告挿入によるCLSの悪化が起きやすい、SaaSのLPやWebアプリはJavaScriptが多くINPが課題になりやすい、といった違いがあります。実装ガイド側で具体的な改善策に進む前に、自サイトのフィールドデータでどの指標が最も悪いかを確認しておくと、施策の選択がブレません。

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

分解要素	支配的なボトルネック	主な改善方向
TTFB	サーバー処理・通信	ホスティング・CDN・キャッシュ
Resource load delay	リソース発見の遅さ	preload・fetchpriority
Resource load duration	リソース転送時間	画像最適化・WebP/AVIF・圧縮
Element render delay	レンダリングブロック	Critical CSS・JS遅延

改善アプローチの分類

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

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

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

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

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

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

web.dev “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する）処理が簡潔に書けるようになりました。これにより、ユーザー入力を割り込み処理できるタイミングを意図的に作れます。INP対策の手段は次の3カテゴリに整理できます。

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

これらの具体的なコード例はページ速度改善の実装ガイドに掲載しています。本記事では「INPを改善するには3つの方向性がある」という判断軸を押さえれば十分です。

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

CLS（Cumulative Layout Shift）は、ページ読み込み中およびその後のセッションで発生した予期せぬレイアウトのズレを累積したスコアです。Good基準は0.1以下、Poorは0.25超。視覚的な不安定さを数値化した指標で、ユーザーが「読んでいた行が突然下にズレた」「押そうとしたボタンが移動した」といった体験を防ぐ役割を持ちます。

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

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

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

web.dev “Optimize CLS”によると、CLSの典型的な原因は5パターンに分類されます。①サイズ未指定の画像・動画（width/height属性なし）、②動的に挿入される広告バナー、③後から読み込まれるWebフォントによるテキスト再描画（FOIT/FOUT）、④JavaScriptで動的挿入されるDOM要素（バナー、カルーセル、レコメンド）、⑤CSS Transitionの誤用（widthやheightなどレイアウトに影響するプロパティのアニメーション）。多くの場合この5パターンに当てはまるため、原因特定はそれほど難しくありません。

原因	典型例	改善方向
サイズ未指定画像	img/video/iframe要素	width/height明示、aspect-ratio指定
動的広告挿入	AdSense・サードパーティ広告	事前にスロット領域を確保
Webフォント遅延	FOIT/FOUT	font-display: swap、size-adjust
動的DOM挿入	レコメンド、お知らせバナー	min-height確保、フェードイン
アニメーション誤用	height変化、top/leftアニメ	transform/opacityで実装

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

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

計測ツールの全体像｜深掘りは子記事へ

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

Lab DataとField Dataの違い

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

代表ツールマトリクス

ツール	データ種別	主な用途
PageSpeed Insights	Lab + Field	個別URLの診断、改善提案の確認
Lighthouse（DevTools）	Lab	開発中の即時確認、詳細レポート
CrUX Dashboard	Field	サイト全体のフィールド値の推移確認
Search Console	Field	サイト全体のURL分類、課題ページ特定
Web Vitals拡張機能	Lab（ローカル）	ページ閲覧時のリアルタイム計測

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

Chrome User Experience Report公式によると、CrUXのデータ集計は「過去28日間のローリングウィンドウ」で行われています。今日改善を本番反映しても、その効果が完全に数値として反映されるまでは約28日かかります。改善直後にPSIのフィールドデータを見て「変わっていない」と早合点しないことが大切です。Search ConsoleのCore Web Vitalsレポートも同様のローリング基準で集計されています。改善後1〜2週間は推移を観察し、4週後に最終評価する流れが現実的です。

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

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

4ステップの全体像

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

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

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

よくある質問（FAQ）

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

Google検索セントラル公式によると、Core Web Vitalsはページエクスペリエンス評価の一部としてランキングシグナルに組み込まれていますが、コンテンツ品質を上回るほど強い影響は持たないとされています。実態としては、競合と内容が拮抗している場合のタイブレイカーとして作用します。Poor判定の指標を放置すると確実に不利になるため、最低でも全指標で「Good」を達成しておくのが現実的な目標です。

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

はい、2024年3月12日にCore Web Vitalsの構成指標から外れ、INPに置き換わりました（Chrome Developers Blog公式アナウンス）。一部の旧来ツールではFIDが表示される場合がありますが、Googleのランキング評価には使われていません。FIDが「Good：100ms以下」だったのに対しINPは「Good：200ms以下」と基準値も異なるため、過去のFID改善実績の数値はINPへそのまま読み替えるのではなく、INP基準で再計測する必要があります。

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

原則としてモバイルを優先します。Googleはモバイルファーストインデックスを採用しており、検索評価はモバイル版を基準に行われるためです。さらにモバイルは回線条件・端末性能の幅が広く、平均的にスコアが低くなる傾向があります。リソースが限られる場合は「モバイルの赤い指標」から手をつけ、「PCの赤い指標」「モバイルの黄」「PCの黄」の順に優先度を下げていくのが効率的です。

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

Chrome User Experience Report公式によると、CrUXは「過去28日間のローリングウィンドウ」でデータを集計します。改善を本番反映してもフィールドデータが完全に置き換わるまで約28日かかるため、直後の数値変動は限定的です。また、CrUXには「十分なデータ量があるページ」のみ表示されるため、トラフィックの少ないページではフィールドデータ自体が出ない場合があります。その場合はラボデータでの改善を継続するか、サイト全体のオリジン値を参照するのが代替手段です。

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

まずChrome DevToolsのPerformanceパネルまたはLong Animation Frames API（LoAF）で「どのインタラクションが遅いか」「どのスクリプトがメインスレッドをブロックしているか」を特定します。多くの場合、サードパーティ製のタグ（広告・アナリティクス・チャットウィジェット）か、自社実装のイベントハンドラ内の重い処理が原因です。原因スクリプトを特定したら、処理の分割（scheduler.yield）、遅延読み込み（dynamic import）、不要な処理の削除、の3アプローチで対応します。具体的なコード例はページ速度改善の実装ガイドを参照してください。

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

変わる可能性は十分にあります。実際FIDからINPへの置換は「より厳しい応答性評価」への移行でしたし、各指標のしきい値もWeb全体の高速化に応じて引き締められる可能性があります。web.dev公式でも「現在の閾値は『現実的に達成可能な良い体験』のレベルであり、Webプラットフォーム全体が進化すれば見直される」と明記されています。施策は「今の閾値を超えるだけ」ではなく、可能な限り高速化しておくと将来の基準変更にも耐えやすくなります。

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

必要ありません。Googleの評価軸は「フィールドデータで全指標がGoodを満たすこと」であって、PageSpeed Insightsのラボスコア（0〜100点）が高いことは直接的なランキング要因ではないからです。実務的にはラボスコアが80点以上、かつフィールドデータでGoodがついていれば十分です。100点に拘って細かいOpportunities対応にリソースを割くより、コンテンツ品質や内部リンク構造の改善に時間を使う方が、サイト全体のSEO投資対効果は高くなります。

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

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判定が発生したら都度対応する運用体制が現実解です。継続計測の仕組みを作ることが、Core Web Vitals施策の最大の成果につながります。

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