コア Web Vitals の最適化: e コマース サイトの LCP、FID、CLS

Google の調査によると、優れた Core Web Vitals を備えたサイトでは離脱率が 24% 低くなります。 コンバージョン率のすべてのパーセンテージ ポイントが収益につながる e コマースにとって、Web パフォーマンスは技術的にあると便利なものではなく、ビジネスの乗数です。 Core Web Vitals は Google のランキング要素としても確認されており、スコアが低いと、まさに潜在顧客が購入を検討しているときに、商品ページが検索結果で押し下げられることを意味します。

重要なポイント

• 2.5 秒未満で最大のコンテンツフル ペイント (LCP) を実現するには、サーバーの応答時間と重要なリソースの読み込みの両方を最適化する必要があります
• 200ms 未満の Next Paint (INP) へのインタラクションは、長い JavaScript タスクを中断し、クリティカルでない実行を延期することを意味します
• 0.1 未満の累積レイアウト シフト (CLS) では、すべての画像、埋め込み、および動的に挿入されるコンテンツの明示的なサイズが必要です
• e コマース サイトは、重い商品画像、サードパーティのスクリプト (分析、チャット、広告)、および動的価格設定要素など、CWV 特有の課題に直面しています。

---

コア Web バイタルを理解する

Core Web Vitals は、Google がランキング シグナルとして使用する 3 つのユーザー中心のパフォーマンス指標です。ユーザーが最も注目するページ エクスペリエンスの 3 つの側面である、読み込み速度、インタラクティブ性、視覚的な安定性を測定します。

注: FID (最初の入力遅延) は、公式の応答性指標として 2024 年 3 月に INP (Interaction to Next Paint) に置き換えられました。 INP は、最初のインタラクションだけでなく、ページのライフサイクル全体にわたるすべてのインタラクションを測定します。

eコマースサイトが苦戦している理由

e コマース サイトは、コンテンツ サイトにはない、次のような特有のパフォーマンスの課題に直面しています。

• 重い製品画像 -- 高解像度の製品写真は変換には重要ですが、読み込みに時間がかかります
• サードパーティ スクリプト -- 分析 (Google Analytics、Meta Pixel)、チャット ウィジェット (Intercom、Zendesk)、パーソナライゼーション エンジン、および A/B テスト ツールはすべて、メイン スレッド時間をめぐって競合します。
• 動的コンテンツ -- 価格変更、株価指標、プロモーション バナー、パーソナライズされた推奨事項により、レイアウトとブロック レンダリングが変更されます。
• 複雑なチェックアウト フロー -- 支払い処理スクリプト、住所検証、不正検出により JavaScript の重要性が高まります

---

最大コンテンツフル ペイント (LCP) の最適化

LCP は、最大の表示要素がレンダリングを終了する時間を測定します。製品ページの場合、これは通常、ヒーロー製品画像です。カテゴリ ページの場合は、最初の製品カードの画像やプロモーション バナーなどが考えられます。

サーバー応答時間 (TTFB)

LCP はサーバーの応答時間よりも速くすることはできません。最初のバイトまでの時間 (TTFB) は、ブラウザが HTML の最初のバイトを待つ時間を測定します。 TTFB は 600 ミリ秒未満、理想的には 200 ミリ秒未満を目標にします。

最適化手法:

• サーバーサイド レンダリング (SSR) -- JavaScript の入力を必要とする空のシェルを送信する代わりに、サーバー上で HTML をレンダリングします。 React Server コンポーネントを備えた Next.js App Router は、デフォルトでこれを提供します。
• エッジ コンピューティング -- Vercel Edge Functions や Cloudflare Workers などのプラットフォームを使用して、サーバー側のレンダリングをユーザーに近いエッジの場所に展開します。
• データベースの最適化 -- 製品ページでのデータベース クエリが遅いと、TTFB が直接増加します。 データベース クエリの最適化 に関するガイドを参照してください。
• キャッシュ -- 匿名ユーザーのためにレンダリングされたページをキャッシュします。 CDN キャッシュされた商品ページは、オリジンから 200 ミリ秒で提供されるのに対し、20 ミリ秒で提供されます。 キャッシュ戦略 を参照してください。

