Core Web Vitals:LCP・INP・CLSの測定方法と改善方法

要点: Core Web Vitalsは、Googleが実際のユーザー体験を表すために使う3つの指標です。Largest Contentful Paint(LCP、読み込み、2.5秒以下で「良好」)、Interaction to Next Paint(INP、応答性、200ミリ秒以下で「良好」)、Cumulative Layout Shift(CLS、視覚的安定性、0.1以下で「良好」)です。それぞれ、過去28日間の実際のChromeユーザーによる訪問の75パーセンタイルで、モバイルとデスクトップを別々に評価します。Googleはこれらがランキングシステムで使われていると述べていますが、最優先されるのは関連性です。改善するには、各指標を構成要素に分解し、最も大きい部分から手を付けます。

Core Web Vitalsに関する情報の多くは、50個ものヒントを並べたリストです。そのため、チームがスプリントを丸ごと「パフォーマンス改善」に費やしても、数値がほとんど動かないことがよくあります。実際には、各指標はいくつかの測定可能な要素に分けられ、たいてい問題の大半は1つの要素が引き起こしています。

このガイドでは、3つの指標が何を測るのか、2026年10月時点の基準値、どのデータソースを信頼すべきか、Googleが検索順位について実際に何と述べているか、そして指標ごとの「まず診断する」改善手順を、web.devにあるGoogle公式ドキュメントに基づいて解説します。

Core Web Vitalsが測るもの

web.devのWeb Vitals概要によると、現在の安定版は3つの指標で構成されています。

基準値はAbout PageSpeed Insightsの表と一致しています。

75パーセンタイルのルール

Googleは、平均値や1回のテストでページを評価しません。web.devでは、測定の目安として「モバイルとデスクトップに分けた、ページ読み込みの75パーセンタイル」が適切だとされています。わかりやすく言えば、実際の訪問の少なくとも4分の3が「良好」の基準を満たす必要があるということです。合格するには、3つすべての指標で75パーセンタイルの結果が良好でなければなりません。

ここから、見落とされがちな2つの帰結が導かれます。

1. モバイルとデスクトップは別々に評価されます。 デスクトップでは良好でも、モバイルでは不良ということがあります。スマートフォンはCPUもネットワークも遅いため、通常はモバイルのほうが難関です。
2. 結果を左右するのは、遅い環境のユーザーです。 訪問者の4分の1が回線の弱い環境で古いAndroidスマートフォンを使っているなら、その体験があなたのスコアです。新しいノートPCとオフィスのWi-Fiでテストしても、ほとんど参考になりません。

INPは2024年にFIDに置き換わりました

Interaction to Next Paintは、2024年3月12日にFirst Input Delay(FID)に代わってCore Web Vitalsの指標になりました。FIDが測るのは、ブラウザが最初の操作の処理を始めるまでの遅延だけでした。INPは、訪問全体を通じたクリック、タップ、キー入力を対象とし、次のフレームが描画されるまでの全時間を測ります。FIDを楽々クリアしていたサイトの多くがINPで不合格になるのは、遅い部分が常に最初の入力以降の処理にあり、FIDはそれを数えていなかったからです。古いレポートやプラグインにFIDが表示されていても、無視してかまいません。

web.devはまた、安定版のCore Web Vitalsは「年に1回を超えて変更されない」こと、新しい候補指標は少なくとも6か月は保留段階にとどまることを述べています。そのため、ルールが変わる前に予告があります。

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

パフォーマンスデータには2種類あり、この2つを混同することが、チームが的外れな対策をしてしまう最も多い原因です。

Googleのドキュメントから、いくつかの詳細を紹介します。

• CrUXは28日間のローリング平均で、CrUX APIドキュメントによれば毎日更新されます。オリジン全体または単一のURLに対して照会でき、スマートフォン、デスクトップ、タブレットで絞り込めます。
• PageSpeed Insightsは両方を表示します。フィールドのセクションには直近28日間のCrUXデータが使われます。URLの訪問数が少なすぎる場合はオリジン全体のデータにフォールバックし、オリジンも小さすぎる場合はフィールドデータがまったく表示されません(About PageSpeed Insights)。ラボのセクションと0〜100のスコアはLighthouseによるものです。
• LighthouseはINPを測定できません。 web.devは、ユーザーのいないシミュレーション環境でページを読み込むツールではINPを測定できないと述べ、ラボでの代替指標としてTotal Blocking Time(TBT)を挙げています。
• Search ConsoleのCore Web Vitalsレポートは、似た体験のページをグループ化し、そのデバイス種別で最も遅い指標のステータスを各グループに付けます。使われるのは直近28日間のCrUXデータです(Core Web Vitalsレポートのヘルプ)。

