ECサイトのCore Web Vitals改善｜LCP・INP・CLSの見方と対策
目次
Core Web Vitalsは、実際の利用者体験を読み込み速度、操作への反応、表示の安定性から捉える指標です。現在の主要指標はLCP、INP、CLSで、ECサイトでは大きな商品画像、レビュー機能、レコメンド、広告などが影響しやすくなります。
数値を良くすることだけが目的ではありません。商品を早く確認でき、ボタンがすぐ反応し、読み込み途中で画面がずれない状態を作ります。Core Web Vitalsだけで順位が決まるわけではないため、内容や購入導線と合わせて改善します。
LCPとは
LCPは、画面内の主要な大きいコンテンツが表示されるまでの時間を測ります。商品ページではメイン画像や商品名周辺、カテゴリでは大きなバナーや一覧画像が対象になることがあります。
一般的な良好の目安は2.5秒以内です。ただし、計測環境やページ群によって結果は異なります。どの要素がLCPとして判定されているかを確認してから対策します。
LCPの改善方法
メイン商品画像を適切なサイズと形式で配信し、ファーストビューの画像を不要に遅延読み込みしないようにします。CDN、キャッシュ、サーバー応答、CSSやフォントの読み込みも確認します。
巨大なヒーローバナーを全商品へ置くと、商品情報より先に重い要素を読み込むことがあります。売り場として必要かを検討し、画像圧縮と表示寸法をそろえます。
INPとは
INPは、クリックやタップ、キーボード操作に対して、画面が次の表示を行うまでの反応性を測ります。一般的な良好の目安は200ミリ秒未満です。
ECサイトでは、バリエーション選択、数量変更、カート追加、絞り込み、メニュー開閉が重要な操作です。見た目だけ速くても、操作が固まると商品選びを妨げます。
INPの改善方法
長時間メインスレッドを占有するJavaScriptを分割し、利用しないスクリプトを減らします。タグ管理、チャット、レビュー、レコメンドなど第三者スクリプトが同時に動く場合は、事業上の必要性と読み込み順を見直します。
操作直後にすべての処理を終えるのではなく、まず選択状態や待機表示を更新し、重い処理を分ける方法もあります。実装後は実際の端末で主要操作を試します。
CLSとは
CLSは、利用者が操作していないのに画面要素がどれだけ移動したかを測ります。一般的な良好の目安は0.1未満です。商品画像やバナーが後から入り、購入ボタンの位置がずれると数値が悪化します。
価格や在庫メッセージ、レビュー、レコメンドなど、非同期で追加される要素も原因になります。誤タップにつながる表示ずれは、利用者体験の問題として優先します。
CLSの改善方法
画像と動画に幅と高さ、またはアスペクト比を指定し、読み込み前から領域を確保します。広告やおすすめ枠にも想定サイズを用意します。
ページ上部へ後から告知バーを差し込む実装は避け、最初から領域を確保します。フォント切り替えによる文字幅の変化も確認します。
実データとテストデータの違い
Search ConsoleのCore Web Vitalsレポートは、実際の利用データをもとに、似たURL群で問題を示します。一方、PageSpeed InsightsやLighthouseのラボデータは、特定条件で原因を調べるために役立ちます。
実データで問題を見つけ、ラボデータで原因を切り分け、公開後に実データの変化を待つという流れで使います。一回の測定値だけで完了を判断しません。
ページ種類ごとに調べる
トップ、カテゴリ、商品、記事、カートではテンプレートと機能が異なります。各種類からアクセスの多いURLと問題のあるURLを選び、共通要因を調べます。
商品ページでだけ遅いなら、画像ギャラリーやレビューが原因かもしれません。カテゴリだけなら、商品カード数、絞り込み、無限スクロールを確認します。
改善の優先順位
利用者が多いページ群、購入に直結する操作、テンプレート全体に効く変更を優先します。数値の小さな差より、画像が見えない、ボタンが反応しない、誤タップが起きる問題を先に直します。
速度対策で商品画像の品質や必要な説明を落としすぎないようにします。軽量化と情報量の両方を保てる配信方法を検討します。
よくある間違い
- 一回のLighthouse結果だけで判断する
- Core Web Vitalsだけで順位が決まると考える
- ファーストビュー画像まで遅延読み込みする
- 第三者スクリプトを追加し続ける
- パソコンだけで確認する
確認項目
- LCP要素が何か特定したか
- カート追加や絞り込みの反応を測ったか
- 画像や広告の領域を確保しているか
- 実データとラボデータを使い分けたか
- ページ種類ごとに問題を分けたか
- 改善前後の変更内容を記録したか
商品画像の改善を設計する
商品画像は購入判断に重要なため、単純に低画質へするのではなく、表示寸法に合う複数サイズを用意します。端末の画面幅や解像度に応じて適切な画像を配信し、圧縮形式と品質を比較します。
ファーストビューのメイン画像は優先し、一覧の画面外画像は遅延読み込みを検討します。画像URLとキャッシュを安定させ、同じ画像を画面部品ごとに何度も取得しないようにします。
第三者スクリプトを棚卸しする
アクセス解析、広告、チャット、レビュー、ヒートマップ、レコメンドはそれぞれ目的がありますが、追加され続けるとJavaScript処理とネットワーク通信が増えます。スクリプト名、担当部署、利用目的、読み込みページ、更新日を一覧にします。
全ページで必要か、商品ページだけでよいか、同じ機能が重複していないかを確認します。停止テストで事業への影響を見たうえで、削除、遅延読み込み、同意後の読み込みを検討します。
数値が改善しないときの切り分け
コードを公開しても実データへ反映されるまで時間がかかります。まず本番ページで変更が配信されているか、キャッシュに旧ファイルが残っていないかを確認します。
次に、問題URL群と改善対象が一致するかを見ます。商品テンプレートを直しても、Search Consoleのグループにカテゴリが混ざっている場合があります。端末、国、回線、ログイン状態による差も調べます。
継続的な性能予算を持つ
一度高速化しても、新しいバナーやタグ、レビュー機能で再び遅くなります。画像容量、JavaScript量、主要操作時間など、リリース時に確認する基準を決めます。
基準を超えたら公開を止めるだけでなく、どの機能を軽くするかを関係部署で判断します。売上に必要な機能と利用されていない装飾を同じ扱いにせず、体験と事業価値を比較します。
ECサイトでの改善例
商品ページのLCPがメイン画像なら、元画像をそのまま縮小表示していないかを確認します。表示幅に合わせた画像、圧縮、CDN、優先読み込みを組み合わせ、ズーム用の高解像度画像は操作後に読み込む方法があります。
絞り込み時のINPが悪いなら、選択するたびに全商品と全件数を同期計算していないかを調べます。操作状態を先に表示し、重い処理を分割する、サーバー応答をキャッシュするなど、利用者が待っていることを理解できる設計にします。
レビュー枠でCLSが起きる場合は、レビュー件数取得前から領域を確保します。レビューがない商品でも高さが大きく空くなら、ページ種別や状態に応じた最小領域を設計します。
改善時に守るべき商品体験
画像枚数やレビューを減らせばページは軽くなりますが、購入判断に必要な情報まで失うと本末転倒です。主要画像は画質と速度を両立し、追加画像や動画は表示位置と読み込み順を工夫します。
速度改善の前後で、商品詳細への到達、バリエーション選択、カート追加が正常に動くかを確認します。性能指標と購入行動を同じ変更記録に残すと、軽量化の影響を判断しやすくなります。
まとめ
Core Web Vitalsは、LCPで読み込み、INPで操作への反応、CLSで表示の安定性を測ります。ECサイトでは商品画像、JavaScript、後から入る部品が主な確認対象です。
Search Consoleで問題のあるURL群を見つけ、ラボツールで原因を調べ、主要な購入操作を実機で確認してください。数値と商品選びのしやすさを同時に改善することが大切です。
