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

PageSpeed Insightsを開く。

赤い数字。黄色い数字。LCP、INP、CLS。

一気に直したくなります。

でも、全部を同じ熱量で追うと、肝心の「読んでいて気持ちいいか」が置いていかれがち。

ページを開いたら主役の画像がすっと出る。ボタンを押せば、間を置かず反応。読んでいる途中で、文字がガクッと動かない。

Core Web Vitalsが見ているのは、結局こういう体感です。

結論。優先順位は“影響の大きさ”で決める

LCP→INP→CLSという固定順はありません。

見るのは、

不良URLの多さ × 影響範囲 × 直しやすさ。

まずSearch Consoleで問題URL群を確認。

優先候補は、

共通テンプレートの問題
「不良」のURL群
流入・成果の大きいページ
少ない変更で検証できるもの

記事の大半でLCPが悪く、原因が共通heroなら、そこを直す方が効く。

逆に、予約ボタンだけ反応が遅いなら、URL数が少なくてもINP優先。

大事なのは指標順ではなく、読者がどこで困っているか。

LCP。最初に見たいものが出てこない

LCPは、画面内の主要画像や大きなテキストが表示されるまでの時間。

記事サイトなら、hero画像や大見出しが対象になりやすいところ。

原因候補は、

hero画像が大きすぎる
LCP画像まで遅延読み込み
WebフォントやCSS待ち
サーバー応答が遅い
ブラウザがLCP要素を見つけるのが遅い

まず、PageSpeed InsightsでLCP対象要素を特定。

“何が遅いか”が分からないまま画像を全部圧縮しても、遠回りです。

画像が原因なら、表示サイズに合わせる。幅と高さを指定。ファーストビューの主画像を安易にlazy loadしない。

ひとつずつ。

INP。押したのに、少し待つ

ボタンを押す。一瞬、何も起きない。

短い待ち時間でも、操作では妙に長く感じます。

INPはクリック、タップ、入力への応答性を見る指標。

犯人になりやすいのは、重いJavaScriptです。

初期化を一気に実行
不要ウィジェットを全ページで読む
入力のたび大きなDOM更新
長い処理が操作を待たせる

改善は、JavaScriptを全部消すことではありません。

今必要か。今すぐ実行する必要があるか。

この2つで分ける。

不要なら消す。あとでいいなら遅らせる。長いなら分割。

地味ですが効きます。

CLS。“読んでいた場所が動く”あの不快感

文章を読んでいたら、画像が読み込まれて本文がズレる。押そうとしたボタンが動く。

かなり嫌な体験です。

CLSが見るのは、この予期しないレイアウト移動。

原因は、

画像・動画の領域未確保
広告や通知の後挿入
Webフォント切り替え
高さ未確定の要素

対策の基本は、先に場所を空けること。

画像なら width と height。あるいは CSS の aspect-ratio。

表示されてから押しのけるのではなく、最初から“席を取っておく”。

PageSpeed InsightsとSearch Console。役割が違う

「手元では速いのに、Search Consoleは不良。」

よくあります。

計測対象と期間が違うからです。

PageSpeed Insightsの公式説明では、実ユーザーデータとLighthouseのラボデータの両方を扱います。

見る場所	得意なこと	注意点
Search Console	サイト全体の問題URL群を発見	単一URLの原因特定には弱い
PSI フィールドデータ	実ユーザー傾向	データ不足の場合あり
PSI ラボデータ	原因候補・修正前後	1回の測定が全体ではない
Chrome DevTools	処理を詳細に追う	手元の条件内

使い分けは、

Search Consoleで探す → PSI / DevToolsで原因を見る → 修正 → 実ユーザーデータで確認。

ラボスコア100点だけを目標にすると、本来直す場所を見失います。

30分で優先度を付ける

1. モバイルとPCを分ける

同じページでも、通信も端末性能も画面構成も違います。

Search ConsoleもモバイルとPCを分けて表示。

片方で代用しない。

2. 共通点を探す

1ページずつ直す前に、同じテンプレートかを見る。

記事詳細だけLCPが悪い。商品ページだけCLSが悪い。全ページINPが悪い。

ここから原因の当たりがつきます。

3. 代表URLを測る

1〜3ページを選び、PSIで診断。

点数ではなく、LCP要素、長いJavaScript、レイアウト移動を見る。

4. 一度に直しすぎない

hero画像もJSもフォントも全部変更。

これをやると、何が効いたか分かりません。

変更は小さく。

ひとつ直す。測る。次へ。

5. 公開後、すぐ結論を出さない

ラボが良くても、実ユーザーへ反映されるまで時間がかかります。

Search Consoleの表示がすぐ変わらないからといって、即失敗ではありません。

少し待つ。

これも改善作業の一部です。

指標別チェック

LCP

LCP対象を特定
hero画像のサイズ・形式確認
主画像をlazy loadしていない
CSS・フォント・サーバー応答確認
モバイルでも確認

INP

遅い操作を再現
不要な第三者スクリプト確認
長い処理を分割
入力時の再計算を確認
必要ページだけJS配信

CLS

画像・埋め込み領域を予約
広告・通知の後挿入確認
フォント切り替え確認
スクロール後のズレ確認
モバイル幅確認

Core Web VitalsだけでSEOは決まらない

ページが一瞬で開いても、答えがなければ意味がありません。

高速な空ページ。

それでは誰も満足しない。

GoogleはCore Web Vitalsを良いユーザー体験のために推奨していますが、3指標だけで順位が決まるわけではありません。

まず検索意図へ答える。クロール・インデックスを整える。モバイルで読めるようにする。

その上で、速さと操作性。

SEO全体の基本は、個人メディア運営者が押さえておきたいSEOの基本でも整理しています。

結論。100点より、“気にならない”サイト

Core Web Vitals改善で目指したいのは、100点のスクリーンショットではありません。

開いた瞬間に「遅い」と思わない。押したら普通に動く。読んでいる場所がズレない。

それで十分。

問題URL群を見つける。共通原因をひとつ直す。ラボと実データで確かめる。

この小さな循環を、影響の大きい場所から。

数字は大事。

でも、最後に見るのは読者の体感です。

参考資料

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日確認）