Core Web Vitalsは何から改善する？LCP・INP・CLSの優先順位

Core Web Vitalsを改善するとき、PageSpeed Insightsの総合点を100に近づけることから始める必要はありません。先に見るべきなのは、実際の訪問者データでLCP・INP・CLSのどれが基準を外しているかです。そのうえで、基準を外したURL群の共通原因から直すのが最短ルートです。

2026年9月20日時点で、Googleが示す「良好」の目安は次の3つです。

指標	何を測るか	「良好」の目安
LCP	主なコンテンツが表示される速さ	2.5秒以下
INP	操作してから画面が反応するまで	200ミリ秒以下
CLS	表示中にレイアウトがずれる度合い	0.1以下

基準値はGoogle Search CentralのCore Web Vitals解説で確認しました。この記事では、実機計測を行った体験談ではなく、Googleの公式資料をもとにした調査・整理として、改善の順番を具体化します。

結論：優先順位は「不良URLの多さ×影響範囲×直しやすさ」で決める

3指標に固定の優先順位はありません。まずSearch ConsoleのCore Web Vitalsレポートで「不良」または「改善が必要」なURL群を確認し、次の順で着手候補を並べます。

テンプレート共通の問題：ヘッダー、記事hero、広告枠など、1回の修正で多くのURLに効く
「不良」のURL群：「改善が必要」より先に、明確に基準から外れたグループを見る
主要な流入・成果ページ：検索流入や問い合わせなど、利用者への影響が大きいページを優先する
少ない変更で検証できる問題：画像サイズ指定、不要なJavaScript、後挿入要素など、原因と修正の対応が明確なものから試す

たとえば、記事一覧の大半でLCPが遅く、原因が共通のhero画像なら、個別ページの細かなCLSより先に画像配信を見直す価値があります。一方、予約ボタンの反応が遅いなら、対象URLが少なくてもINPを優先すべきです。「LCP→INP→CLS」と機械的に並べるのではなく、読者が困る場面と修正の波及範囲で決めます。

LCP・INP・CLSは、それぞれ何が悪いのか

LCP：ファーストビューの主役が出るまでの時間

LCP（Largest Contentful Paint）は、画面内で主要な画像や大きなテキストブロックが描画されるまでを測ります。記事サイトではhero画像や大見出しが対象になりやすく、次のような原因を切り分けます。

hero画像が必要以上に大きい、または適切な形式・圧縮になっていない
LCP画像まで遅延読み込みしている
WebフォントやCSSが描画を長く止めている
サーバー応答やHTML生成そのものが遅い
LCP要素の取得をブラウザが遅く発見している

最初の一手は、PageSpeed Insightsの診断でLCP対象要素を特定し、その要素が「いつ発見され、いつ取得され、いつ描画されたか」を見ることです。画像が原因なら、表示寸法に合う画像を配信し、幅と高さを指定したうえで、ファーストビューの画像を安易に遅延読み込みしないようにします。

INP：クリックや入力への反応の遅さ

INP（Interaction to Next Paint）は、クリック、タップ、キーボード入力といった操作に対する応答性を示します。読み込み直後だけでなく、ページ滞在中の操作が対象です。

原因になりやすいのは、メインスレッドを長時間占有するJavaScriptです。

初期化処理や計算を一度に実行している
使っていないウィジェットやタグを全ページで読み込んでいる
入力のたびに大きなDOM更新や重い再計算をしている
1つの長い処理が、ユーザー操作への応答を待たせている

改善では、不要なスクリプトを消す、機能を必要なページだけで読み込む、長い処理を分割する、入力イベントの処理量を減らす、という順が基本です。JavaScriptをすべて削るのではなく、「そのページで本当に必要か」「操作直後にすべて実行する必要があるか」を分けて考えます。

CLS：読もうとした場所が動く不快さ

CLS（Cumulative Layout Shift）は、予期しないレイアウト移動の度合いです。画像の読み込み後に本文が押し下げられたり、押そうとしたボタンの上に別要素が差し込まれたりする現象が代表例です。

画像・動画・埋め込みに表示領域が予約されていない
広告や通知を既存コンテンツの上へ後から挿入している
Webフォント切り替えで文字幅が大きく変わる
JavaScriptで高さ未確定の要素を追加している

画像にはwidthとheight、またはCSSのaspect-ratioで先に場所を確保します。広告や外部埋め込みも想定サイズの枠を用意し、後から表示する案内は既存の本文を押し下げない配置を検討します。

PageSpeed InsightsとSearch Consoleは役割が違う