実践的なルールは、フィールドデータで問題の有無を判断し、ラボデータで原因を探ることです。Lighthouseのスコアが98なのにフィールドのLCPが不良なら、実際のユーザーはシミュレーションより悪い体験をしているということです。原因は、低スペックの端末、広告、パーソナライズ、ラボテストでは動作しないサードパーティスクリプトなどであることが多いです。

Core Web Vitalsは検索順位にどれほど影響するか

Googleのページエクスペリエンスに関するドキュメントは、両面について明確に述べています。

• 「Core Web Vitalsはランキングシステムで使用されています」とあり、Googleは「検索での成功のために」良好なCore Web Vitalsを達成することを推奨しています。
• ページエクスペリエンスについて「単一のシグナルは存在しません」。コアランキングシステムはさまざまなシグナルを見ています。
• 「Google検索は、ページエクスペリエンスが劣っていても、常に最も関連性の高いコンテンツを表示しようとします」。
• Search Consoleやサードパーティのツールで良い結果が出ても、ページが上位に表示されることは保証されません。
• 「SEOだけを目的に完璧なスコアを目指すのは、時間の使い方として最善ではないかもしれません」。

私たちの解釈はこうです。Core Web Vitalsは、関連性の低いページを関連性の高いページより上に押し上げることはありませんが、品質が同程度のページ同士では差を生む可能性があり、ユーザーにとっては直接重要です。商品写真の表示に5秒かかるページや、「購入」ボタンが0.5秒固まるページは、順位に関係なく顧客を失います。3つすべてで「良好」を目指し、それ以上はスコアを追い求めず、コンテンツに戻りましょう。

ステップ1:どの指標がどこで不合格かを調べる

コードを変更する前に:

1. Search ConsoleのCore Web Vitalsレポートを、まずモバイルから開きます。どの指標が不合格か、どのURLグループが影響を受けているか(商品ページ、ブログ記事、トップページなど)を確認します。
2. 不合格のグループごとに代表的なURLを1つ選び、PageSpeed Insightsで実行します。フィールドデータがそのURLのものか、オリジンのものかを確認します。
3. 1回に1つのテンプレートを修正します。Core Web Vitalsの問題はほぼテンプレートの問題です。すべての商品ページが同じ画像コンポーネント、同じスクリプト、同じレイアウトを共有しているからです。

無料のCore Web Vitalsチェッカーなら、アカウントなしですぐに概要を把握できます。CrUXからスマートフォン訪問者の75パーセンタイルのLCP、INP、CLSを取得します(入力したページにChromeのデータが十分あればそのページ、なければオリジン全体)。さらに、そのページ(デフォルトではトップページ)のサーバー応答時間、HTMLサイズ、圧縮、head内のレンダリングブロックスクリプト、画像フォーマットも測定します。

ステップ2:LCPを4つのサブパートで改善する

LCPは、ビューポート内で最大の画像またはテキストブロックが描画されるまでの時間です。対象になる要素には、<img>、<video>、CSSのurl()背景画像を持つ要素、ブロックレベルのテキストが含まれます(web.devのLCP)。ほとんどの商品ページやランディングページでは、ヒーロー画像がこれに当たります。

Optimize LCPでは、LCPを合計で全体になる4つの要素に分けています。

web.devはこの割合を「厳密なルールではなくガイドライン」としていますが、診断には非常に役立ちます。Chrome DevToolsのPerformanceパネルでは、記録した読み込みの内訳を確認できます。割合が大きく上回っている部分から着手しましょう。

TTFBが高い場合

TTFBには、リダイレクト、接続の確立、サーバー処理が含まれます。web.devのTTFBガイドでは、おおよその目標として0.8秒以下を挙げています。ただし、TTFB自体はCore Web Vitalsではありません。

