Core Web Vitals for Ecommerce: Why High-Intent Visitors Get the Worst Performance

The invisible performance problem in ecommerce

Many of my clients care deeply about passing the Core Web Vitals. Passing means that 75% of all traffic should have a good experience. An admirable goal. But in optimizing for that 75%, a small but critical group of about 5% gets overlooked: the visitors who will convert to customers.

The irony? These high-intent visitors often get the worst performance on your site. Not because you forgot to optimize. Because your caching system actively excludes them.

Last reviewed by Arjen Karel on March 2026

Why your CrUX data hides the problem

Core Web Vitals optimization, mostly due to the Google ranking bonus, tends to focus on optimizing for the slightly below average visitor. In ecommerce, it makes a lot of sense to move beyond this and add an extra focus on high-intent visitors. Those are the visitors converting into customers.

According to research by Deloitte and Google, a 0.1 second improvement in page speed leads to a 9.1% increase in add-to-basket actions for retail sites. That is also the exact moment where caching stops working for them.

We can typically identify these users by the number of items in their cart.

There is another blind spot. CrUX (the Chrome User Experience Report) only tracks Chrome users who have sync enabled. Many ecommerce shoppers use Safari on mobile or non-syncing browsers. Your CrUX dashboard might show green scores while your actual buyers experience something very different. This is why a passing CrUX score does not tell the whole story.

The caching cliff: what happens when a user adds to cart

Here is the problem: adding items to a shopping cart destroys your caching. And caching is what makes your site fast.

Caching plugins disable full page caching for users with dynamic content. Something as simple as "items in a shopping cart" forces the server to rebuild the entire page with every request. This significantly increases your Time to First Byte, which directly slows down Largest Contentful Paint and First Contentful Paint.

The numbers are dramatic. On a typical WooCommerce site, TTFB goes from roughly 100ms (cached) to 1,600ms or more (uncached). That is a 16x increase in server response time the moment someone adds a product to their cart. I have seen cases where logged-in WooCommerce users wait 5 to 9 seconds for a page that loads in under a second for anonymous visitors.

How each platform handles it

WooCommerce sets several cookies when a user adds to cart: woocommerce_cart_hash, woocommerce_items_in_cart, and wp_woocommerce_session. The moment any caching plugin (WP Rocket, LiteSpeed Cache, WP Super Cache) detects these cookies, it bypasses the cache for every page. Not just the cart page. Your homepage, your product pages, your category pages: all uncached. On top of that, WooCommerce fires an AJAX request to /?wc-ajax=get_refreshed_fragments on every page load to keep the mini-cart widget updated. This request alone can take 2 to 3 seconds on shared hosting.

This is one reason why WooCommerce has the lowest Core Web Vitals pass rate of all major ecommerce platforms. According to the 2025 Web Almanac, only 33% of WooCommerce sites pass all three Core Web Vitals on desktop, compared to 76% for Shopify.

Shopify handles this better thanks to its managed CDN infrastructure, but even Shopify cannot cache pages containing customer or cart objects. The difference is that Shopify's baseline TTFB (around 0.51 seconds) is already fast enough that the uncached penalty is smaller.

Magento 2 found a clever solution: the full page is always cached, even for cart users. Dynamic content (mini-cart, user greeting, stock status) is fetched client-side via AJAX to /customer/section/load/ and stored in the browser's localStorage. The page itself stays in the full page cache. This is the "slow by design" problem solved at the architecture level.

Your best customers get your worst pages

The numbers make this painful. Farfetch measured a 1.3% drop in conversion rate for every 100ms increase in LCP. Blue Triangle found a 40 to 50% conversion rate decline when LCP goes from 2 seconds to 4 to 5 seconds.

A visitor browses your fast, cached site. They find a product they like. They click "add to cart." At that exact moment, the caching stops and their TTFB jumps from 100ms to 1,600ms. From here on, every page they visit (comparing products, checking shipping, heading to checkout) is uncached. The people most likely to buy are now browsing the slowest version of your site.

Across sites monitored by CoreDash, we see cart users experiencing 3 to 5 times worse TTFB than anonymous visitors on self-hosted ecommerce platforms. On managed platforms like Shopify the gap is smaller (1.5 to 2x) but still measurable.

How to detect this in your RUM data

You cannot see this problem in Lighthouse or PageSpeed Insights. Those tools test as anonymous visitors with no cookies. Your lab scores will look great while your actual buyers struggle.

To find this problem, you need Real User Monitoring. Segment your RUM data by whether the user has a cart cookie set. Compare the TTFB, FCP, and LCP between these two segments. If you see a 2x or larger gap, caching bypass is your problem.

In most analytics platforms you can also segment by page type. Compare your product listing pages (usually cached) against your cart and checkout pages (never cached). A TTFB difference of more than 500ms between these page types is a red flag that your server waiting duration needs attention.

How to fix performance for high-intent visitors

Fix the backend before relying on caching. Do not solely rely on caching plugins. Analyze your backend code, optimize database queries, and fine-tune your server to ensure a fast TTFB even without caching. A site that is slow without cache will be catastrophically slow for cart users. The cache duration sub-part of TTFB should not be doing all the heavy lifting.

Use partial caching (fragment caching). Cache the expensive parts of your page separately. Product descriptions, navigation menus, and footer content rarely change and can be cached in Memcached or Redis even when the full page cache is disabled. When a cart user requests a page, your CMS assembles it from cached fragments instead of regenerating everything from scratch. This can cut uncached TTFB by 60 to 80%.

Render dynamic components client-side. This is the Magento 2 approach and it works. Serve the majority of the page as cached HTML (server-side rendered). Then use JavaScript and a small API call to fetch the dynamic parts (cart count, user greeting, personalized recommendations) after the page loads. The browser gets the fast, cached HTML immediately. The dynamic bits fill in a moment later. Your LCP and FCP stay fast because they are driven by the cached shell, not the dynamic content.

Shopify's headless framework (Hydrogen) does exactly this: product data is aggressively cached with long TTLs, while cart and customer data uses CacheNone() and is fetched client-side after load. This pattern also avoids INP problems because the dynamic fetch happens asynchronously instead of blocking user interaction.

Implement effective cache key management. Use simple keys for static elements (the URL is often enough as a cache key) and complex keys for dynamic content that includes the user ID, product IDs, and timestamps. This lets you cache at a per-user level instead of choosing between "fully cached" and "not cached at all."

Disable cart fragments on non-cart pages. If you run WooCommerce, disable the wc-ajax=get_refreshed_fragments call on pages that do not display a mini-cart. Several performance plugins (Perfmatters, FlyingPress) offer a toggle for this. It eliminates a 2 to 3 second AJAX call on every page load for cart users.

Consider edge-side composition. If you use Cloudflare, Workers can assemble pages at the edge: serve the cached page body from the CDN and inject dynamic fragments (cart, user info) via separate sub-requests. Cloudflare published an Edge Side Includes implementation for Workers that does exactly this, keeping your TTFB fast while still serving personalized content.