Ecommerce

Core Web Vitals for ecommerce: fix LCP, INP and CLS by page

Which page templates fail, why they fail and the exact fixes for a WooCommerce or custom store, with a checklist you can hand to any developer.

By RaaoPublished 8 min read

Short answer: what Core Web Vitals mean for an ecommerce site

Core Web Vitals for ecommerce come down to three numbers measured on real shoppers' devices: LCP (how fast the main product image or heading appears) should be 2.5 seconds or less, INP (how fast the page reacts to taps such as "Add to basket" or a filter) should be 200 ms or less, and CLS (how much the layout jumps) should be 0.1 or less. Each store template fails for different reasons: product pages usually fail LCP, category pages fail INP and CLS, and checkout fails INP. Fix them template by template, not page by page.

Why Core Web Vitals matter more for online stores

Google evaluates Core Web Vitals at the 75th percentile of real Chrome visits over a rolling 28 days, separately for mobile and desktop. If one in four mobile shoppers gets a 4-second LCP, the whole URL group is flagged. Since March 2024, INP has replaced First Input Delay, and INP is much harder to pass on JavaScript-heavy stores.

Stores are hit harder than brochure sites for three reasons:

  • Big images above the fold. The product photo is almost always the LCP element, and it is often a 2,000 px JPEG inside a slider.
  • Lots of interaction. Swatches, filters, mini-carts and quantity selectors all count towards INP.
  • Third-party scripts. GA4, Meta Pixel, TikTok, review widgets, chat, cookie banners and A/B testing tools all compete for the main thread.

The cost is not only SEO. Slow pages make paid traffic more expensive because more clicks bounce before the page renders. If you are already seeing a sluggish admin and slow pages overall, start with our guide to why WooCommerce is slow; this article focuses on the three metrics.

How to measure LCP, INP and CLS on product, category and checkout pages

Use the right tool for each job:

Tool Data type Use it for
Search Console → Experience → Core Web Vitals Field (CrUX), grouped URLs Which templates fail, on mobile or desktop
PageSpeed Insights Field + lab One URL: real-user values at the top, diagnostics below
Chrome DevTools → Performance panel Lab, your device Finding the exact element, script or interaction
web-vitals JavaScript library or GA4 events Field, your own data Per-template monitoring, including checkout (often too little traffic for CrUX)

In Search Console each issue names the metric, the threshold it misses and the device type, for example an LCP issue on mobile. Click one and Google shows example URLs from the affected group. If all examples are /product/... URLs, the problem is your product template.

Google's own reference pages explain the thresholds: web.dev on Core Web Vitals and the Search Console report help.

Which store pages fail which metric (and why)

Template Usual failing metric Typical cause
Home page LCP Hero slider, autoplay video, web fonts blocking text
Category / shop page INP, CLS AJAX filters re-rendering the whole grid, images without dimensions, "load more" pushing content
Product page LCP Main image lazy-loaded or inside a JS gallery, large unoptimised photos, render-blocking CSS
Cart INP Recalculating totals on every quantity change, cart fragments, coupon field scripts
Checkout INP, CLS Address autocomplete, payment iframes loading late, shipping methods appearing after load

Is a speed plugin enough, or do you need better hosting or a new theme?

Be honest about where the bottleneck is before buying anything. There are three levels of fix, and each solves a different problem.

Option Fixes Does not fix When it is enough
Caching/optimisation plugin (WP Rocket, LiteSpeed Cache, Perfmatters) TTFB on cached pages, CSS/JS deferral, lazy-loading Slow uncached pages (cart, checkout, logged-in B2B), heavy JS from the theme Lean theme, under ~30 plugins, mostly guest traffic
Better hosting (managed VPS, Redis, CDN) TTFB everywhere, Black Friday peaks, slow admin Layout shifts, heavy scripts, oversized images TTFB above 800 ms even with caching
Theme rebuild or custom storefront LCP structure, INP from page builders and sliders, CLS by design Bad tag management habits Page builder + many add-ons, or every fix breaks something else

A common trap: stacking two optimisation plugins that both minify and combine files. The result is often broken JavaScript, a checkout that throws Uncaught TypeError in the console and worse INP than before. Use one tool and configure it carefully, excluding checkout and cart from JavaScript delay.

Another trap is optimising the home page only. Shoppers from Google Shopping and ads usually land on product pages, and organic traffic lands on category pages. Those two templates usually decide your Search Console report.

Step by step: fixing LCP on product pages

