Blog /

Core Web Vitals for E-commerce: What Actually Moves the Needle

Which Core Web Vitals metrics actually affect e-commerce revenue, which optimizations give 80/20 results, and what is overrated. Real data from WooCommerce stores.

MGKNeT

WordPress & E-commerce Experts

Google officially made Core Web Vitals a ranking factor in 2021. Since then, the SEO industry has produced an enormous volume of advice about LCP, INP, and CLS - most of it focused on getting a green score in PageSpeed Insights.

The problem: a green score doesn’t mean you’ve actually improved your store’s revenue. Some of the most impactful performance work we do has almost no effect on PageSpeed scores. And some of the changes that move scores significantly have almost no effect on real users.

Here’s what actually matters for e-commerce stores - and what you can safely deprioritise.

The Metrics That Drive Revenue

LCP (Largest Contentful Paint): The One That Matters Most

LCP measures how long it takes for the largest visible element on the page to load - typically your hero image, product photo, or above-the-fold banner.

For e-commerce, LCP is the metric most directly connected to revenue. The reason is intuitive: when a customer lands on a product page, the product image is usually the LCP element. If that image loads slowly, the customer is sitting on a blank or partial page deciding whether to wait or leave.

The threshold that matters: under 2.5 seconds is “good”, 2.5-4 seconds is “needs improvement”, over 4 seconds is “poor”. But for e-commerce, you should be targeting under 2 seconds on mobile, not just clearing the 2.5 second threshold.

What actually moves LCP:

Server response time (TTFB) is the upstream problem most stores ignore. If your server takes 800ms to respond, you’ve already spent 800ms before a single byte of your page has loaded. No amount of image optimisation fixes a slow server. This is usually a hosting problem.

Image format and sizing is the highest-leverage optimisation for most WooCommerce stores. We routinely find product images served at 2400px width to mobile users viewing them at 400px, in JPEG format, without WebP alternatives. Fixing this alone often cuts LCP by 1-2 seconds.

Resource prioritisation matters more than most guides acknowledge. The browser needs to discover your LCP image quickly and start downloading it immediately. If your LCP image is a CSS background image, or if it’s below a wall of render-blocking scripts and stylesheets, it gets discovered late regardless of how well the image itself is optimised. fetchpriority="high" on your LCP image is one line of code with measurable impact.

INP (Interaction to Next Paint): The New One Everyone Is Confused About

INP replaced FID (First Input Delay) in March 2024. Where FID measured only the delay before the browser started processing your first click, INP measures the full latency of all interactions throughout the page visit - from click or tap to the next visual update.

This change matters a lot for e-commerce because checkout flows are interaction-heavy. Adding to cart, updating quantities, applying coupons, selecting shipping methods - each of these is an interaction that INP measures.

Poor INP on a WooCommerce store almost always comes from JavaScript execution. The usual culprits:

Third-party scripts loaded synchronously. Analytics, chat widgets, marketing pixels, review widgets - these frequently execute large amounts of JavaScript on the main thread. Each one adds to interaction latency. We’ve measured 300-400ms of INP improvement just from moving third-party scripts to load after user interaction rather than on page load.

WooCommerce AJAX requests blocking the UI. When a customer clicks “Add to Cart” and the button stays unresponsive for 800ms while the AJAX request processes, that’s a poor INP event. The fix isn’t making the server faster (though that helps) - it’s updating the UI immediately to acknowledge the interaction, then confirming once the server responds.

Page builder bloat. Many page builders load their entire JavaScript runtime on every page, including pages that don’t use interactive elements. A product archive page doesn’t need the same JS footprint as a configurable product page.

CLS (Cumulative Layout Shift): The Most Annoying, Least Revenue-Impacting

CLS measures how much page content shifts around as the page loads - images without dimensions popping in and pushing content down, fonts swapping and reflowing text, ads loading into spaces that weren’t reserved for them.

A high CLS score genuinely degrades user experience. But in our experience across dozens of WooCommerce sites, CLS improvements correlate less strongly with revenue than LCP or INP improvements. The exception is checkout: a layout shift during payment form interaction - where the submit button moves just as someone clicks it - is catastrophic. We’ve seen this cause cart abandonment spikes.

Fixing CLS is mostly hygiene work: set explicit width and height on all images, reserve space for dynamic content, use font-display: swap or optional carefully (swap can actually increase CLS on slow connections), and test your checkout flow specifically.

The 80/20 Optimisations

If you want to know where to spend your time, here’s the honest prioritisation for a typical WooCommerce store:

1. Fix your hosting first. This is the single change with the largest impact across all three metrics. A server that responds in 150ms instead of 800ms improves LCP directly, gives INP more time budget for JavaScript execution, and removes the TTFB overhead that makes everything else harder. Managed WordPress hosting with server-level caching isn’t optional if you’re serious about performance.

2. Serve modern image formats with correct dimensions. Convert product images to WebP or AVIF. Serve appropriately sized images using srcset. Set explicit width and height attributes. This alone addresses the majority of LCP issues on image-heavy product pages.

3. Audit and defer third-party scripts. Open your browser’s network tab and count how many third-party domains you load on a product page. Each one is a potential INP and LCP problem. Google Tag Manager in particular is frequently misconfigured - loading dozens of tags synchronously that should be deferred or removed entirely.

4. Enable server-level full-page caching. LiteSpeed Cache, Nginx FastCGI cache, or a CDN with HTML caching - anything that serves cached pages to anonymous visitors without hitting PHP or the database. This is the most important WooCommerce-specific optimisation and the one most often skipped on shared hosting.

5. Optimise your WooCommerce AJAX handling. If add-to-cart, quantity updates, and coupon application feel sluggish, profile the AJAX handlers. Common causes: expensive database queries triggered on every cart update, plugins hooking into cart calculations unnecessarily, no object caching (Redis/Memcached) so every request hits the database cold.

What’s Overrated

Obsessing over PageSpeed Insights scores. PageSpeed runs a single simulated test on a throttled mobile connection from a Google data centre. Your real users have different devices, different connections, and different geographic distances from your server. We’ve seen stores with PageSpeed scores of 45 that converted better than competitors scoring 90, because the score-90 store was heavily caching static assets (easy PageSpeed wins) while neglecting server response time and JavaScript execution that PageSpeed weights less.

Eliminating render-blocking resources at all costs. Yes, render-blocking CSS and JavaScript delay page paint. But aggressively inlining or deferring everything can introduce worse problems - FOUC (flash of unstyled content), CLS from late-loading stylesheets, broken interactive elements. The goal is a fast, correct page, not a maximum score.

Lazy loading everything. Lazy loading below-the-fold images is correct and effective. Lazy loading your first product image on a category page - which is usually the LCP element - actively hurts your score and user experience. We regularly find WooCommerce themes and plugins applying loading="lazy" to every image on the page indiscriminately.

Removing plugins to reduce HTTP requests. Bundling and caching have made individual HTTP requests less important than they were in 2015. Removing a plugin because it adds one HTTP request, while that plugin provides genuine functionality, is optimising the wrong thing. What matters is what those requests load: a 50KB JavaScript bundle is a problem, a 2KB CSS file is not.

Real Before/After: What Typical Improvements Look Like

On a WooCommerce clothing store we worked with recently: initial audit showed LCP of 5.2s mobile, INP of 420ms, CLS of 0.18. All three “poor” or “needs improvement”.

The work, in order:

  1. Migrated from shared hosting to managed WordPress VPS with LiteSpeed — TTFB dropped from 820ms to 95ms
  2. Converted and resized product images to WebP with correct srcset — LCP dropped from 5.2s to 2.1s
  3. Added fetchpriority="high" to the first product image on archive pages — LCP dropped further to 1.8s
  4. Audited and deferred non-critical third-party scripts via GTM — INP dropped from 420ms to 180ms
  5. Set explicit image dimensions site-wide and fixed a font loading issue — CLS dropped from 0.18 to 0.04

Final scores: LCP 1.8s, INP 180ms, CLS 0.04. All green. Organic traffic from product category pages increased 23% over the following quarter as the pages gained ranking positions they’d been losing to faster competitors.

The total implementation time was about 12 hours of focused work. No redesign, no new theme, no major code changes.

The Practical Starting Point

Run a PageSpeed Insights test on your homepage, your most important category page, and your most important product page. Look at the field data (not just lab data) if your site has enough traffic for it.

Then look at your TTFB first. If it’s over 400ms, hosting is your bottleneck and everything else is secondary. If TTFB is good, move to LCP and identify your LCP element. Is it an image? Is it optimised? Is it prioritised?

For INP, the Chrome User Experience Report gives you real user data. If your INP is in the poor range, a JavaScript profiling session in Chrome DevTools will show you exactly which interactions are slow and why.

Performance work has a compounding quality: each improvement makes the next one more impactful. A store that fixes its hosting, then fixes its images, then fixes its JavaScript execution will see significantly better results than one that tries to tackle all three simultaneously without addressing them in order.

If you’d like an honest assessment of where your store’s performance bottlenecks are and what the highest-leverage fixes would be, our technical SEO service includes a full Core Web Vitals audit with prioritised recommendations.

Let's build something together

Tell us about your project and we'll figure out how we can help.