• HTMLをCDNから配信し、短時間でもエッジにキャッシュします。Core Web Vitalsを改善する最も効果的な方法では、TTFBを短縮する最良の方法としてCDNが挙げられています。
• 広告や短縮リンク経由のものを含め、リダイレクトの連鎖をなくします。
• (アナリティクスやキャンペーンによる)固有のURLパラメータが、すべてのリクエストをキャッシュミスにしていないか注意します。
• ページテンプレートの遅いデータベースクエリやサーバーサイドレンダリングをプロファイリングします。

リソースの読み込み遅延が大きい場合

これは最も大きなサブパートであることが多く、修正コストも通常は最も低く済みます。ブラウザは画像のダウンロードをもっと早く始められたのに、その存在を知らなかったという状態です。

• LCP画像は、通常の<img src>またはsrcsetとして最初のHTMLに入れます。JavaScriptで挿入された画像や、遅延読み込みライブラリ用のdata-srcを使った画像は、発見が遅れます。
• LCP画像は決して遅延読み込みしないでください。 ヒーロー画像からloading="lazy"を外します。web.devも「LCP画像を遅延読み込みしてはいけません」とはっきり述べています。
• LCP画像にfetchpriority="high"を付けます。付ける画像は1〜2枚までにします。
• 画像がCSSの背景である場合は、<link rel="preload">と高いフェッチ優先度でプリロードするか、<img>に切り替えます。
• 可能であれば、接続を再利用するために、重要な画像はHTMLと同じオリジンから配信します。

リソースの読み込み時間が長い場合

• srcsetとsizesを使い、表示サイズに合った画像を配信して、スマートフォンにデスクトップ用の画像をダウンロードさせないようにします。
• AVIFやWebPなどの最新フォーマットを使い、適切に圧縮します。
• 自動でリサイズや変換をしてくれる画像CDNを使います。
• 同時に帯域を奪い合っている、ほかの優先度の高いダウンロードを減らします。

要素のレンダリング遅延が大きい場合

画像は届いているのに、何かがブラウザによる描画を妨げています。

• レンダリングをブロックするCSS:量を減らし、重要でないスタイルは遅延させ、ごく小さなクリティカルCSSだけをインライン化します。
• <head>内の同期スクリプト:asyncまたはdeferを付けます。
• クライアントサイドレンダリング:JavaScriptフレームワークが動いて初めてコンテンツが表示されるなら、サーバーサイドレンダリングやプリレンダリングを検討します。
• どのバリアントを表示するか決まるまでページを隠すA/Bテストやパーソナライズのスクリプト。
• 画像の準備ができた瞬間に動いている、長いJavaScriptタスク。

LCPが画像ではなくテキストブロックの場合、リソースの読み込み遅延と読み込み時間はゼロになり、問題はTTFB、レンダリングをブロックするリソース、またはWebフォントにあります。

ステップ3:INPを3つのフェーズで改善する

INPは、訪問全体のクリック、タップ、キー入力(スクロールやホバーは対象外)を記録し、最も遅い操作を報告します。50回の操作ごとに1つの外れ値は除外されます(web.devのINP)。各操作には3つのフェーズがあります。

根本的な問題はほぼ必ずロングタスク、つまりメインスレッドで50ミリ秒を超えるタスクです。ロングタスクの実行中、ブラウザはユーザーに応答できません。

入力遅延を減らす

• 起動時に読み込むJavaScriptを減らします。スクリプトの評価は、ユーザーが最初にタップしようとするまさにそのタイミングでロングタスクを生みます。
• タグマネージャーを見直します。web.devでは「未使用のコードを含む古いタグは削除できる」とされています。チャットウィジェット、ヒートマップ、A/Bテスト、広告スクリプトは、メインスレッドで重い処理を実行していることがよくあります。
• ChromeのCoverageツールとコード分割で、ページが使わないコードの配信をやめます。

処理時間を減らす

• イベントハンドラでの処理を減らします。ユーザーがまず見る必要があるものを更新し、残り(アナリティクスの送信、状態の保存、レコメンドの再計算)は後回しにします。
• 処理の区切りごとにメインスレッドへ処理を譲ります。await scheduler.yield()は、残りの処理を優先度付きの新しいタスクで続行します。すべてのブラウザが対応しているわけではないため、web.devはPromiseで包んだsetTimeoutへのフォールバックを提案しています(Optimize long tasks)。
• レイアウトスラッシングを避けます。同じタスク内でスタイルを変更した直後にoffsetHeightなどのレイアウト値を読むと、ブラウザは同期的にレイアウトを計算せざるを得なくなります。読み取りと書き込みはまとめて行いましょう。

