Core Web Vitals:LCP、INP、CLSと25の改善策

Core Web Vitals:LCP、INP、CLSの解説

Core Web Vitals解説:LCP、INP、CLSとコード付き改善策25選 | We.Inc

LCP、INP、CLSが何を測るか、良好と不良のしきい値、フィールドデータとラボデータの違い、このページのライブ計測、原因別に整理したコード付きの改善レシピ25個、プラットフォーム別の注意点を解説します。

Core Web Vitalsは、実際の訪問を対象にした3つの指標です。Largest Contentful Paint(読み込み、2.5秒以下で良好)、Interaction to Next Paint(応答性、200ミリ秒以下で良好)、Cumulative Layout Shift(視覚的な安定性、0.1以下で良好)。訪問の75%以上が3つすべてを満たすと、そのページは合格です。

良好なスコア

下のメーターは、このページを操作している間、あなたのブラウザーで計測します。その後、不合格になっている指標を見つけ、その指標のレシピを順に試してください。各レシピには、解決する原因とコードを載せています。

よくある質問

First Input Delayは何に置き換わりましたか?

2024年3月に、Interaction to Next PaintがFirst Input Delayに代わってCore Web Vitalの1つになりました。INPは最初の操作だけでなくページ上のすべての操作を対象にし、結果が描画されるまでの時間も含みます。

Lighthouseのスコアは良いのに、Core Web Vitalsが不合格なのはなぜですか?

Lighthouseは、シミュレートした1台の端末での1回のテストです。Core Web Vitalsは、より遅いスマートフォンや回線を使う実際の訪問者の28日分のデータを使い、Lighthouseでは計測できないINPも含みます。

Core Web VitalsはGoogleの検索順位に影響しますか?

Googleのページエクスペリエンスのシグナルの一部です。Googleは関連性とコンテンツの質のほうがはるかに重要だと説明しているため、良いVitalsが最も効くのは、ほかの点でページが同程度のときです。

改善が反映されるまでどのくらいかかりますか?

フィールドデータは直近28日間を対象にしているため、デプロイ後およそ4週間かけて少しずつ改善が表れます。

速度スコアとの違い

3つの指標

しきい値(実際の訪問の75パーセンタイルで判定)

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

フィールドデータとラボデータの比較

LCPの改善(レシピ1〜9)

1. ヒーロー画像を最初に取得する

fetchpriority="high"で、この画像が最も重要だとブラウザーに伝えます。LCP画像は決して遅延読み込みしないでください。

2. CSSで設定したLCP画像をプリロードする

背景画像はCSSの読み込み後と、見つかるのが遅くなります。headでプリロードすれば、すぐにダウンロードが始まります。

3. 適切なサイズを配信する

srcsetとsizesを使えば、スマートフォンはデスクトップ用ではなく小さいファイルをダウンロードできます。

4. モダンな画像フォーマットを使う

AVIFとWebPは、同じ画質ならJPEGよりかなり小さいことが一般的です。pictureを使えば、古いブラウザーはフォールバックできます。

5. フォントの読み込み中に文字を隠さない

font-display: swapは代替フォントの文字をすぐに表示するので、LCP要素である見出しがフォントのダウンロードに足止めされません。

6. 画像CDNに早めに接続する

preconnectは、後で必要になるサードパーティのオリジンに対して、DNS、TCP、TLSのハンドシェイクを前もって済ませます。

7. ページ表示に不要なスクリプトを遅らせる

deferやasyncのないheadのスクリプトはレンダリングをブロックします。deferは順序を保ちつつ、HTMLの解析が終わるまで待ちます。

8. 空の器ではなく本物のHTMLを送る

LCP要素がJavaScriptで作られる場合、バンドルがダウンロードされて実行されるまで何も描画できません。サーバーレンダリングやプリレンダリングなら最初のレスポンスに含められます。選択肢については、シングルページアプリのSEOガイドをご覧ください。

9. HTMLをエッジでキャッシュする

サーバーの応答が遅いと、すべてが遅れます。静的なページはCDNでキャッシュし、適切なCache-Controlを設定しましょう。

INPの改善(レシピ10〜17)

10. 長いタスクを分割する

50ミリ秒を超えるタスクは入力をブロックします。処理の合間にメインスレッドへ制御を譲り、その間にクリックを処理できるようにします。scheduler.yieldは比較的新しい機能で、setTimeoutのフォールバックはどこでも動作します。

11. 先にフィードバックを描画し、処理は後で

ボタンの表示をすぐに更新し、ブラウザーが描画する機会を得てから重い処理を行います。

12. 入力に連動する処理をデバウンスする

キーを押すたびに長いリストを絞り込むと、入力がもたつきます。少し間が空くのを待ちましょう。

13. 遅いReactの更新をトランジションとしてマークする

startTransitionを使うと、Reactは入力の応答性を保ち、重い結果は可能になった時点で描画します。

14. サードパーティのスクリプトを遅らせる

チャットウィジェットやタグマネージャーは、読み込み時に重いコードを実行することがよくあります。ページがアイドルになった後か、最初の操作時に読み込みましょう。

15. DOMを小さく保つ

巨大なページでは、スタイルやレイアウトの更新がすべて遅くなります。content-visibilityは、画面外のセクションが近づくまでレンダリングを省略します。

16. 書き込みのループ内でレイアウトを読み取らない

スタイルを変えるたびにoffsetHeightを読むと、毎回レイアウトが強制されます。先にすべて読み取り、その後で書き込みましょう。

17. 重い計算をWeb Workerに移す

大きなファイルの解析や何千行もの並べ替えは、クリックをブロックせずにワーカーで実行できます。

CLSの改善(レシピ18〜25)

18. 画像と動画にサイズを指定する

widthとheightがあれば、ファイルが届く前にブラウザーが領域を確保できます。それでもCSSでレスポンシブにできます。

19. 埋め込み用の領域を確保する

地図、動画、iframeは読み込みが遅いことがよくあります。aspect-ratioでボックスの大きさを保ちます。

20. バナーや広告の領域を確保する

読んでいる部分の上にコンテンツが挿入されると、読んでいる部分が押し下げられます。前もって枠に最小の高さを指定しましょう。

21. 代替フォントのサイズを合わせる

Webフォントに切り替わると、文字が折り返し直されることがあります。ローカルの代替フォントにsize-adjustを指定すると、両者の幅が近づきます。

22. topやheightではなくtransformでアニメーションさせる

transformで動かしてもほかの要素は動かないので、レイアウトシフトとして数えられません。

23. Cookieバーはコンテンツを押し下げず重ねて表示する

画面下部に固定したバーはページを動かしませんが、上部に挿入したバーは動かします。

24. コンテンツと同じサイズのスケルトンを使う

読み込み中のプレースホルダーは、置き換わる内容と同じ領域を占めるべきです。

25. バックフォワードキャッシュを有効に保つ

バックフォワードキャッシュから復元されたページは、新たなシフトなしで即座に表示されます。unloadハンドラーはそれを妨げるので、代わりにpagehideを使いましょう。

プラットフォーム別の注意点

プラットフォーム別の注意点

LCPの原因はたいてい画像です。画像を小さくするには

WebP変換ツール

このページのライブ計測

対応ブラウザーでは、このページのLCP、CLS、INPをあなたのブラウザー内で計測します。

良好

改善が必要

不良

このブラウザーでは非対応

INP(これまでで最も遅い値)

最大の描画を待っています

どこかをクリックまたは入力すると計測します

無料で始める · クレジットカード不要

関連: ガイド|Webマーケティングと集客を学ぶ

製品

ご利用いただける方

機能

リソース

会社情報

サイトマップを見る