改善で混乱しやすいのが、「手元では速いのにSearch Consoleでは不良」「PageSpeed Insightsを測るたびに点数が違う」という状況です。これは、計測対象と期間が違うために起こります。

PageSpeed Insightsの公式説明によると、同ツールはChrome UX Report由来の実ユーザーデータ（フィールドデータ）と、Lighthouseによる診断用データ（ラボデータ）の両方を表示します。

見る場所	得意なこと	注意点
Search Console	サイト全体の問題URL群を発見する	URL単体の原因特定には向かない
PageSpeed Insightsのフィールドデータ	実ユーザー環境での傾向を確認する	十分なデータがないURLでは表示されないことがある
PageSpeed Insightsのラボデータ	修正前後の診断、原因候補の発見	1回の測定を実ユーザー全体の結果とはみなせない
Chrome DevTools	処理やレイアウト移動を詳細に追う	計測した端末・条件内の再現結果である

つまり、Search Consoleで対象を決め、PageSpeed InsightsとDevToolsで原因を探し、修正後にフィールドデータで確かめるという流れが合理的です。ラボの総合スコアだけをKPIにすると、実際の問題URLを見失いやすくなります。

30分でできる改善優先度の付け方

1. モバイルとパソコンを分けて確認する

Search ConsoleのCore Web Vitalsレポートを開き、モバイルとパソコンを別々に見ます。両者は通信・端末性能・画面構成が異なるため、一方の結果で代用しません。Search Consoleヘルプでも、レポートはモバイルとPCに分け、ステータスや指標が似たURLをグループ化して示すと説明されています。

2. URL群の共通テンプレートを探す

不良URLを1ページずつ直す前に、同じレイアウト、画像パターン、外部スクリプトを使っていないか確認します。記事詳細だけでLCPが悪いならhero、商品詳細だけでCLSが悪いなら画像ギャラリー、全ページでINPが悪いなら共通タグ、といった仮説を立てられます。

3. 代表URLをラボ計測する

URL群から代表的な1〜3ページを選び、PageSpeed Insightsで診断します。ここでは点数そのものより、LCP要素、長いJavaScript処理、レイアウト移動を起こした要素など、修正に結びつく情報を記録します。

4. 変更を小さくして比較する

複数の大改修を一度に入れると、どの変更が効いたか分からなくなります。「hero画像の配信サイズを修正」「全ページ共通の不要タグを停止」のように変更単位を分け、同じ条件でラボ計測を繰り返します。

5. 公開後は実ユーザーデータを待つ

ラボ結果が改善しても、実際の訪問者全体で同じ結果になるとは限りません。公開後はSearch Consoleの検証機能を使い、Core Web Vitalsレポートの推移を確認します。短時間で表示が変わらなくても、すぐに修正失敗と判断しないことが大切です。

指標別チェックリスト

LCPが悪いとき

LCP対象要素を特定した
hero画像を表示寸法に合うサイズ・形式で配信している
ファーストビューの主画像を遅延読み込みしていない
CSS、フォント、サーバー応答の待ち時間を確認した
モバイル回線・端末でも確認した

INPが悪いとき

反応が遅い操作を再現した
不要な第三者スクリプトを洗い出した
長い処理を分割できないか確認した
入力のたびに不要な再計算をしていない
JavaScriptを必要なページだけに配信している

CLSが悪いとき

画像と埋め込みの表示領域を予約した
広告・通知を本文の上へ後挿入していない
フォント切り替え時のずれを確認した
スクロール後に発生する移動も確認した
モバイル幅で要素の折り返しを確認した

Core Web VitalsだけをSEOの答えにしない

GoogleはCore Web Vitalsを検索での成功と良いユーザー体験のために推奨していますが、3指標だけで検索順位が決まるわけではありません。読みたい答えがないページを高速化しても、コンテンツの不足は解消しません。

優先順位は、まず検索意図に答える内容、クロール・インデックスの問題、モバイルで読める設計を整え、その品質を損なわないよう表示速度と操作性を改善することです。タイトルや内部リンク、構造化データも含めた基本は、個人メディア運営者が押さえておきたいSEOの基本で整理しています。

Core Web Vitals改善の出発点は、100点を目指すことではありません。実ユーザーデータで問題のあるURL群を見つけ、共通原因を1つ直し、ラボとフィールドの両方で確かめる。この小さな循環を、影響の大きいテンプレートから回すのが現実的です。

参考資料

Understanding Core Web Vitals and Google search results（Google Search Central）（2026年9月20日確認）
About PageSpeed Insights（Google for Developers）（2026年9月20日確認）
Core Web Vitalsレポート（Search Consoleヘルプ）（2026年9月20日確認）