ECサイトのCore Web Vitals：LCP・INP・CLS解説

LCP・INP・CLSが測る内容、75パーセンタイルでの「良好」「不良」の基準、ラボデータとフィールドデータの違い、ShopifyとWooCommerceでのよくある改善策を解説します。

FixReports 編集部3分で読めます

Core Web Vitals（コアウェブバイタル）は、実際の訪問者がページをどう体験しているかを表すGoogleの3つの指標です。読み込みを表すLargest Contentful Paint（LCP）、応答性を表すInteraction to Next Paint（INP）、視覚的な安定性を表すCumulative Layout Shift（CLS）で構成されます。訪問の75%以上が「良好」の範囲に入っていれば合格で、その範囲はLCPが2.5秒以内、INPが200ミリ秒以内、CLSが0.1以下です。評価はモバイルとデスクトップで別々に行われます。ECサイトでスコアが不合格になる原因は、たいてい、サイズが大きすぎる、または遅延読み込みされたメインビジュアルや商品画像、アプリやトラッキングのスクリプト、ウェブフォント、そしてページの表示後にコンテンツを押し下げるバナーやレビューウィジェットにあります。

要点

Core Web Vitalsの基準値はいくつですか？

3つの指標すべてで、ページ読み込みの75パーセンタイルが「良好」の範囲に入っていれば、そのページはCore Web Vitalsを満たしています。

指標測定する内容良好改善が必要不良
LCPビューポート内で最も大きな画像、動画、テキストブロックが描画されるまでの時間2.5秒以下2.5秒超、4.0秒以下4.0秒超
INPクリック、タップ、キー入力から次のフレームが描画されるまでの時間200 ms以下200 ms超、500 ms以下500 ms超
CLS表示中のコンテンツが予期せず動く量0.1以下0.1超、0.25以下0.25超

基準値は、2026年10月時点のweb.devのLCP （新しいタブで開きます）、INP （新しいタブで開きます）、CLS （新しいタブで開きます）の各ガイドに基づいています。

75パーセンタイルで判定するということは、最も速い訪問者だけでなく大多数の訪問者を反映した結果になるということです。またGoogleはモバイルとデスクトップを分けて評価します （新しいタブで開きます）。PageSpeed Insightsは、3つの指標すべてが「良好」の場合にページを合格とし、INPのデータが十分でない場合はLCPとCLSだけで判定します（PageSpeed Insightsのドキュメント （新しいタブで開きます））。Googleは、安定版のCore Web Vitalsを変更するのは年に1回までとしています。

ストアでは、LCP要素はメインビジュアルのバナーやメインの商品画像であることが多く、だからこそ画像の扱いが非常に重要になります。

2024年3月にINPがFIDに置き換わったのはなぜですか？

FIDが最初の操作と、その遅延の一部しか測定していなかったのに対し、INPは訪問全体を通じた操作を対象とするためです。

Googleは2023年5月にINPをCore Web Vitalsに加えると発表し、2024年3月12日 （新しいタブで開きます）に切り替えが行われました。FIDが報告していたのは最初の操作の入力遅延だけで、イベントハンドラーの実行や結果の描画にかかる時間は含まれていませんでした。INPは訪問全体のクリック、タップ、キー入力を観測し、外れ値を除いて最も長いものを報告します。スクロールやホバーは対象外です。CrUX APIとPageSpeed Insights APIの利用者には、2024年9月9日まで移行の猶予がありました（web.dev （新しいタブで開きます））。

各操作は3つの部分から成ります。入力遅延（処理中のスクリプトを待つ時間）、処理時間（ハンドラーの実行）、表示遅延（次のフレームの描画）です（web.dev （新しいタブで開きます））。

ストアでこうした操作にあたるのは、バリエーション選択、数量ボタン、カートに追加、カートドロワー、フィルター、メニューです。最初の素早いタップではFIDに合格していても、あとでフィルターを開いたときには遅く感じる、ということも起こり得ました。

ラボデータとフィールドデータの違いは何ですか？

ラボデータは固定条件下での1回のテストから得られるのに対し、フィールドデータは実際の訪問者から継続的に収集されます。Googleは、何から修正するかを決める際にはフィールドデータを使うよう推奨しています（web.dev （新しいタブで開きます））。