プレゼンテーション遅延を減らす

• DOMを小さく保ちます。Optimize INPでは、レンダリング処理がDOMのサイズに応じて増えると説明されています。
• content-visibilityを使い、長いレビューやフッターなど画面外のセクションのレンダリングを省きます。
• クリックに応じて、大量のHTMLをJavaScriptでレンダリングするのは避け、必要な分だけレンダリングします。

遅い操作を見つけるには、まず実ユーザーのデータ(どのページが不合格か)を確認し、そのうえでChrome DevToolsで再現します。CPUをスロットリングした状態で、怪しい要素をクリックしながらPerformanceトレースを記録し、クリック後のロングタスクを探します。

ステップ4:CLSを原因別に改善する

CLSは、予期しないレイアウトシフトを合算したものです。各シフトのスコアは、ビューポートのうち動いた割合に移動距離を掛けて求められ、シフトは最大5秒のウィンドウにまとめられ、CLSは最も悪いウィンドウの値になります(web.devのCLS)。クリック、タップ、キー入力から500ミリ秒以内のシフトは、ユーザーが予期していたものなので除外されます。スクロールは入力に含まれないため、スクロール中にコンテンツがずれた場合はカウントされます。

Optimize CLSによると、主な原因と対処法は次のとおりです。

経験から言える注意点が2つあります。

• スペースが縮むときもシフトは起きます。 web.devは、確保したスペースを取り除くと「コンテンツを挿入するのと同じくらいCLSが発生することがある」と警告しています。広告枠が空のままでも、プレースホルダーは残しましょう。
• Cookieバナーやプロモバーはよくある原因です。 ページを押し下げるのではなく、コンテンツの上に重ねて表示します。

back/forwardキャッシュを忘れずに

ユーザーが「戻る」を押したとき、bfcacheから復元されたページは、新たな読み込み時のシフトなしで即座に表示されます。web.devは、bfcacheの対象にすることがCLSを低く保つ非常に効果的な手法だと述べています。web.devのbfcacheガイドによると、最も多い阻害要因は2つで、unloadイベントリスナー(代わりにpagehideを使う)と、機密情報を含まないページに付けたCache-Control: no-storeヘッダーです。Chrome DevToolsには、Application › Back/forward cacheにテスト機能があります。

具体例(架空の数値)

以下は架空の例であり、実データではありません。架空のオンライン家具店Fernwood Homeは、商品ページテンプレートのモバイルでのCore Web Vitals評価が不合格です。75パーセンタイルのフィールド値は次のとおりです。

LCP:4.6秒

スロットリングしたスマートフォンのプロファイルでDevToolsのトレースを取ると、LCP要素はメインの商品写真でした。内訳は次のとおりです。

リソースの読み込み遅延は目安の割合の3倍以上なので、最初に対処します。対策は次のとおりです。最初の写真をサーバー側のHTMLで通常の<img>としてレンダリングし、そこからloading="lazy"を外してfetchpriority="high"を追加します。srcsetでスマートフォン向けサイズのAVIFとWebPを配信し、キャッシュキーでトラッキングパラメータを無視する形でCDNにHTMLをキャッシュし、A/Bスクリプトはdeferで読み込みます。

リリース後のラボ結果は、TTFB 0.7秒、読み込み遅延 0.2秒、読み込み時間 0.6秒、レンダリング遅延 0.3秒で、LCPは1.8秒になりました。

INP:340ミリ秒

フィールドデータは商品ページを示しています。DevToolsで再現すると、遅い操作は「カートに追加」ボタンでした。トレースでは、入力遅延が約90ミリ秒(チャットウィジェットと2つのトラッキングタグが同時に動作)、処理時間が190ミリ秒(ハンドラがカートのドロワー全体を再レンダリングし、3つのアナリティクス呼び出しを同期的に送信)、プレゼンテーション遅延が60ミリ秒でした。

対策は、チャットウィジェットを最初のユーザー操作の後にだけ読み込み、カートのドロワーの更新を先に表示し、そのあとアナリティクスとレコメンドの更新の前に処理を譲ることです。同じスロットリングしたプロファイルでのラボ計測は、約150ミリ秒でした。