LCP is the most common failure, and the fixes are well understood.

  1. Identify the LCP element. In PageSpeed Insights, look for the "Largest Contentful Paint element" diagnostic. On a product page it is usually the first gallery image.
  2. Never lazy-load it. Remove loading="lazy" from the first product image and add fetchpriority="high". Many gallery plugins lazy-load every slide, including the first one.
  3. Serve the right size. A 400 px wide phone slot does not need a 2,400 px image. Generate proper srcset sizes and serve WebP or AVIF. Aim for under 150 KB for the main mobile image.
  4. Cut server response time. Time to First Byte above 800 ms (web.dev's TTFB guidance treats 0.8 s or less as good) makes a 2.5 s LCP almost impossible. Use full-page caching for product and category pages, object caching (Redis) for WooCommerce queries, and a CDN.
  5. Remove render-blocking CSS and JS. Inline critical CSS, defer non-critical scripts and drop the slider library if the product gallery can be plain HTML with CSS scroll snap.
  6. Preload the hero font only if text is the LCP element. Use font-display: swap and limit yourself to two font files.

Step by step: fixing INP on category, cart and checkout

INP measures the slowest typical interaction during the visit. On stores, the culprits are long JavaScript tasks.

  • Filters: Replace "reload the whole grid on every checkbox" with server-rendered filter URLs or a lightweight search index. Debounce price sliders. On Kuiba's store, which has 10,000+ products, faceted search had to be instant to be usable at all.
  • Variation swatches: Avoid plugins that rebuild the full variation table in JavaScript on every click. Precompute variation data server-side.
  • WooCommerce cart fragments: The ?wc-ajax=get_refreshed_fragments request runs on many pages to refresh the mini-cart. Load it only when the cart is not empty, or replace it with a small custom endpoint.
  • Third-party tags: Each tag in Google Tag Manager adds main-thread work. Move what you can server-side (server-side GA4, Meta Conversions API), delay chat and review widgets until user interaction, and remove tags nobody looks at.
  • Checkout: Keep checkout scripts to payment, address and tracking. Do not load sliders, popups or upsell widgets on checkout.

In Chrome DevTools, record a Performance trace while clicking a filter. Any task longer than 50 ms shows a red corner; the "Interactions" track shows which interaction pushed INP over 200 ms.

Step by step: fixing CLS (layout shifts)

CLS is often the easiest metric to fix, and it annoys shoppers most when an "Add to basket" button moves under their thumb.

  • Every product image has width and height attributes or a CSS aspect-ratio.
  • The cookie banner overlays the page instead of pushing it down.
  • Promo bars and "free delivery over £50" banners have reserved space.
  • Review stars, price widgets and "only 3 left" badges are rendered server-side, not injected later.
  • Web fonts use font-display: swap with a metric-compatible fallback font.
  • Payment and address iframes in checkout have a fixed minimum height.
  • "Load more" on category pages appends below the viewport, not above.

Core Web Vitals ecommerce checklist by template

Use this as a sprint checklist:

  • Search Console Core Web Vitals report reviewed for mobile and desktop
  • LCP element identified on home, category and product templates
  • First product image not lazy-loaded, has fetchpriority="high"
  • Images resized, in WebP/AVIF, with srcset
  • TTFB under 800 ms on cached pages (check from your target country)
  • Full-page cache, object cache and CDN active
  • Unused plugins and page-builder modules removed
  • Tag Manager audit: each tag has an owner and a purpose
  • Cart fragments limited or replaced
  • Checkout loads only essential scripts
  • Real-user monitoring per template (web-vitals library or GA4)
  • Re-check after 28 days and start validation in Search Console

What it costs to fix Core Web Vitals on an online store

These are estimates from typical projects, not fixed prices. The range depends mostly on how much of the theme and plugin stack can stay.

Scope Typical effort Estimated cost (EUR, excl. VAT)
Audit: field data, per-template diagnosis, prioritised list 1–3 days €400–€1,200
Quick wins: images, caching, lazy-load fixes, tag clean-up 3–8 days €1,000–€3,500
Theme rebuild on the same WooCommerce data 3–8 weeks €4,000–€12,000
Hosting upgrade (managed VPS with caching and CDN) ongoing €30–€150 per month

If your theme is a heavy page builder with 40+ plugins, a rebuild is often cheaper over two years than repeated patching. Raao's store packages are built with speed as a baseline: Starter (from €1,900) and Launch (from €3,900) include fast page loads, and Launch adds CDN, caching and image optimisation as standard. Hosting and maintenance on servers we manage starts at €89 per month. See the ecommerce service and pricing pages for what each tier includes.

If you want a second opinion on your Search Console report, the free 30-minute call is a good place to start: contact us.

How we did it for Kuiba

Kuiba sells premium furniture and lighting with 10,000+ configurable products from 25+ European brands. Speed had to survive a catalogue of that size and a lot of marketing tags.

  • A custom storefront built for speed and SEO, rather than a theme with page-builder layers.
  • Instant faceted search with synonyms and an AI fallback, so filtering a large catalogue stays responsive.
  • Server-side GA4 and Meta Conversions API, which keeps tracking accurate without loading every pixel in the shopper's browser.
  • Feeds for Google Merchant, Meta, TikTok and Pinterest run from the same platform, alongside the storefront.
  • A product configurator with price matrices, finishes and dimensions that prices products correctly online.
core web vitalspage speedwoocommerceseo

Frequently asked questions

Keep reading

Let us look at your setup together

Book a free 30-minute call and leave with a clear next step and a realistic price range.

Prefer writing? Send us a brief
  • 30 minutes, video call, no obligation
  • Talk directly with the engineers who would build it
  • Honest view on scope, timeline and budget

The calendar is provided by Microsoft Bookings, which may set its own cookies.