E-commerce Core Web Vitals: the mistakes costing you sales

Why Core Web Vitals are critical for e-commerce

Web vitals aren't just a Google whim. They measure the real experience of your users - and they have a direct impact on your revenue.

The official thresholds (75th percentile of real visits):

The numbers speak for themselves:

• Vodafone: LCP improved by 31% → +8% sales
• Farfetch: every 100 ms of LCP gained → +1.3% conversion
• Swappie: improved LCP + CLS → +42% mobile revenue
• Cdiscount: optimized CWV → +6% revenue on Black Friday

E-commerce site performance isn't a DevOps topic. It's a business topic.

Since March 2024, INP has replaced FID in Core Web Vitals. If your team is still optimizing FID, you're working on the wrong metric.

Mistake #1 - Unoptimized hero product image (LCP)

This is the number one mistake I see on e-commerce sites. The hero image on the homepage or product page is most often the LCP element - and it's systematically mishandled.

Typical symptoms:

• Image served as a 2 MB uncompressed JPEG
• PNG format instead of WebP or AVIF
• No fetchpriority attribute
• loading="lazy" applied to the above-the-fold image

The fix:

<img src="hero.webp" // Always use WebP or AVIF formats
    fetchpriority="high" // Specify priority for the main LCP image
    loading="eager" // This is optional : `eager` is default value
    width="1200" // Specify image sizes
    height="600" 
    alt="Featured product"> // SEO and accessibility alternative description

If the image is loaded via CSS or JavaScript (background-image, JS carousel), add a preload in the head:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Key points:

• Convert to WebP (or AVIF for modern browsers)
• Compress at 85-90% quality - the eye can't tell the difference
• Only apply fetchpriority="high" to one image per page
• On Shopify, use image_tag with the loading: 'eager' parameter for the theme's hero image

A well-handled e-commerce LCP often comes down to this image alone.

Mistake #2 - Product carousel shifting the page (CLS)

Product carousels on the homepage are CLS bombs. The content loads, the carousel initializes, and the whole page jumps down. Result: CLS > 0.25, frustrated user, missed click.

Common causes:

• Carousel height not reserved before JS initialization
• Images without explicit dimensions (width and height)
• Asynchronous loading of the number of visible slides

The fix: Reserve the space before the JS executes:

.carousel-wrapper { min-height: 420px; /* known carousel height */ contain: layout; }

And always set dimensions on images:

<img src="your-image.webp" width="440" height="440" />

On WooCommerce / PrestaShop, third-party carousel plugins (Slick, poorly configured Swiper) are the first culprits. Check that the container has a fixed height in CSS before the script loads.

E-commerce CLS is 80% solved by explicit dimensions and reserved space. No need to refactor the entire architecture.

Mistake #3 - Third-party scripts blocking interaction (INP)

E-commerce INP is the hardest metric to fix - and the most often ignored. Yet since March 2024, it's an official Core Web Vital.

The problem: every click on "Add to cart", every menu open, every interaction triggers JavaScript code. If the main thread is busy with third-party scripts, the visual response exceeds 200 ms. The user perceives the site as slow.

Chatbots, marketing pixels, A/B testing

I've seen this mistake on dozens of e-commerce sites. The usual suspects:

The fix:

1. Load third-party scripts as async - never synchronously in the head. Also avoid defer: if your internal code (menu, cart) waits for this event to initialize, a defer third party can create a functional SPOF - the site renders, but nothing responds to clicks anymore.

2. Delay non-critical scripts until after the first user interaction:

// Load the chatbot only after the first click
document.addEventListener('click', () => {
  loadChatbot();
}, { once: true });

3. Audit via Chrome DevTools → Performance tab → look for "Long Tasks" triggered by your third-party scripts

4. Remove anything unused - an active Pinterest pixel on a site that doesn't run Pinterest campaigns is pure waste

On Shopify sites with 15–20 installed apps, Total Blocking Time often exceeds 2 seconds. Each app adds JS. Cull the list.

Mistake #4 - Lazy load on the LCP image

Common paradox: the team optimizes performance by adding loading="lazy" to every image. Including the LCP image. Result: Largest Contentful Paint explodes.

The problem: loading="lazy" prevents the browser from loading the image until the user is near the area. On mobile, the hero image is often above-the-fold - it should load immediately. But until the page is built by the browser, it doesn't know whether an image will be visible in the viewport or not, which delays the download.

Simple rule:

• Above-the-fold images → loading="eager", which is the attribute's default value (+ fetchpriority="high" if the image is the page's LCP)
• Below-the-fold images → loading="lazy"

On platforms like PrestaShop or WooCommerce, themes often apply loading="lazy" to all images via a global rule. Check your hero image template and explicitly override the attribute.

Diagnostic tool: PageSpeed Insights directly identifies the LCP element and flags whether loading="lazy" is wrongly applied.

Mistake #5 - Web fonts not preloaded (CLS + LCP)

