Core Web Vitalsを改善する方法:LCP、INP、CLSの実践ガイド

Core Web Vitalsは、ページを読み込んで使うときの体験を表すためにGoogleが使っている3つの計測値です。メインコンテンツがどれだけ速く表示されるか、誰かが操作したときにページがどれだけ速く反応するか、そしてレイアウトがどれだけガタつくか。これらはGoogleがページ体験を評価する要素の一部ですが、検索順位にとっては、関連性が高く役に立つコンテンツのほうがはるかに重要です。Core Web Vitalsは何よりも、サイトが速く感じられるかどうかを知るための良い目安になります。

3つの指標と「良好」の基準

• Largest Contentful Paint (LCP) — ビューポート内で最も大きな画像またはテキストブロックがレンダリングされた時点。良好: 2.5秒以下、不良: 4秒超。
• Interaction to Next Paint (INP) — クリック、タップ、キー入力に対して、ページが目に見える形で反応するまでにかかる時間。訪問全体を通して計測されます。良好: 200ミリ秒以下、不良: 500ミリ秒超。INPは2024年3月に、First Input Delayに代わってCore Web Vitalsの指標になりました。
• Cumulative Layout Shift (CLS) — 表示されているコンテンツが、予期せずどれだけ動くか。良好: 0.1以下、不良: 0.25超。

ページ読み込みの75%(75パーセンタイル)が各指標の「良好」のしきい値を満たしていれば、そのページは合格です。判定はモバイルとデスクトップで別々に行われます。つまり、遅いほうの4分の1の訪問者は評価に響きませんが、ミドルレンジのスマートフォンを使う典型的な訪問者は評価に含まれるということです。

ラボデータとフィールドデータ

フィールドデータは実際の訪問者から得られます。GoogleのChrome UX Reportが、データ提供に同意したChromeユーザーから直近28日間分を継続的に収集しており、Search Consoleの「ウェブに関する主な指標」レポートや、PageSpeed Insightsの上部に表示されるのがこのデータです。評価の対象になるのはこちらですが、十分なトラフィックが必要で、変化もゆっくりです。

ラボデータは、Lighthouseのように、管理された条件下でページを1回読み込んで得られます。どのページでもすぐに取得でき、指標がなぜ遅いのかを示してくれるので、診断のための道具になります。ただし、シミュレートされたスマートフォンでの1回のラボ実行が、訪問者の実際の端末や回線と一致することはありません。また、ラボテストではINPをまったく測定できません。誰もページを操作していないからです。ラボで得られる指標のうち最も近いのは、読み込み中にメインスレッドが忙しすぎて反応できない時間を表すTotal Blocking Time (TBT) です。

両方を使い分けましょう。問題があるかどうか、修正が効いたかどうかを知るにはフィールドデータ、原因を見つけるにはラボデータです。自前でフィールドデータを集めたい場合は、オープンソースのJavaScriptライブラリ web-vitals を使えば、実際の訪問から3つの指標すべてをアクセス解析に送信できます。

LCPを改善する

LCPの時間は4つの部分に分けられます。最初の1バイトが届くまでの時間(TTFB)、ブラウザがLCPリソースの読み込みを始めるまでの遅延、そのダウンロードにかかる時間、そしてレンダリングされるまでの遅延です。どの部分が大きいのかを突き止めたうえで、次の対策をとります。

• サーバーの応答を速くする。 ページキャッシュとCDNを使い、HTMLがすぐに届くようにします。
• LCP画像を早い段階で発見できるようにする: CSSの背景やJavaScriptで挿入する画像ではなく、HTML内の通常の <img> を使い、loading="lazy" は決して付けないでください。
• 優先度を上げる: LCP画像に fetchpriority="high" を付けるか、参照されるのが遅い場合はプリロードします。
• 小さくする: 表示サイズに合わせ、WebPまたはAVIFで配信します。画像サイズを小さくする方法を参照してください。
• レンダリングを妨げるリソースを取り除く: クリティカルCSSをインライン化し、必須でないスクリプトは遅延させ、メインコンテンツが表示される前に大がかりなクライアントサイドレンダリングを行うことは避けます。

INPを改善する

INPが遅くなるのは、誰かが操作したその瞬間にブラウザのメインスレッドが忙しい(たいていはJavaScriptを実行している)とき、または操作をきっかけに始まった処理の描画に時間がかかるときです。

• 配信するJavaScriptを減らす。 使っていないライブラリやプラグインを削除し、バンドルを分割し、インタラクティブである必要のない部分はハイドレーションしないようにします。
• 長いタスクを分割する。 50ミリ秒を超える処理は小さな単位に分け、その合間にブラウザへ制御を戻します。setTimeout か、対応している環境では scheduler.yield() を使います。
• イベントハンドラーでの処理を減らす。 まずUIを更新し、重い処理はそのあとで行います。入力ハンドラーにはデバウンスをかけます。
• サードパーティのスクリプトを棚卸しする。 チャットウィジェット、タグマネージャー、A/Bテストツールは、操作のたびに重いコードを実行していることがよくあります。あとから読み込むか、必要なときだけ読み込みましょう。
• DOMを適度な大きさに保つ。 DOMが大きいと、再レンダリングのたびに遅くなるからです。

CLSを改善する

• 画像と動画にサイズを指定する。 width 属性と height 属性、またはCSSの aspect-ratio を使い、読み込み前に領域が確保されるようにします。
• 広告、埋め込み、バナーのための領域を確保する。 コンテナに最小の高さを指定し、訪問者がすでに読んでいる部分より上にコンテンツを挿入しないでください。
• Webフォントを制御する。 font-display: swap または optional を使い、主要なフォントをプリロードし、メトリクスを合わせた代替フォント(size-adjust)を使って、Webフォントが届いたときのずれを小さくします。
• アニメーションにはtransformを使う。 top や height のように、周囲のコンテンツを動かしてしまうプロパティは避けます。
• バックフォワードキャッシュ(bfcache)が働くようにする — unload ハンドラーを避けましょう。そうすれば、戻ってきたときにページがずれなく瞬時に復元されます。

Rudraが役立つ場面

無料のサイト表示速度チェッカーは、Lighthouseの既定のモバイルシミュレーションでラボテストを1回実行します。各指標は計測値とともに表示され、1回の実行によるラボ計測であることが明記されたうえで、公開されているしきい値(LCP 2.5秒 / 4秒、CLS 0.1 / 0.25、TBT 200 / 600ミリ秒)と比較されます。不合格の監査項目には、原因となっているファイルや要素が最大5つ、推定される削減効果とともに表示されるので、どこから手を付ければよいかがわかります。INPの測定とフィールドデータは含まれません。それらはSearch ConsoleかPageSpeed Insightsで確認してください。ページ全体が遅い理由については、Webサイトが遅いのはなぜ?をご覧ください。

うまくいく進め方

1. Search Consoleの「ウェブに関する主な指標」レポートで、どの指標が、どのページグループで不合格になっているかを確認する。
2. そのグループから代表的なページを1つ選び、ラボテストを数回実行する。
3. 最も大きな原因から直し、デプロイして、ラボで再テストする。
4. フィールドデータが更新されるのを待ってから(集計期間は28日間です)、結果を判断する。