Core Web Vitals on Ecommerce Sites: The Usual Culprits
Why ecommerce sites fail LCP, INP and CLS, and the prioritized fixes that actually move Core Web Vitals scores on storefronts.
Ecommerce sites fail Core Web Vitals more often than any other site type, and it’s almost always the same three culprits: an oversized hero or product image loading without priority, third-party scripts — reviews widgets, chat, personalisation, ad tags — blocking the main thread, and image or ad slots that shift the layout because no dimensions were reserved for them. To pass Google’s thresholds — LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, each measured at the 75th percentile of real visitors — you have to fix these three categories specifically, because generic “make the site faster” advice rarely touches the actual bottlenecks on a product-heavy storefront.
Key takeaway
- The three Core Web Vitals thresholds to pass are LCP < 2.5s, INP < 200ms, and CLS < 0.1, each at the 75th percentile of real-user data over a rolling 28-day window.
- On ecommerce sites specifically, the hero/product image is almost always the LCP element, and it’s frequently the thing slowing that metric down.
- Third-party scripts — reviews, chat widgets, personalisation, analytics tags — are the single biggest driver of poor INP on storefronts, not your own code.
- CLS failures on product listing pages are usually caused by images or ad units loading without a reserved width and height attribute.
What Core Web Vitals actually measure, and why ecommerce struggles
Largest Contentful Paint (LCP) measures how quickly the largest visible element — almost always a hero banner or the primary product image — renders. Interaction to Next Paint (INP) measures how responsive the page feels when a visitor actually clicks, taps or types; it fully replaced First Input Delay as Google’s responsiveness metric back in March 2024, so any older audit still discussing FID is measuring the wrong thing. Cumulative Layout Shift (CLS) measures how much visible content jumps around as the page loads. Google grades these using the Chrome User Experience Report at the 75th percentile — meaning three out of four real visits need to hit “good” for the page to pass, not just your own test environment.
Ecommerce sites struggle more than blogs or brochure sites because product pages and category grids are inherently image-heavy, load third-party scripts for reviews and merchandising that a content site doesn’t need, and often render product grids dynamically via JavaScript in a way that delays when the browser knows the final layout.
LCP: the hero and product image problem
The most common LCP mistake on ecommerce sites is treating the main product or hero image like any other lazy-loaded image on the page. It shouldn’t be — it’s the element the browser is racing to paint first, so it needs fetchpriority="high", no lazy-loading attribute, and ideally a properly sized, compressed image served in a modern format like WebP or AVIF rather than an oversized JPEG the CMS never resized. A second common cause is render-blocking CSS or fonts sitting between the browser and the point where it can paint that image — every additional stylesheet or web font the browser must fetch before rendering delays LCP by that fetch’s full round trip.
| Metric | Good threshold | Most common ecommerce cause of failure |
|---|---|---|
| LCP (Largest Contentful Paint) | Under 2.5 seconds | Unoptimised or lazy-loaded hero/product image; render-blocking fonts and CSS |
| INP (Interaction to Next Paint) | Under 200 milliseconds | Third-party scripts (reviews, chat, personalisation) blocking the main thread |
| CLS (Cumulative Layout Shift) | Under 0.1 | Images and ad slots without reserved width/height; late-loading banners and cookie notices |
INP: the third-party script problem
INP failures on storefronts are rarely caused by the store’s own template code — they’re caused by the accumulation of third-party scripts that marketing and merchandising teams add over time: a reviews widget, a live chat bubble, a personalisation engine, retargeting pixels, a heatmap tool. Each one adds JavaScript that competes for the main thread, and when a visitor taps “Add to cart” or opens a size selector while the browser is still busy processing that script, the interaction feels sluggish. The fix isn’t necessarily removing every third-party tool — it’s auditing which ones are actually driving revenue, deferring or lazy-loading the ones that aren’t essential to the initial page render, and loading chat widgets and personalisation scripts only after the main content is interactive rather than blocking on them upfront.
CLS: layout shift on product grids
Category and search result pages are where CLS problems concentrate, because they render dozens of product images in a grid, often lazy-loaded as the visitor scrolls. Every image without an explicit width and height attribute (or a CSS aspect-ratio box) causes the surrounding layout to shift once it loads, because the browser didn’t know how much space to reserve for it in advance. The same applies to promotional banners, cookie consent notices and “free shipping” bars that inject themselves above the fold after the initial page paint — each one pushes everything below it down, and each push counts against your CLS score.
75th percentile
Google doesn’t grade Core Web Vitals on your best-case lab test — it grades on real-user data from the Chrome User Experience Report, and a metric only counts as “good” once at least 75% of real visits to that page hit the good threshold over a rolling 28-day window. A page that scores perfectly in Lighthouse but is slow for visitors on older phones or weak connections can still fail in Search Console.
Source — Google Chrome UX Report methodology for Core Web Vitals assessment
Mobile matters more than desktop for ecommerce vitals
Google’s Core Web Vitals assessment is based primarily on mobile field data for most sites, and ecommerce traffic skews heavily toward mobile devices — which means a store that only tests on a fast office desktop connection is measuring the wrong thing. A product image that loads acceptably fast over broadband can easily blow past the 2.5-second LCP threshold on a mid-range phone over a 4G connection, and third-party scripts that feel instant on a desktop CPU can add hundreds of milliseconds of blocking time on a lower-powered mobile processor. When you’re diagnosing a vitals problem, pull the mobile breakdown specifically in Search Console’s Core Web Vitals report rather than looking at the combined figure, and test with Chrome DevTools’ network and CPU throttling set to simulate a mid-tier phone, not your own device.
This also affects how you prioritise fixes. If mobile LCP is failing while desktop passes comfortably, the fix is almost always image weight and third-party script load order rather than server response time, since a slow server affects both device types roughly equally while heavy client-side rendering disproportionately punishes weaker mobile hardware.
A prioritised fix order for ecommerce sites
Fixing Core Web Vitals on a large catalogue site is a multi-week project, not an afternoon. Work through it in this order, since each step tends to have diminishing returns if you tackle them out of sequence:
- Identify your actual LCP element per template (product page, category page, homepage) using PageSpeed Insights or Search Console’s Core Web Vitals report — don’t assume, verify.
- Fix image delivery for that specific element first: correct sizing, modern format,
fetchpriority="high", no lazy-load attribute on above-the-fold images. - Audit every third-party script currently loading and classify each as essential-to-render, essential-but-deferrable, or removable.
- Defer or lazy-load non-essential third-party scripts so they load after the main content is interactive, not before.
- Add explicit width/height (or CSS aspect-ratio) to every image and ad slot across category and product templates.
- Re-test using real field data — Search Console’s Core Web Vitals report, not just a single lab test — over at least a two-week window before declaring the fix successful.
If you’re mid-migration, this is worth checking alongside your replatforming project rather than after — a new theme or platform frequently resets Core Web Vitals scores in either direction, and it’s far cheaper to catch a regression on staging than after launch. Pagination and grid rendering choices also affect CLS directly; see our comparison of pagination versus load-more on product listings for how that specific decision interacts with layout stability.
Frequently asked questions
Do Core Web Vitals directly affect Google rankings?
Core Web Vitals are part of Google’s page experience signals and can act as a tie-breaker among pages of similar relevance and quality, but strong content and relevance still outweigh a perfect vitals score. That said, poor vitals also hurt conversion rate directly, which makes fixing them worthwhile independent of any ranking effect.
What replaced First Input Delay (FID) as a Core Web Vital?
Interaction to Next Paint (INP) fully replaced FID as an official Core Web Vital in March 2024. INP measures responsiveness across the entire page visit rather than just the first interaction, making it a stricter and more representative metric than FID was.
Why does my site pass Lighthouse but fail in Search Console?
Lighthouse runs a single lab test under controlled conditions, while Search Console’s Core Web Vitals report uses real-user field data from actual visitors on their own devices and connections. A page can look fast in a lab test and still fail for real users on slower phones or networks.
Should I remove all third-party scripts to fix INP?
No — audit them instead of removing them wholesale. Some, like a reviews widget that drives conversions, are worth keeping but should be deferred so they load after the main content becomes interactive rather than blocking that process.
How often should I monitor Core Web Vitals on an ecommerce site?
Check Search Console’s Core Web Vitals report at least monthly, and immediately after any theme update, app installation, or platform change, since those are the events most likely to introduce a regression without anyone noticing until traffic or conversion drops.
The bottom line
Core Web Vitals problems on ecommerce sites are rarely mysterious — they trace back to unoptimised hero images, unmanaged third-party scripts, and layout shifts from images and banners without reserved space. Fix those three categories in order, verify with real field data rather than a single lab test, and treat vitals monitoring as an ongoing part of site maintenance rather than a one-time project. It’s one piece of the broader technical picture in our ecommerce SEO guide.
If your Core Web Vitals report is a wall of red and you’re not sure where to start, we can audit and prioritise the fixes — see our ecommerce SEO plans.
