Core Web Vitals——2026年に本当に効く指標

Googleは明確にしました。ユーザー体験はランキング要因です。そしてこの文脈での「体験」は、3つの数字——Core Web Vitals——で測られます。閾値の外なら順位を落とし、内側なら順位が上がります。

LCP — Largest Contentful Paint

最大の可視要素が描画されるまでの時間を測ります。ヒーロー画像、大きな見出し、主要動画。閾値：2.5秒。4秒を超えると「poor」——Googleも分かっています。

よくある原因：最適化されていない画像、レンダーをブロックするフォント、遅いサーバ、キャッシュ不足。

INP — Interaction to Next Paint

2024年3月にFIDを置き換えました。ユーザー操作（クリック、タップ、キー入力）と画面反応の遅延を測ります。閾値：200ms。500msを超えると「poor」。

よくある原因：メインスレッドをブロックする重いJavaScript、まずく書かれたリスナー、過剰にレンダリングするフレームワーク。

CLS — Cumulative Layout Shift

ページ読み込み中にレイアウトがどれだけ跳ねるかを測ります。閾値：0.1。ボタンを押そうとした瞬間、広告に下へ押しやられたあの瞬間——それがCLSです。

よくある原因：width/heightのない画像、読み込み時にサイズが変わるフォント、ロード後に挿入される広告や埋め込み。

測定方法

PageSpeed Insightsはラボ（シミュレーション）とフィールド（Chrome User Experience Report経由の実ユーザー）の両方で測定します。両方見ましょう——ラボは制御された環境、フィールドこそがGoogleにとってのスコアです。

もう一つの方法：Search Console > Core Web Vitals。問題のある具体的なURLをパターンごとに表示してくれます。どこから手を付けるべきかを知る、最も直接的な方法です。

たいてい80%の問題を解く方法

• 画像をWebP/AVIFにし、HTMLで明示的にwidth/heightを指定する
• フォントはpreloadとfont-display: swapを使う
• JavaScriptを小さなchunkに分割し、非クリティカルなものはlazy loading
• サーバの前にCDNを置く（Cloudflare、Vercel Edge、Cloudfront）
• 公開コンテンツはサーバサイドレンダリングまたは静的生成にする
• 誰も使っていないのにまだバンドルに残っているライブラリを取り除く

この6点で、スコアが悪いサイトの大半は直ります。残りはケースバイケース——そこからが本格的な最適化作業の始まりです。