ラボデータフィールドデータ
取得元シミュレーションによる1回のページ読み込み（Lighthouse、Chrome DevTools、PageSpeed Insightsのラボデータ欄）実際のChromeユーザー（Chrome UX Report）、または自社のリアルユーザーモニタリング
条件デバイスとネットワークは固定。Lighthouseのモバイルテストの既定値 （新しいタブで開きます）は「Slow 4G」（往復150 ms、下り1.6 Mbps）と4倍のCPU低速化訪問者が使っているあらゆるデバイス、ネットワーク、地域
INP通常のページ読み込みでは測定されない。Total Blocking Time（TBT）がおおよその代わりになる実際の操作から測定
適した用途デバッグや、リリース前の変更の確認訪問者が実際にどんな体験をしているかの把握

TBTは、メインスレッドの各タスクのうち50 msを超えた部分を合計したものです。web.devは、平均的なモバイル端末で200 ms未満を目安としつつ、INPの代わりにはならないとしています（web.dev （新しいタブで開きます））。

Chrome UX Report（CrUX）には、ストアにとって重要な点が3つあります。

  • 28日間の移動平均 （新しいタブで開きます）で、毎日更新されます。
  • Chromeのレポート条件を満たすユーザーの、デスクトップ版とAndroid版のChromeが対象です。iOS版Chromeは除外されるため、iPhoneの買い物客が大半を占めるストアでは、フィールドデータが利用者の一部しか反映しません（手法の説明 （新しいタブで開きます））。
  • ページやオリジンは、一般に発見可能で十分な人気がある場合にのみ掲載されます。そのため、アクセスの少ないストアにはオリジン単位のデータしかないか、データがまったくないことがあります。

Shopifyのウェブパフォーマンスダッシュボード （新しいタブで開きます）も、実際のユーザーのLCP、INP、CLSを75パーセンタイルで報告しますが、集計期間は28日ではなく30日です。CrUXとは多少の差が出るものと考えておきましょう。

ストアのページでLCPを遅くしているものは何ですか？

ストアでLCPが遅い原因の多くは、メイン画像が重すぎる、見つかるのが遅い、あるいは遅延読み込みやアニメーションによって意図的に遅らされていることです。

  • LCP画像の遅延読み込み。 web.devは、これは決して行わないようにと述べています（web.dev （新しいタブで開きます））。WordPressのページを分析したところ、ネイティブの遅延読み込みを使うサイトでは75パーセンタイルのLCPが遅くなっており、ファーストビューの画像を遅延読み込みしないことでこの悪化は解消されました（web.dev （新しいタブで開きます））。
  • 見つかるのが遅い画像。 CSSのbackground-imageで設定されたメインビジュアルや、スライダーのスクリプトで挿入されたメインビジュアルは、ブラウザが最初に解析するHTMLには含まれていません。Shopifyは、メインビジュアルのコンテンツにCSSの背景を使うことや、LCP画像にフェードイン効果をかけることを避けるよう勧めています（Shopify （新しいタブで開きます））。
  • 低い優先度。 画像はレイアウトが完了するまで低い優先度で読み込まれるため、ShopifyはLCP画像にfetchpriority="high"を指定するよう推奨しています（Shopify （新しいタブで開きます））。web.devは、1～2枚を超える画像に指定すると効果が薄れると指摘しています（web.dev （新しいタブで開きます））。
  • レンダリングを妨げるCSSとスクリプト。 <head>内の大きなスタイルシートや同期スクリプトは、画像が届いたあとでも描画を遅らせます（web.dev （新しいタブで開きます））。
  • ファイルサイズとフォント。 最新の画像形式、srcsetとsizes、CDNを使いましょう。ウェブフォントには、autoとblock以外のfont-displayの値を指定します。
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

ストアのページでINPを遅くしているものは何ですか？

ストアでINPが遅いのは、たいていメインスレッド上のJavaScriptが多すぎるためです。その多くはアプリ、トラッキングタグ、テーマの機能に由来し、その結果タップが待たされます。