重要なリソースの読み込み

HTML が到着したら、LCP 要素をレンダリングする前に、ブラウザーは CSS、フォント、および画像をロードする必要があります。

LCP の画像の最適化:

• LCP 画像に対して <img> を fetchpriority="high" とともに使用して、ブラウザに優先順位を付けるように指示します
• 最新の形式を使用します: WebP (JPEG より 30% 小さい) または AVIF (JPEG より 50% 小さい)
• 400 ピクセルのモバイル画面に 2000 ピクセルの画像が読み込まれるのを避けるために、srcset と sizes を使用して応答性の高い画像を提供します
• <link rel="preload" as="image"> を使用して、ドキュメント <head> 内の LCP イメージをプリロードします。
• LCP イメージの遅延ロードを避けます -- すぐにロードしたい場合は、遅延ロードにより画像が延期されます。

CSS の最適化:

• レンダリングをブロックする CSS リクエストを回避するために、HTML <head> に重要な CSS をインライン化します。
• media="print" を使用して重要でない CSS (アニメーション、スクロールしないと見えないスタイル) を延期し、ロード時に media="all" にスワップします
• 未使用の CSS を削除 -- PurgeCSS などのツールで無効なルールを排除します

フォントの最適化:

• font-display: swap を使用して、カスタム フォントの読み込み中にフォールバック フォントでテキストをすぐに表示します
• <link rel="preload" as="font" crossorigin> を使用してプライマリ フォント ファイルをプリロードします。
• 使用する文字のみを含むフォントのサブセット (完全な Unicode ではなくラテン語のサブセット)
• 本文のシステム フォント スタックを考慮します -- ネットワーク リクエストなしで即座にロードされます。

---

次のペイントへのインタラクションの最適化 (INP)

INP は、ユーザー操作 (クリック、タップ、キー押下) と次のビジュアル更新の間の遅延を測定します。ページ セッション中のすべてのインタラクションをキャプチャし、最悪のインタラクション (98 パーセンタイル) を報告します。 INP が低いということは、ページが遅く反応しにくいと感じられることを意味します。

長いタスクを中断する

ブラウザのメイン スレッドは、JavaScript の実行、レイアウト計算、描画、およびユーザー入力の処理を処理します。長い JavaScript タスク (50 ミリ秒を超える) はこれらすべてをブロックし、ユーザーが対話するときに目に見える遅延が発生します。

メインスレッドのブロックを軽減するためのテクニック:

• コード分割 -- 現在のページに必要な JavaScript のみを読み込みます。 Next.js はこれをルートごとに自動的に実行しますが、ページ内の動的なインポートによりより詳細な制御が可能になります。
• 重要ではない JavaScript を延期 -- 分析、チャット ウィジェット、ソーシャル メディアの埋め込みは、ページがインタラクティブになる前に読み込む必要はありません。 defer または async 属性を使用するか、ユーザー操作後にそれらをロードします
• Web ワーカー -- 負荷の高い計算 (価格計算、大規模な製品リストのフィルタリング、検索インデックス作成) を、メイン スレッドをブロックしない Web ワーカー スレッドに移動します。
• requestIdleCallback -- アイドル期間中に優先度の低い作業 (将来のページのプリロード、オフスクリーン コンポーネントの事前レンダリング) をスケジュールします。

水分補給の最適化

サーバーでレンダリングされた React アプリケーションは「ハイドレート」する必要があります。つまり、イベント リスナーをアタッチし、サーバーでレンダリングされた HTML とクライアント側の状態を調整します。多くのインタラクティブなコンポーネントを含む大きなページの場合、ハイドレーションには 500 ミリ秒以上かかることがあります。

