ECサイトのCore Web Vitals: 購入意欲の高い訪問者が最悪のパフォーマンスを経験する理由

ECサイトに潜む見えないパフォーマンス問題

私のクライアントの多くは、Core Web Vitalsの合格を非常に重視しています。合格とは、全トラフィックの75%が良好なユーザー体験を得られることを意味します。これは賞賛すべき目標です。しかし、この75%を最適化する過程で、約5%の小規模ながら極めて重要なグループが見落とされています。それは顧客にコンバージョンする訪問者です。

皮肉なことに、こうした購入意欲の高い訪問者は、しばしばサイト上で最悪のパフォーマンスを経験します。それはあなたが最適化を忘れたからではありません。あなたのキャッシュシステムが意図的に彼らを除外しているからです。

2026年3月、Arjen Karelによる最終レビュー

CrUXデータが問題を隠してしまう理由

Core Web Vitalsの最適化は、主にGoogleのランキングボーナスを目的としているため、平均より少し下の訪問者に向けた最適化に焦点が当てられがちです。ECサイトにおいては、この考え方から一歩踏み出し、購入意欲の高い訪問者にさらに焦点を当てることが非常に理にかなっています。彼らこそが顧客へとコンバージョンする訪問者だからです。

DeloitteとGoogleの調査によると、小売サイトにおけるページ速度の0.1秒の改善は、カート追加アクションの9.1%増加につながります。そして、まさにこの瞬間こそが、彼らに対するキャッシュ機能が停止するタイミングなのです。

通常、これらのユーザーはカート内のアイテム数によって特定できます。

ここにはもう一つの死角があります。CrUX (Chrome User Experience Report) は、同期を有効にしているChromeユーザーのみを追跡します。多くのECサイトの買い物客は、モバイルのSafariや同期していないブラウザを使用しています。あなたのCrUXダッシュボードが緑色のスコアを示していても、実際の購入者は全く異なる体験をしている可能性があります。これが、CrUXスコアの合格が全てを物語っているわけではない理由です。

キャッシュの崖: ユーザーがカートに追加した時に何が起こるか

ここが問題です。ショッピングカートにアイテムを追加すると、キャッシュが破壊されてしまいます。そして、サイトを高速化しているのはキャッシュなのです。

キャッシュプラグインは、動的コンテンツを持つユーザーに対してフルページキャッシュを無効にします。「ショッピングカート内のアイテム」という単純なものでさえ、リクエストのたびにサーバーにページ全体を再構築させる原因となります。これによりTime to First Byteが著しく増加し、それが直接的にLargest Contentful PaintとFirst Contentful Paintを遅延させます。

その数値は劇的です。一般的なWooCommerceサイトでは、TTFBは約100ms（キャッシュあり）から1,600ms以上（キャッシュなし）に跳ね上がります。これは、誰かがカートに商品を追加した瞬間に、サーバーの応答時間が16倍に増加することを意味します。匿名訪問者には1秒未満で読み込まれるページが、ログインしたWooCommerceユーザーには5〜9秒も待たされるケースを見たことがあります。

各プラットフォームの対応方法

WooCommerceは、ユーザーがカートに追加するとwoocommerce_cart_hash、woocommerce_items_in_cart、wp_woocommerce_sessionなどの複数のCookieを設定します。キャッシュプラグイン（WP Rocket、LiteSpeed Cache、WP Super Cacheなど）がこれらのCookieを検出した瞬間、すべてのページでキャッシュがバイパスされます。カートページだけではありません。ホームページ、製品ページ、カテゴリーページなど、すべてがキャッシュされなくなります。その上、WooCommerceはミニカートウィジェットを更新し続けるために、ページを読み込むたびに/?wc-ajax=get_refreshed_fragmentsへのAJAXリクエストを発行します。共有ホスティングでは、このリクエスト単体で2〜3秒かかることもあります。

これが、主要なECプラットフォームの中でWooCommerceのCore Web Vitals合格率が最も低い理由の1つです。2025年のWeb Almanacによると、デスクトップで3つのCore Web Vitalsすべてに合格しているWooCommerceサイトはわずか33%であり、Shopifyの76%と比較して低くなっています。

ShopifyはマネージドCDNインフラストラクチャのおかげでこの問題をよりうまく処理していますが、Shopifyでさえcustomerまたはcartオブジェクトを含むページをキャッシュすることはできません。違いは、ShopifyのベースラインTTFB（約0.51秒）がすでに十分に高速であるため、キャッシュなしのペナルティが小さい点にあります。

Magento 2は賢明な解決策を見つけました。フルページはカートユーザーに対してさえも常にキャッシュされます。動的コンテンツ（ミニカート、ユーザーの挨拶、在庫状況）は、AJAX経由で/customer/section/load/にクライアントサイドでフェッチされ、ブラウザのlocalStorageに保存されます。ページ自体はフルページキャッシュ内に留まります。これは「意図された遅さ (slow by design)」の問題がアーキテクチャレベルで解決された例です。

最良の顧客が最悪のページを経験する

数字を見ると、これは痛ましい事実です。Farfetchの測定では、LCPが100ms増加するごとにコンバージョン率が1.3%低下しました。Blue Triangleの調査では、LCPが2秒から4〜5秒に悪化すると、コンバージョン率が40〜50%低下することが判明しています。