レビュー、チャット、アナリティクスのスクリプトが実行中のときに買い物客が「カートに追加」をタップすると、そのタップは待たされます。商品フォーム全体を再描画するバリエーション選択は、処理時間を増やします。巨大なメガメニューや、カラースウォッチの多いコレクショングリッドは、表示遅延を増やします。

web.devは、長いタスクを分割してメインスレッドに処理を譲ること、まず画面を更新して残りは後回しにすること、DOMを小さく保つことを推奨しています（web.dev （新しいタブで開きます））。Shopifyはストア向けの手順として、すべてのアプリ、ピクセル、テーマのスクリプトを点検すること、重要でないものは読み込みを遅らせること、機能は操作されたときに読み込むこと、A/Bテストを実施していないときはちらつき防止スニペットを無効にすることを挙げています（Shopify （新しいタブで開きます））。

商品ページやコレクションページでレイアウトのずれが起きる原因は何ですか？

ストアでのレイアウトのずれは、主に最初の描画のあとに表示されたり、サイズが変わったりするコンテンツから生じます。サイズ指定のない画像、お知らせバーやCookieバー、レビューウィジェット、アプリブロック、フォントの切り替えなどです。

web.devは、よくある原因として、サイズが不明なメディア、既存のコンテンツの上に追加されるコンテンツ、自らサイズを変えるサードパーティのウィジェット、代替フォントとサイズが異なるウェブフォントを挙げています（web.dev （新しいタブで開きます））。ストアでいえば、上部に挿入される送料無料バー、商品名のあとに読み込まれる星評価、価格の下に表示される分割払いの案内、おすすめ商品のカルーセルなどです。Shopifyは、ポップアップのコンテンツもずれの原因になり得ると指摘しています（Shopify （新しいタブで開きます））。

ユーザーの入力から500 ms以内に起きたずれは数えられませんが、スクロール中のずれは数えられ、ラボツールではそれを見逃すことがよくあります（web.dev （新しいタブで開きます））。画像にはwidthとheight、またはCSSのaspect-ratioを指定し、ウィジェットのためのスペースを確保し、バナーはオーバーレイとして表示し、size-adjustでフォントの切り替えによるずれを減らし、アニメーションにはtopやleftではなくtransformを使いましょう。

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

ShopifyでCore Web Vitalsを改善するにはどうすればよいですか？

Shopifyでは、効果の大半は、最初の画像を高い優先度で即時に読み込むこと、アプリのスクリプトを減らすこと、そして管理画面のウェブパフォーマンスレポートで結果を確認することから得られます。

管理画面でデータを確認する

概要は オンラインストア > テーマ（Online Store > Themes）のページに表示され、LCP、INP、CLSの詳細なレポートは ストア分析 > レポート（Analytics > Reports）にあります。データの反映は最大36時間遅れることがあり、プライベートモードをオフにしておく必要があります（Shopifyヘルプセンター （新しいタブで開きます））。

Liquidで画像の読み込みを制御する

image_tagフィルターは、preloadを設定しない限り、ページ下部のセクションでは画像を遅延読み込みします（image_tagリファレンス （新しいタブで開きます））。セクション1～3では即時読み込み、セクション4以降では遅延読み込みです。テーマエディターではsection.indexがnilになるため、<= 3ではなく> 3で判定します。

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

商品グリッドでは、Shopifyは最初の数枚のカードだけを即時読み込みにするよう提案しています（例：forloop.index <= 4、Shopify （新しいタブで開きます））。preload: trueは控えめに使いましょう。Shopifyは、見つかるのが遅いリソース1～2個だけをプリロードするよう推奨しています。

アプリが残したものを削除する

使っていないアプリ埋め込みは、オンラインストア > テーマを編集 > アプリ埋め込み（Online Store > Edit theme > App embeds）でオフにします（Shopifyヘルプセンター （新しいタブで開きます））。アプリをアンインストールするとそのアプリブロックは削除されますが、テーマファイルを直接編集したアプリは「ゴーストコード」を残すことがあり、Shopifyはこれが品質やパフォーマンスの問題を引き起こす可能性があるとしています（Shopify （新しいタブで開きます））。Shopifyはまた、スクリプトタグは2027年3月1日に動作しなくなるとしています。フォントについては、外部のフォントサービスよりも、Shopify自身のCDNかシステムフォントを使うよう推奨しています（Shopify （新しいタブで開きます））。