CLS:0.21

原因は3つです。読み込み後に価格の上へ挿入されるレビュー星ウィジェット、商品タイトルの折り返しを変えるWebフォントの差し替え、サイズ指定のないサムネイル画像です。対策として、レビューウィジェットの高さを確保し、タイトル用フォントをプリロードしてsize-adjustでフォールバックを調整し、すべてのサムネイルにwidthとheightを追加します。ラボでのCLSは0.04でした。

結果の読み方

ラボの数値は、修正が効いていることを裏付けます。評価を決めるフィールドの数値は、28日間のウィンドウで古い訪問が新しい訪問に置き換わるにつれて動きます。Fernwoodは約4週間かけて徐々に変化すると見込み、そのあとSearch Consoleのレポートで「トラッキングを開始」をクリックして検証を始めます。この検証も28日間続きます。フィールドのLCPが1.8秒ではなく、たとえば2.3秒に落ち着いたとしても、それは普通のことです。実際のスマートフォンやネットワークは、どのラボのプロファイルよりも遅いからです。

よくある間違い

• Lighthouseのスコアを追いかける。 0〜100のスコアはラボの要約です。Googleの評価は、75パーセンタイルのフィールドデータを使います。
• デスクトップだけでテストする。 モバイルは別に評価され、通常はこちらが先に不合格になります。
• 何でも遅延読み込みする。 ファーストビューより下の画像を遅延読み込みするのは良いことですが、ヒーロー画像の遅延読み込みは、LCPが悪化する最も多い原因の1つです。
• トップページだけを直す。 トラフィックの多くは、商品、カテゴリ、記事のテンプレートに着地していることがよくあります。不合格のURLが最も多いテンプレートから直しましょう。
• スクリプトをもう1つ追加する。 すべてのタグ、ウィジェット、テストスクリプトがメインスレッドを奪い合います。1つ追加するなら、1つ削除しましょう。
• すぐに結果が出ると期待する。 フィールドデータにリリースが完全に反映されるには、約28日かかります。
• モバイルの基本を無視する。 ビューポートタグがないページや、サイズが大きすぎる画像を使っているページは、最適化以前にスマートフォンで遅くなります。無料のモバイルフレンドリーテストで、これらの基本を確認できます。

1時間で始めるチェックリスト

1. ドメインを無料のCore Web Vitalsチェッカーにかけ、スマートフォンでの実ユーザーのLCP、INP、CLSに加えて、サーバー応答時間、圧縮、ブロックスクリプトを確認します。
2. Search ConsoleのCore Web Vitalsレポートをモバイルで開き、不合格のURLグループを一覧にします。
3. 不合格のグループごとに1つのURLをPageSpeed Insightsにかけ、フィールドでどの指標が不合格かを記録します。
4. LCPについては、DevToolsのトレースを記録し、4つのサブパートを書き出します。最も大きいものから直します。
5. INPについては、遅い操作と、その後のロングタスクを見つけます。
6. CLSについては、サイズ指定のない画像、後から挿入されるコンテンツ、フォントを確認します。
7. 公開し、ラボで確認し、2週間後と4週間後にフィールドデータを確認します。

Core Web Vitalsは、テクニカルな健全性の一部にすぎません。テクニカルSEO監査ガイドでは、クローリング、インデックス、リダイレクト、構造化データとの関連の中でCore Web Vitalsを位置づけています。

SearviaでCore Web Vitalsに取り組む

無料のCore Web Vitalsチェッカーは、アカウント不要で、1分以内にサイトの実ユーザーの状況を把握できます。Searvia内では、ウェブサイトプロジェクトのPage speedタブが、アクセスの多いページに対して毎週PageSpeed Insightsを実行し、ラボスコアと、直近28日間のLCP、INP、CLSの実際のChromeユーザーデータの両方を表示します。修正は節約できる時間の順に並び、Write a fix plan for my files with AIを使えば、上位の項目をお使いのスタックに合わせた手順ごとの変更に落とし込めます(3クレジット)。Search Consoleを連携すれば、クリック数や掲載順位を速度の隣に表示でき、速くなったテンプレートが実際にトラフィックを増やしたかどうかを判断できます。ページ速度のヘルプガイドでは、約2分でできるセットアップを解説しています。