訪問者は高速にキャッシュされたあなたのサイトを閲覧しています。彼らは気に入った商品を見つけ、「カートに追加」をクリックします。まさにその瞬間、キャッシュ機能が停止し、彼らのTTFBは100msから1,600msに跳ね上がります。これ以降、彼らがアクセスするすべてのページ（商品の比較、送料の確認、チェックアウトへの進行）はキャッシュされません。購入する可能性が最も高い人々が、今やサイトの最も遅いバージョンを閲覧しているのです。

CoreDashによって監視されているサイト全体で、セルフホスト型のECプラットフォームにおいて、カートユーザーが匿名訪問者よりも3〜5倍悪いTTFBを経験していることが確認されています。Shopifyのようなマネージドプラットフォームでは、その差は小さい（1.5〜2倍）ものの、依然として測定可能な影響があります。

RUMデータでこの問題を検出する方法

LighthouseやPageSpeed Insightsでこの問題を確認することはできません。これらのツールは、Cookieを持たない匿名訪問者としてテストを行います。ラボデータのスコアは素晴らしく見える一方で、実際の購入者は問題に直面しているのです。

この問題を発見するには、Real User Monitoringが必要です。ユーザーにカートのCookieが設定されているかどうかでRUMデータをセグメント化します。これら2つのセグメント間でTTFB、FCP、およびLCPを比較してください。もし2倍以上の差が見られる場合、キャッシュのバイパスが問題の原因です。

ほとんどのアナリティクスプラットフォームでは、ページタイプでセグメント化することも可能です。製品一覧ページ（通常はキャッシュされる）と、カートおよびチェックアウトページ（決してキャッシュされない）を比較します。これらのページタイプ間でTTFBに500ms以上の差がある場合、サーバーの待機時間 (server waiting duration)に注意を払う必要があるという赤信号です。

購入意欲の高い訪問者のパフォーマンスを修正する方法

キャッシュに頼る前にバックエンドを修正する。 キャッシュプラグインだけに頼らないでください。バックエンドコードを分析し、データベースクエリを最適化し、サーバーを微調整して、キャッシュがなくても高速なTTFBを確保します。キャッシュなしで遅いサイトは、カートユーザーにとっては壊滅的に遅くなります。TTFBのサブパートであるキャッシュ期間 (cache duration)にすべての重労働を負わせるべきではありません。

部分キャッシュ（フラグメントキャッシュ）を使用する。 ページの処理負荷が高い部分を個別にキャッシュします。製品説明、ナビゲーションメニュー、フッターのコンテンツはめったに変更されないため、フルページキャッシュが無効になっている場合でもMemcachedやRedisにキャッシュできます。カートユーザーがページをリクエストした際、CMSはすべてをゼロから再生成するのではなく、キャッシュされたフラグメントからページを組み立てます。これにより、キャッシュなしのTTFBを60〜80%削減できます。

動的コンポーネントをクライアントサイドでレンダリングする。 これはMagento 2のアプローチであり、効果的です。ページの大部分をキャッシュされたHTML（サーバーサイドレンダリング）として配信します。その後、ページ読み込み後にJavaScriptと小規模なAPI呼び出しを使用して、動的な部分（カートの数、ユーザーの挨拶、パーソナライズされたおすすめ）をフェッチします。ブラウザは高速にキャッシュされたHTMLをすぐに受け取ります。動的な部分は少し後に埋め込まれます。あなたのLCPとFCPは、動的コンテンツではなくキャッシュされたシェルによって駆動されるため、高速な状態を維持できます。

Shopifyのヘッドレスフレームワーク（Hydrogen）はまさにこれを行っています。製品データは長いTTLで積極的にキャッシュされる一方で、カートおよび顧客データはCacheNone()を使用し、読み込み後にクライアントサイドでフェッチされます。動的フェッチはユーザーインタラクションをブロックするのではなく非同期で発生するため、このパターンはINPの問題も回避します。

効果的なキャッシュキー管理を実装する。 静的要素にはシンプルなキー（多くの場合、URLをキャッシュキーとするだけで十分です）を使用し、ユーザーID、製品ID、タイムスタンプなどを含む動的コンテンツには複雑なキーを使用します。これにより、「完全にキャッシュする」か「まったくキャッシュしない」かの二者択一ではなく、ユーザーレベルでのキャッシュが可能になります。

カート以外のページでカートフラグメントを無効にする。 WooCommerceを実行している場合は、ミニカートを表示しないページでwc-ajax=get_refreshed_fragmentsの呼び出しを無効にしてください。いくつかのパフォーマンスプラグイン（Perfmatters、FlyingPressなど）がこの機能のトグルを提供しています。これにより、カートユーザーのすべてのページ読み込みで発生する2〜3秒のAJAX呼び出しを排除できます。

エッジサイドの構成を検討する。 Cloudflareを使用している場合、Workersを利用してエッジでページを組み立てることができます。キャッシュされたページ本体をCDNから配信し、個別のサブリクエストを介して動的フラグメント（カート、ユーザー情報）を注入します。Cloudflareは、これを正確に実行するWorkers向けのEdge Side Includes実装を公開しており、パーソナライズされたコンテンツを提供しながらTTFBを高速に維持します。