WooCommerceでCore Web Vitalsを改善するにはどうすればよいですか？

WooCommerceでは、プラグインがWordPressによる画像の優先度付けを上書きしていないことを確認し、カートとチェックアウト以外のすべてをキャッシュし、必要もないのにあらゆるページで読み込まれるスクリプトを削除します。

  • コアの画像処理を活かす。 WordPress 6.3（2023年8月8日リリース）以降、コアはLCPになりそうな画像（既定では50,000平方ピクセル以上）にfetchpriority="high"を付与し、最初の3つのコンテンツ画像では遅延読み込みを行いません（Make WordPress Core （新しいタブで開きます））。最適化プラグインが独自の遅延読み込みを追加する場合は、メインビジュアルとメインの商品画像が対象から除外されているか確認してください。
  • キャッシュするのはページで、カートではない。 WooCommerceのガイドは、サーバーまたはプラグインによるページキャッシュとCDNを推奨する一方、カートとチェックアウトのページはキャッシュしないよう勧めています（WooCommerce開発者向けドキュメント （新しいタブで開きます））。
  • カートフラグメントを確認する。 WooCommerce 7.8以降、カートフラグメントのスクリプトはCartウィジェットがあるページでのみ読み込まれますが、このウィジェットをハードコードしているテーマもあります。Mini-Cartブロックはカートフラグメントを使いません（WooCommerce開発者ブログ （新しいタブで開きます））。
  • 重いプラグインを見つける。 WooCommerceは、遅いプラグインを見つけるためにQuery Monitorを使うこと、そして重要でないJavaScriptの読み込みを遅らせることを提案しています。

ファーストビューに4枚以上の画像を表示するレイアウトの場合は、WordPressのしきい値を引き上げることができます。

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

修正の効果が表れるまでにどれくらいかかりますか？

ラボテストでは修正の効果がすぐにわかりますが、CrUXは直近28日間を平均するため、フィールドデータに完全に反映されるまでには最大で約4週間かかります。

1回ごとの結果にはばらつきがあるため、変更の前後でラボテストを何度か実行し、そのうえでPageSpeed Insights、Search ConsoleのCore Web Vitalsレポート、またはShopifyのレポートでフィールドの数値を追いましょう。無料スキャンなら、約1分で最初の結果がわかります。表示速度改善レポートは、速度制限をかけたモバイルのラボテスト（低速4G、4倍のCPU低速化）を実行し、Chrome UX Reportのフィールドデータを加えます。Googleにストアの十分なデータがあれば、INPも含まれます。

よくある質問

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

Googleは、Core Web Vitalsがランキングシステムで使用されていると述べています。ただし、スコアが良くても上位表示が保証されるわけではなく、ページエクスペリエンスが悪くても最も関連性の高いコンテンツを表示するとしています（Google検索セントラル （新しいタブで開きます））。

PageSpeed Insightsでストアのフィールドデータが表示されないのはなぜですか？

CrUXに含まれるのは、一般に発見可能で、対象となるChromeの訪問者が十分にいるページとオリジンだけです。アクセスの少ないストアでは、オリジン単位のデータしかないか、データがまったくないことがあるため、ラボテストとプラットフォーム独自のレポートを頼りにしてください。

合格するにはLighthouseのスコアが90以上必要ですか？

いいえ。Lighthouseのパフォーマンススコアはラボでの結果であるのに対し、Core Web Vitalsの評価は75パーセンタイルのフィールドデータを使います。そのため、Lighthouseのスコアがそれほど高くなくても合格することもあれば、高くても不合格になることもあります。

商品画像はすべて遅延読み込みにすべきですか？

いいえ。最初の画面より下の画像は遅延読み込みにし、メインビジュアルとメインの商品画像は即時に読み込んで、そのうち1枚にfetchpriority="high"を指定します。

モバイルの結果がデスクトップより悪いのはなぜですか？

Googleはモバイルとデスクトップを別々に測定しており、スマートフォンはプロセッサもネットワークも遅いためです。Lighthouseのモバイルテストは、Slow 4GのプロファイルとCPUの4倍低速化によってその状況を再現しています。

出典

すべてのガイド