水分補給戦略:

• 選択的な水和 -- サスペンス境界のある React 18 では、ページの一部を独立して水和できます。ユーザーが操作しているコンポーネントが優先されます。
• プログレッシブハイドレーション -- 最初にスクロールせずに見えるコンポーネントをハイドレートし、ユーザーがスクロールするまでスクロールせずに見えるコンポーネントのハイドレーションを遅らせます。
• React サーバー コンポーネント -- Next.js App Router は、JavaScript をクライアントにまったく送信せずに、サーバー上でコンポーネントをレンダリングします。クライアント側の JavaScript が必要なのは対話型コンポーネントのみです

サードパーティのスクリプト管理

サードパーティのスクリプトは、e コマース サイトにおける INP の最大の原因です。一般的な Shopify ストアでは、15 ～ 25 個のサードパーティ スクリプトを読み込み、合計で 1 ～ 3MB の JavaScript を追加し、メインスレッド時間を競います。

---

累積レイアウト シフト (CLS) の防止

CLS は、ページのライフサイクル中の予期しないレイアウトの変化を測定します。レイアウトのシフトは、ユーザーの操作なしに表示要素の位置が変更されるときに発生します。ユーザーは、ボタンをクリックするとボタンに手を伸ばした瞬間に動いたり、上に広告が読み込まれたときに下に飛び出すテキストを読んだりすることに不快感を感じます。

一般的な CLS の原因と修正

寸法のない画像: すべての <img> 要素には、明示的な width および height 属性、または CSS aspect-ratio が必要です。サイズを指定しないと、ブラウザーは画像にゼロのスペースを割り当て、画像が読み込まれてスペースが占有されるときにコンテンツを移動します。

動的に挿入されるコンテンツ: 既存のコンテンツの上に挿入されるプロモーション バナー、Cookie 同意バー、および通知トーストは変化を引き起こします。これらの要素用のスペースを確保するか、コンテンツを押し下げない方法 (固定位置、オーバーレイ) で要素を挿入します。

Web フォントによりテキストのリフローが発生する: カスタム フォントがロードされてフォールバック フォントと置き換えられると、文字幅の違いによりテキストがリフローする場合があります。 font-display: optional (時折のフォールバック表示を受け入れる場合) または慎重に一致したフォールバック フォント メトリックを持つ font-display: swap を使用します。

遅延読み込みの広告と埋め込み: 広告スロット用のスペースを予約し、CSS min-height または aspect-ratio を使用して埋め込みます。広告サーバーが遅い場合でも、レイアウトは安定しています。

ページ タイプ別の CLS 予算

---

CWV の測定と監視

ラボツール (総合テスト)

• Lighthouse -- Chrome DevTools に統合され、最適化の提案を含む CWV スコアを提供します
• WebPageTest -- 各要素がいつレンダリングされるかを正確に示すフィルムストリップ ビューによる詳細なウォーターフォール分析
• PageSpeed Insights -- ラボ データ (Lighthouse) とフィールド データ (CrUX) を組み合わせて全体像を把握します

フィールドデータ (リアルユーザーモニタリング)

ラボツールは制御された条件下でテストします。フィールド データは、さまざまなデバイス、ネットワーク、条件にわたる実際のユーザー エクスペリエンスをキャプチャします。

• Chrome ユーザー エクスペリエンス レポート (CrUX) -- 実際の Chrome ユーザーから集約された CWV データ。PageSpeed Insights と BigQuery で利用可能
• web-vitals ライブラリ -- 運用環境で CWV を測定し、分析にレポートする JavaScript ライブラリ
• RUM プロバイダー -- Datadog RUM、SpeedCurve、Sentry Performance はビジネス指標とともに CWV をキャプチャします

継続的なモニタリング

スコアが低下したときに警告を発する自動 CWV モニタリングを設定します。