Web fonts are a double source of problems: they delay LCP (invisible text during loading) and generate CLS (text resizes when the font loads - FOUT).

Symptoms:

• font-display: swap without preload → visible CLS on load
• Fonts loaded from Google Fonts without optimization → blocking external request
• Several weights and styles loaded unnecessarily

The fix:

<!-- In the <head>, before any other CSS -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

And in the CSS:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: optional; /* Avoids FOUT on slow connections */
}

font-display: optional is more aggressive than swap: if the font isn't immediately available from cache, the browser uses the system font. Zero CLS, zero delayed LCP. It's the right choice for e-commerces that want clean web vitals.

Practical tip: host your fonts locally rather than from Google Fonts. One fewer external request, one fewer DNS connection = improved LCP (and stronger GDPR compliance).

Mistake #6 - Product filters and sorting generating CLS

Category pages with dynamic filters are classic cases of e-commerce CLS. The user arrives, filters load in JS, and the entire product grid drops 200 px. CLS score: 0.35. Failed.

What's happening:

1. The initial HTML renders without the filters
2. JS injects the filter bar above the grid
3. The grid is pushed down → layout shift

The fix:

Reserve space for the filters from the initial render:

.filters-container { min-height: 56px; /* known filter bar height */ }

Or better: render filters server-side (SSR) so they're present in the initial HTML. On PrestaShop for example, SSR faceted-search modules exist and avoid this problem.

For skeleton loaders on the product grid:

.product-grid { min-height: 800px; /* approximate grid height */ }

Golden rule: never inject content above existing content after the initial load. If you must, reserve the space in advance.

Mistake #7 - High TTFB on category pages (LCP)

TTFB (Time to First Byte) isn't an official Core Web Vital, but it's the first link in the LCP chain. A 2-second TTFB makes an LCP ≤ 2 s mathematically impossible.

On e-commerce category pages, TTFB explodes for specific reasons:

• Complex SQL queries to fetch filtered products
• No HTML cache for anonymous users
• Full server-side rendering on every request (no CDN)
• Third-party modules running server-side on every page

TTFB targets for category pages:

• < 400 ms: excellent
• 400–600 ms: very good
• 600–800 ms: acceptable
• > 800 ms: fix as a priority

Concrete actions:

1. Enable HTML caching for anonymous category pages - it's the fix with the best effort/impact ratio
2. Use a CDN (Cloudflare, Fastly) to serve resources from edge nodes close to users
3. Optimize SQL queries: index the columns used in filters (price, category, stock)
4. Enable object caching (Redis, Memcached) for repeated catalog queries
5. Move to PHP 8.3+ if you're on PrestaShop or WooCommerce - the performance gain is real

On Shopify or SFCC, infrastructure performance is managed by your provider. If your TTFB is still high, look at your site's code:

• Liquid snippets or complex templates can slow down server response time
• Custom developments or apps that inject content server-side can also impact TTFB

Another regularly observed problem is infrastructure location. If your brand is global, a single infrastructure located in Europe will be slower for users in Australia or South America due to distance from the origin.

How to audit your e-commerce Core Web Vitals

Before fixing anything, measure. Field data always takes priority over lab data.

Essential tools:

These tools are free and openly available. They give you an overall sense of your e-commerce site's performance, but offer limited visibility:

• Lab test configurations (PageSpeed in particular) are constrained, and not customizable.
• The RUM data Google collects is limited to Chrome Android visitors and Chrome on Desktop devices.
• Field and lab data are naive about your server-side problems.

Alongside these tools, it's worth calling on an e-commerce web performance expert who can use much more advanced tools, especially profiling tools that optimize server response times.

If you want to start on your own, here's a recommended webperf audit process:

1. Search Console → Core Web Vitals report → identify "Poor" and "Needs improvement" pages
2. Prioritize by business impact: a category page with 50,000 monthly visits is generally worth more than a store locator page with 500 visits over the same period.
3. Chrome DevTools → Performance tab → simulate a slow 4G connection on mobile

Want to identify the root causes of your site's performance issues? Whether you use Shopify, PrestaShop, Sylius or even Salesforce Commerce Cloud, a structured webperf audit is the fastest way to get clear answers.

To understand each metric's mechanics in detail, the full Core Web Vitals documentation covers measurement mechanisms and official thresholds.

Optimizing e-commerce core web vitals isn't a one-off project. Set up continuous monitoring to catch regressions before they hit your sales.

FAQ

Useful sources

• Web Vitals - Official Google documentation - definitions, thresholds and metric lifecycle
• Core Web Vitals and business impact - Case studies - Vodafone, Tokopedia, Redbus, Cdiscount cases
• Optimize LCP - web.dev - complete technical guide
• Optimize INP - web.dev - complete technical guide
• Optimize CLS - web.dev - complete technical guide
• PageSpeed Insights - field + lab measurement tool
• Core Web Vitals report - Google Search Console - real per-page data