Core Web Vitals を平易に解説：LCP、INP、CLS

Core Web Vitals は、Webサイトの性格診断ではない

Core Web Vitals は、しばしば謎めいた成績表のように扱われます。ページに赤い数値が付き、誰かが Slack にスクリーンショットを投稿し、チームは JavaScript フレームワークについて議論し始めます。

これは特に有用ではありません。

Core Web Vitals を理解するうえでより良い考え方は、もっと単純です。実際のデバイスを使う実際の人にとって、そのページが使いやすく感じられるかどうかを示す3つの測定値です。パフォーマンス、アクセシビリティ、品質のすべてを捉えるものではありません。しかし、よくある3つの不満の原因を捉えます。

• 主要なコンテンツが表示されるまでに時間がかかりすぎる。
• ユーザーが何かしようとしたとき、ページの反応が遅い。
• ユーザーが読んだりタップしたりしている最中にレイアウトが動く。

これが3つの Core Web Vitals、LCP、INP、CLS です。

Google はこれらをページ エクスペリエンス シグナルの一部として使用していますが、SEO の観点は重視する最良の理由ではありません。より良い理由は、遅く、ガタつき、反応の悪いページはユーザーの時間を無駄にするからです。そうしたページは、コンバージョンが悪くなり、サポート負荷も高まり、時間が経つほど劣化しやすい傾向があります。

3つの指標を一文で説明する

詳細に入る前に、平易に言うと次のようになります。

• LCP、つまり Largest Contentful Paint は、主要な可視コンテンツが読み込まれるまでの時間を測ります。
• INP、つまり Interaction to Next Paint は、訪問中のユーザー操作に対してページがどれだけ素早く反応するかを測ります。
• CLS、つまり Cumulative Layout Shift は、ページが予期せずどれだけ動くかを測ります。

一般的なしきい値は次のとおりです。

| Metric | 良好 | 改善が必要 | 不良 | |---|---:|---:|---:| | LCP | 2.5秒以下 | 2.5秒〜4.0秒 | 4.0秒超 | | INP | 200ms以下 | 200ms〜500ms | 500ms超 | | CLS | 0.1以下 | 0.1〜0.25 | 0.25超 |

これらの数値は通常、実ユーザー訪問の 75パーセンタイル で評価されます。これは重要です。完璧なラボ測定を1回作ることが目的ではありません。遅いスマートフォンや不安定なネットワークを使う人も含め、大半のユーザーにとって体験を良くすることが目的です。

自動レポートを見つめながら、どこから始めればよいかわからない場合は、診断とパニックを切り分けることが役立ちます。そのワークフローをより詳しく扱った、慌てずに Lighthouse レポートを読むための別ガイドもあります。

LCP：ページはいつ読み込まれたと感じられるのか？

Largest Contentful Paint は、ビューポート内で最も大きな可視コンテンツ要素のレンダリング時刻を測定します。実務上、それは多くの場合、次のようなものです。

• ヒーロー画像、
• 大きな見出し、
• 注目記事の画像、
• 商品画像、
• 大きなテキストブロック。

LCP が問うているのは、すべてのスクリプト、トラッキングピクセル、ファーストビュー外の画像の読み込みがいつ終わったかではありません。問うているのは、ユーザーが見に来た主要なものがいつ表示されたかです。

そのため LCP は、昔ながらの「ページ読み込み時間」よりも人間に近い指標です。ページが技術的には遅く読み込み完了しても、主要コンテンツがすばやく表示されれば速く感じられます。逆も同じです。ヒーロー領域がまだ空白、ぼやけた状態、またはレンダリング遅延でブロックされているのに、ページの load イベントだけが発火することもあります。

LCP が悪化する一般的な原因

LCP の悪化の多くは、いくつかの予測しやすい場所から生じます。

1. サーバーレスポンスが遅い

HTML ドキュメントの到着が遅ければ、それ以外のすべても遅れて始まります。

1. レンダリングをブロックする CSS や JavaScript

ブラウザはコンテンツを持っていても、まだ描画できません。

1. 最適化されていないヒーロー画像

最大要素が大きすぎる、形式が不適切、優先度が低い、または誤って遅延読み込みされている場合があります。

1. Webフォントによるテキストレンダリングの遅延

大きな見出しが LCP 要素になることがあり、フォント読み込みがそれを遅らせたり、見た目を変えたりします。

1. クライアントサイドレンダリングの遅延

意味のあるコンテンツを表示する前に大きな JavaScript バンドルが必要なページでは、LCP が悪化します。

LCP を改善する方法

実際の LCP 要素から始めてください。ブラウザが何を測定しているのかを把握する前に、無作為にアセットを最適化しないことです。