1. CI/CD パイプラインで Lighthouse CI を実行して、デプロイ前に回帰を検出します
2. CrUX データを毎月監視して、最も重要なページ全体の傾向を確認する
3. RUM を使用して、CWV スコアをビジネス指標 (コンバージョン率、直帰率、セッションごとの収益) と関連付けます。
4. ビジネスへの影響を直接測定するための A/B テストのパフォーマンスの変更

包括的な監視設定については、可観測性と APM ガイド を参照してください。

---

eコマース固有の最適化チェックリスト

このチェックリストを使用して、e コマース サイトの CWV を体系的に改善します。

---

よくある質問

Core Web Vitals は実際に Google のランキングに影響を与えますか?

はい。 Google は、Core Web Vitals がページ エクスペリエンス更新のランキング シグナルであることを確認しました。コンテンツの関連性が依然として主要な要素である一方で、CWV は同様のコンテンツ品質を持つページ間のタイブレーカーとして機能します。競争力のある e コマース キーワードの場合、優れた CWV スコアは目に見えるランキング上の優位性をもたらします。

サーバー設定にアクセスせずに Shopify で CWV を修正するにはどうすればよいですか?

制御できることに重点を置きます: 画像の最適化 (Shopify の組み込み画像最適化や Crush.pics などのアプリを使用)、インストールされているアプリの最小化 (それぞれ JavaScript を追加)、軽量テーマの使用、遅延読み込みによるサードパーティ スクリプトの遅延、すべての画像への明示的な寸法の追加。高度な最適化については、Shopify 速度最適化サービス をご覧ください。

LCP、INP、または CLS を優先する必要がありますか?

最初に最悪のスコアを持つメトリクスを優先します。すべてが不十分な場合は、ユーザーの認識と直帰率に最も直接的な影響を与えるため、LCP から始めます。 LCP の改善 (サーバーの最適化、画像の最適化) は、多くの場合、ページ全体の重量を軽減することで INP も改善します。

CWV の改善が SEO に影響を与えるまでにどれくらい時間がかかりますか?

Google は、シグナルのランキングに 28 日間のローリング CrUX データを使用します。改善を展開した後、変更が CrUX データに反映されるまでに 4 ～ 6 週間かかり、ランキングの変化が表示されるまでにはさらに長くかかる可能性があります。 Search Console で CrUX データを監視し、進行状況を追跡します。

競争力のある e コマースではどの CWV スコアを目標にすべきですか?

3 つの指標すべてが「良好」範囲にあることを目標にします。LCP は 2.5 秒未満、INP は 200 ミリ秒未満、CLS は 0.1 未満です。競技カテゴリーでは、LCP 1.5 秒未満、INP 100 ミリ秒未満、CLS 0.05 未満のトップレベルのパフォーマンスを目指します。これらのスコアにより、e コマース サイトの 80 ～ 90% よりも上位になります。

---

次は何ですか

まずは、最もトラフィックの多いページで PageSpeed Insights を使用して、現在の Core Web Vitals を測定します。最もスコアの悪いメトリクスを特定し、このガイドの最適化手法を実行してください。小さな改善が複合して、500 ミリ秒の LCP 改善と 100 ミリ秒の INP 削減および 0.05 CLS の改善を組み合わせることで、ランキングとコンバージョン率の両方を目に見えて改善できます。

パフォーマンス エンジニアリングの全体像については、ビジネス プラットフォームのスケーリング に関する柱ガイドを参照してください。 CWV スコアに負荷をかけるトラフィックの急増に備えるには、ブラック フライデーの負荷テスト ガイド をお読みください。

ECOSIRE は、e コマース プラットフォーム向けに Shopify 速度の最適化 と Core Web Vitals 監査を提供します。包括的な CWV 分析については、パフォーマンス チームにお問い合わせください。

---

ECOSIRE によって発行 — Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。