Performance & Scalabilityシリーズの一部
完全ガイドを読むコア 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 つの側面である、読み込み速度、インタラクティブ性、視覚的な安定性を測定します。
| メトリック | 何を測定するのか | 良い | 改善が必要 | 悪い |
|---|---|---|---|---|
| LCP (最大コンテンツフルペイント) | 読み込み速度 -- 最大の表示要素がレンダリングされるとき | 2.5秒未満 | 2.5秒～4.0秒 | 4.0秒以上 |
| INP (次のペイントへのインタラクション) | 応答性 -- ユーザー操作と視覚的応答の間の遅延 | 200ミリ秒未満 | 200ミリ秒 - 500ミリ秒 | 500ミリ秒以上 |
| CLS (累積レイアウト シフト) | 視覚的な安定性 -- ページ レイアウトが予期せずどの程度変化するか | 0.1未満 | 0.1～0.25 | 0.25以上 |
注: 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 を追加し、メインスレッド時間を競います。
| スクリプト カテゴリ | 典型的な影響 | 緩和 |
|---|---|---|
| アナリティクス (GA4、メタピクセル) | 100 ～ 300 ミリ秒のメインスレッド | 最初のインタラクション後にロードし、ワーカーのオフロードに Partytown を使用する |
| チャット ウィジェット (インターコム、ドリフト) | 200 ～ 500 ミリ秒のメインスレッド | スクロールまたはクリックしてロードするパターンでの遅延読み込み |
| A/B テスト (Optimizely、VWO) | 100 ～ 400 ミリ秒のレンダリング ブロッキング | 代わりにエッジ側のテストまたは機能フラグを使用してください。 |
| 支払いスクリプト (Stripe、PayPal) | 100 ～ 200 ミリ秒のメインスレッド | チェックアウト ページでのみロードする |
| レビュー ウィジェット (Yotpo、Judge.me) | 100 ～ 300 ミリ秒のメインスレッド | Intersection Observer を使用してフォールドの下に遅延読み込み |
累積レイアウト シフト (CLS) の防止
CLS は、ページのライフサイクル中の予期しないレイアウトの変化を測定します。レイアウトのシフトは、ユーザーの操作なしに表示要素の位置が変更されるときに発生します。ユーザーは、ボタンをクリックするとボタンに手を伸ばした瞬間に動いたり、上に広告が読み込まれたときに下に飛び出すテキストを読んだりすることに不快感を感じます。
一般的な CLS の原因と修正
寸法のない画像:
すべての <img> 要素には、明示的な width および height 属性、または CSS aspect-ratio が必要です。サイズを指定しないと、ブラウザーは画像にゼロのスペースを割り当て、画像が読み込まれてスペースが占有されるときにコンテンツを移動します。
動的に挿入されるコンテンツ: 既存のコンテンツの上に挿入されるプロモーション バナー、Cookie 同意バー、および通知トーストは変化を引き起こします。これらの要素用のスペースを確保するか、コンテンツを押し下げない方法 (固定位置、オーバーレイ) で要素を挿入します。
Web フォントによりテキストのリフローが発生する:
カスタム フォントがロードされてフォールバック フォントと置き換えられると、文字幅の違いによりテキストがリフローする場合があります。 font-display: optional (時折のフォールバック表示を受け入れる場合) または慎重に一致したフォールバック フォント メトリックを持つ font-display: swap を使用します。
遅延読み込みの広告と埋め込み:
広告スロット用のスペースを予約し、CSS min-height または aspect-ratio を使用して埋め込みます。広告サーバーが遅い場合でも、レイアウトは安定しています。
ページ タイプ別の CLS 予算
| ページの種類 | CLSターゲット | 主な注力分野 |
|---|---|---|
| 製品ページ | 0.05未満 | 製品画像、レビューウィジェット、関連製品 |
| カテゴリ・一覧ページ | 0.05未満 | 製品カードの画像、フィルターサイドバー、ページネーション |
| ホームページ | 0.1未満 | ヒーローバナー、プロモーションセクション、目玉商品 |
| チェックアウト | 0.02未満 | 支払いフォーム、配送オプション、注文概要 |
| ブログ/コンテンツ | 0.05未満 | 埋め込み画像、広告スロット、関連投稿 |
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 モニタリングを設定します。
- CI/CD パイプラインで Lighthouse CI を実行して、デプロイ前に回帰を検出します
- CrUX データを毎月監視して、最も重要なページ全体の傾向を確認する
- RUM を使用して、CWV スコアをビジネス指標 (コンバージョン率、直帰率、セッションごとの収益) と関連付けます。
- ビジネスへの影響を直接測定するための A/B テストのパフォーマンスの変更
包括的な監視設定については、可観測性と APM ガイド を参照してください。
eコマース固有の最適化チェックリスト
このチェックリストを使用して、e コマース サイトの CWV を体系的に改善します。
| エリア | アクション | CWV の影響 |
|---|---|---|
| 製品画像 | WebP/AVIF への変換、幅/高さの追加、ヒーロー画像のプリロード | LCP、CLS |
| スクロールせずに見える範囲の CSS | クリティカル CSS をインライン化、残りを延期 | LCP |
| サードパーティのスクリプト | 分析の遅延、チャットの遅延ロード、チェックアウト時のみの支払いのロード | INP |
| フォントの読み込み | プライマリ フォントをプリロードし、font-display を使用します。 LCP、CLS | |
| コード分割 | 製品タブ、レビュー、推奨事項の動的インポート | INP |
| 画像の遅延読み込み | フォールド未満の画像を遅延ロードし、LCP 画像を遅延ロードしない | LCP |
| レイアウト予約 | 画像のアスペクト比、広告スロットの最小高さを設定 | CLS |
| サーバーレンダリング | 製品ページとカテゴリページに SSR/SSG を使用する | LCP |
| CDN キャッシング | 不変ヘッダーを使用して静的アセットをキャッシュし、短い TTL を使用して HTML をキャッシュします。 LCP | |
| 圧縮 | テキスト アセットに対して Brotli を有効にし、圧縮画像を提供する | LCP |
よくある質問
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 の改善を組み合わせることで、ランキングとコンバージョン率の両方を目に見えて改善できます。
パフォーマンス エンジニアリングの全体像については、[ビジネス プラットフォームのスケーリング] (/blog/scaling-business-platform-performance) に関する柱ガイドを参照してください。 CWV スコアに負荷をかけるトラフィックの急増に備えるには、ブラック フライデーの負荷テスト ガイド をお読みください。
ECOSIRE は、e コマース プラットフォーム向けに Shopify 速度の最適化 と Core Web Vitals 監査を提供します。包括的な CWV 分析については、パフォーマンス チームにお問い合わせください。
ECOSIRE によって発行 — Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。
執筆者
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
関連記事
電子商取引のための AI コンテンツ生成: 商品説明、SEO など
AI を使用して e コマース コンテンツを拡張します: 商品説明、SEO メタ タグ、電子メールのコピー、ソーシャル メディア。品質管理フレームワークとブランドの声の一貫性に関するガイド。
AI を活用したダイナミックプライシング: リアルタイムで収益を最適化
AI 動的価格設定を実装し、需要弾力性モデリング、競合他社の監視、倫理的な価格設定戦略により収益を最適化します。アーキテクチャと ROI のガイド。
電子商取引向け AI 不正検出: 販売を妨げずに収益を保護
AI 詐欺検出を実装すると、誤検知率を 2% 未満に抑えながら、不正取引の 95% 以上を捕捉できます。 ML スコアリング、行動分析、ROI ガイド。
Performance & Scalabilityのその他の記事
Webhook のデバッグと監視: 完全なトラブルシューティング ガイド
障害パターン、デバッグ ツール、再試行戦略、監視ダッシュボード、セキュリティのベスト プラクティスを網羅したこの完全なガイドを利用して、Webhook デバッグをマスターしてください。
k6 負荷テスト: 起動前に API のストレス テストを行う
Node.js API の k6 負荷テストをマスターします。仮想ユーザーの増加、しきい値、シナリオ、HTTP/2、WebSocket テスト、Grafana ダッシュボード、CI 統合パターンをカバーします。
Nginx 実稼働構成: SSL、キャッシュ、およびセキュリティ
Nginx 実稼働構成ガイド: SSL 終端、HTTP/2、キャッシュヘッダー、セキュリティヘッダー、レート制限、リバースプロキシセットアップ、Cloudflare 統合パターン。
Odoo パフォーマンス チューニング: PostgreSQL とサーバーの最適化
Odoo 19 のパフォーマンス チューニングに関する専門ガイド。 PostgreSQL の構成、インデックス作成、クエリの最適化、Nginx キャッシュ、エンタープライズ展開のためのサーバーのサイジングについて説明します。
Odoo 対 Acumatica: 成長するビジネスのためのクラウド ERP
2026 年の Odoo と Acumatica の比較: 独自の価格モデル、スケーラビリティ、製造の深さ、成長軌道に適合するクラウド ERP はどれですか。
本番環境での AI エージェントのテストと監視
実稼働環境で AI エージェントをテストおよび監視するための完全なガイド。 OpenClaw 導入の評価フレームワーク、可観測性、ドリフト検出、インシデント対応について説明します。