実践的な修正には次のようなものがあります。

• HTML をすばやく配信する：適切にキャッシュし、バックエンド処理を減らし、遅いリダイレクトを避ける。
• LCP 画像を最適化する：適切な寸法、圧縮、形式を使う。
• ファーストビュー内のヒーロー画像を遅延読み込みしない。
• メイン画像が本当に優先対象である場合は、fetchpriority="high" を慎重に使う。
• クリティカル CSS は、レンダリング遅延を意味のある形で減らせる場合に限ってインライン化する。
• 最初の意味のあるレンダリングまでに必要な JavaScript を減らす。
• font-display: swap または別の意図的なフォント戦略を使う。

画像とフォントは頻繁に原因になります。画像については、トレードオフは単に「ファイルが小さいほど良い」ではありません。形式の選択、エンコードの手間、ブラウザサポートがすべて関係するため、私たちは AVIF が WebP に勝る場合とそうでない場合 の実践的な判断ツリーを用意しています。文字量の多いページでは、多くのサイトが実際に使う以上のフォントファイルを配信しているため、Webフォントはいまでも最も簡単なパフォーマンス改善のひとつ です。

INP：触れたときにページは反応するか？

Interaction to Next Paint は応答性を測ります。より具体的には、ユーザー操作から、ブラウザがその操作を処理した後の次の視覚的更新までの遅延を見ます。

操作には次のようなものが含まれます。

• ボタンのクリック、
• メニューのタップ、
• チェックボックスの選択、
• フォームフィールドへの入力、
• アコーディオンを開くこと。

INP は 2024 年に First Input Delay に代わって Core Web Vital になりました。これは良い変更でした。First Input Delay は最初の操作だけを見ていました。INP はより広く、ページ訪問全体の操作を考慮し、高遅延の操作をそのページの応答性スコアとして報告します。

平易に言うと、INP は、読み込まれているように見えるのに固まっているように感じるページを見つけます。

おそらく、あなたもこのようなページを使ったことがあるでしょう。準備できているように見えます。メニューをタップします。半秒間何も起きません。もう一度タップします。すると2つのことが同時に起きます。これは INP の問題です。

INP が悪化する一般的な原因

INP は通常、メインスレッドの問題です。ブラウザは反応したいのに、JavaScript、レンダリング処理、またはレイアウト計算が邪魔をしています。

典型的な原因には次のようなものがあります。

• 大きな JavaScript バンドル、
• 高コストなイベントハンドラー、
• クライアントレンダリングアプリでのハイドレーション処理、
• メインスレッドを奪い合うサードパーティスクリプト、
• ページ読み込み後の長時間タスク、
• 小さな操作によって引き起こされる複雑な DOM 更新、
• レイアウトスラッシング。コードがレイアウト値の読み取りと書き込みを繰り返す状態です。

マーケティングタグ、アナリティクス、チャットウィジェット、同意バナーはいずれも影響する可能性があります。これは「すべて削除せよ」という意味ではありません。ページ上のすべてのスクリプトにはコストがあり、そのコストが目に見えやすい場所がインタラクション遅延だという意味です。

INP を改善する方法

INP の改善は、ひとつの魔法の属性というより、メインスレッドの競合を減らすことです。

有用なアプローチには次のようなものがあります。

• 長い JavaScript タスクを小さな塊に分割する。
• 必須でない処理は、ページが使えるようになってから後回しにする。
• 使っていない JavaScript は、単に minify するのではなく削除する。
• イベントハンドラーを小さく、予測可能に保つ。
• 小さな状態変更のためにインターフェイスの大部分を再レンダリングしない。
• 可能な場合は、単純な視覚状態に CSS を使う。
• サードパーティスクリプトを監査し、必要な場所でだけ読み込む。

インタラクション設計にも目を向けてください。ボタンが即座に視覚的フィードバックを返せば、その後の処理に時間がかかっても、より反応が良いように感じられます。これはパフォーマンスの代替ではありませんが、優れたインターフェイス設計の一部です。アクセシブルな Web ボタン のチェックリストとも重なります。明確な状態、適切なセマンティクス、予測可能な挙動は、ユーザーとブラウザの双方を助けます。

CLS：ページはユーザーの期待する位置に留まるか？

Cumulative Layout Shift は、可視要素の予期しない移動を測ります。ユーザーが段落を読み始めたとき、その上に広告、画像、バナーが読み込まれてテキストが下に押し出されると、それは CLS に影響します。

CLS は秒で測定されません。どれだけのコンテンツが、どれだけ遠くへ動いたかに基づくスコアです。低いほど良好です。

重要な言葉は 予期しない です。ユーザー操作によって起きるレイアウト変更は、通常同じようにはカウントされません。誰かが「もっと見る」をタップしてコンテンツが展開されるなら、それは予期されたものです。ニュースレターバナーが3秒後に上部に現れてすべてを下へ押し下げるなら、それは予期されていません。

CLS が悪化する一般的な原因

CLS の失敗は、多くの場合ありふれています。

• width 属性と height 属性のない画像、
• 予約領域のない広告や埋め込み、
• コンテンツの上に挿入される cookie バナー、
• 異なるメトリクスで差し替わる Webフォント、
• 遅れて読み込まれるプロモーションバー、
• ページ上部付近に動的に挿入されるコンテンツ。

修正は通常、コンテンツが到着する前に領域を確保することです。ブラウザはページの形をできるだけ早く知っているべきです。

CLS を改善する方法

可視のずれから始めてください。録画を見るか、ブラウザツールを使って、どの要素が動いているのかを特定します。

そのうえで、地味な修正を適用します。

• 画像に明示的な width 属性と height 属性を追加する。
• レスポンシブなメディアコンテナには CSS の aspect-ratio を使う。
• 広告、埋め込み、iframe のために固定または最小の領域を予約する。
• 読み込み後に既存コンテンツの上へバナーを挿入しない。
• 最終フォントに近いメトリクスのフォールバックフォントを選ぶ。
• top、left、width、height のようなレイアウトプロパティを変更するアニメーションを避け、transform を優先する。

CLS は、巧妙さより規律が勝つ数少ないパフォーマンス指標のひとつです。ページに安定した箱があれば、良いスコアになりやすいものです。

フィールドデータとラボデータはどちらも有用だが、答える問いが異なる

よくある混乱の原因は、ツールによって異なる数値が表示されることです。それは普通のことです。

フィールドデータ は実ユーザーから得られます。実際のデバイス、ネットワーク、場所、ブラウザ条件を反映します。Google の Chrome User Experience Report はフィールドデータの一例です。

ラボデータ は制御されたテスト環境から得られます。Lighthouse がよく知られた例です。再現性がありデバッグに役立ちますが、ユーザーの実際の体験と同じではありません。

ユーザーに実際の問題があるかどうかを判断するにはフィールドデータを使います。その問題を再現し、デバッグするにはラボデータを使います。

また、Core Web Vitals は通常、ブランドの単一の抽象的な性質としてではなく、URL または URL グループごとに評価されることも覚えておいてください。ホームページ、ブログ記事、料金ページ、チェックアウトでは、ボトルネックが大きく異なる場合があります。

現実的な作業順序

3つの指標がすべて悪い場合、あらゆる場所から着手したくなります。それをこらえてください。

実践的な順序は次のとおりです。

1. 明らかな CLS を先に直す

画像サイズの欠落や不安定なバナーは、しばしば手早い改善になります。

1. 重要なテンプレートの LCP を改善する

商品ページ、ランディングページ、記事、サインアップフローなど、重要なページに集中します。

1. 実際の操作で INP を調査する

ユーザーが実際にクリックするものをクリックしてください。メニュー、フィルター、フォーム、チェックアウトのコントロールは、初期読み込みのトレースより多くのことを示すことがよくあります。

1. サードパーティスクリプトを監査する

コストに見合うものは残します。そうでないものは削除するか遅らせます。

1. パフォーマンス予算を設定する

予算がなければ、パフォーマンス改善は劣化します。新しいスクリプト、画像、デザインコンポーネントが、静かに成果を元に戻してしまいます。

重要なのは、バッジのために最適化しないことです。ユーザージャーニーのために最適化してください。トラフィックの少ないページでのわずかなスコア改善より、少し不完全でもはるかに速いチェックアウト操作のほうが重要な場合があります。

<!-- tool-cta:start -->

💡 試してみてください: LCP は通常画像の問題なので、まずは簡単な改善として Image Compressor でヒーロー画像を小さくしましょう。

<!-- tool-cta:end -->

Core Web Vitals が教えてくれないこと

Core Web Vitals は有用ですが、不完全です。

コンテンツが良いかどうかは教えてくれません。ナビゲーションが理にかなっているかも教えてくれません。アクセシビリティを保証するものでもありません。プライバシー、セキュリティ、信頼、読みやすさ、またはページがユーザーの疑問に答えているかどうかも測定しません。

判断の代わりにもなりません。Core Web Vitals に合格していても不快なページはあり得ます。複雑なアプリケーションは、制約の中で責任ある設計がなされていても、しきい値を下回ることがあります。

LCP、INP、CLS を火災報知器のように扱ってください。鳴ったら調査します。静かであっても、建物の保守は続けます。