Core Web Vitals for Ecommerce: How to Fix LCP, CLS and INP on Your Store

Your store might look perfect. The product photography is sharp, the copy converts, and the checkout flow makes sense on paper. None of that matters if Google’s Core Web Vitals report flags your pages as slow, unstable, or unresponsive. Core Web Vitals measure how real visitors experience your site — not how it performs in a controlled lab test — and Google has used these signals as part of its ranking algorithm since 2021.

E-commerce sites carry a heavier performance burden than almost any other website type. A blog loads text and a few images. A store loads product galleries, variant selectors, review widgets, live inventory counters, upsell popups, and third-party checkout scripts — often all on the same page. Every one of those elements can quietly damage your Core Web Vitals scores, and every damaged score chips away at both your rankings and your conversion rate.

This guide breaks down exactly how to fix the three Core Web Vitals—Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP)—with specific, platform-level fixes for Shopify, WooCommerce, and custom-built or Magento stores.

What Changed: INP Replaced FID

If you’ve read older Core Web Vitals guides, you’ve probably seen First Input Delay (FID) listed as one of the three core metrics. That’s outdated. Google officially retired FID in March 2024 and replaced it with Interaction to Next Paint (INP) as the responsiveness metric inside Core Web Vitals.

The difference matters. FID only measured the delay before a browser responded to a visitor’s first interaction on a page. INP measures the responsiveness of every interaction during a visit — clicking a size selector, opening a mobile menu, tapping “Add to Cart” — and reports the worst (or near-worst) delay. That makes INP a far stricter, more realistic test of how a store actually feels to use.

If your site or your developer is still optimizing for FID, you’re solving a problem Google no longer measures. The current thresholds you need to hit are:

Google uses the 75th percentile of real visitor data to assign a pass or fail at the page level — meaning at least 75% of your visits need a “Good” score across all three metrics for that page to pass. This data comes from the Chrome User Experience Report (CrUX) and shows up directly inside your Google Search Console Core Web Vitals report.

For the rest of this guide, every fix is built around the current three metrics: LCP, CLS, and INP.

Fixing LCP on Product and Category Pages

LCP measures how long it takes for the largest visible element on a page to render. On most ecommerce templates, that element is the hero product image, the main category banner, or a large heading sitting above the fold. Slow LCP almost always traces back to one of the same root causes.

Compress and convert your images

Product photography is usually the single biggest contributor to a slow LCP. Convert images to WebP or AVIF instead of JPEG or PNG — these modern formats deliver the same visual quality at a fraction of the file size. A 2MB product hero image can often be brought under 150KB without a visible quality loss.

Set explicit dimensions and preload the LCP image

Browsers need to know an image’s width and height before they can reserve space for it. Adding a preload tag for your above-the-fold hero image tells the browser to fetch it immediately, rather than discovering it deep in the page’s render queue.

Lazy-load everything except the LCP element

Product grids, related-item carousels, and below-the-fold category images should all load lazily. The only image that should load eagerly is the one Google is actually measuring for LCP.

Reduce server response time

A fast image still arrives slowly if your server takes too long to respond. Use a content delivery network (CDN) to serve cached assets from a location physically closer to your visitor, and make sure your hosting plan isn’t the bottleneck — this becomes especially important on self-hosted platforms, which we cover in the platform sections below.

Eliminate render-blocking resources

CSS and JavaScript files that load before your main content can delay LCP significantly. Defer non-critical scripts and inline only the CSS needed to render what’s visible on first load. If your store has never had a structured technical SEO audit, this is usually the first place real, measurable gains appear. Our technical SEO service starts here for exactly that reason.

Eliminating CLS on Add-to-Cart and Dynamic Elements

CLS measures visual stability — how much content unexpectedly moves while a page loads or while a visitor interacts with it. On ecommerce sites, layout shifts tend to cluster around the same handful of culprits.

Reserve space for images and embeds before they load

Any image, video, or iframe without explicit width and height attributes will cause the browser to shift surrounding content once the asset finally loads. This is the single most common cause of CLS failures on product pages.

Watch for late-loading review widgets and trust badges

Third-party review platforms, star-rating widgets, and trust badges often inject themselves into the page after the initial render — pushing the “Add to Cart” button or price down the moment a visitor is about to interact with it. Reserve a fixed-height container for these elements so their arrival doesn’t move anything else.

Control how banners and popups appear

Announcement bars, cookie consent banners, and promotional popups that slide in after page load are a frequent CLS trigger. Where possible, reserve their space in the initial layout rather than injecting them dynamically, or animate them in a way that doesn’t displace other content.

Fix font-loading shifts

When a custom web font loads after a page’s fallback font has already rendered, text can resize and reflow — shifting everything below it. Use font-display: swap and preload your critical font files to minimize this gap.

Avoid inserting content above existing content

Dynamically inserted elements like a “low stock” warning or a shipping countdown that appears above the product description should be designed into the layout from the start, not injected on top of it after the fact.

Reducing INP on Checkout and Interactive Flows

INP is where e-commerce sites tend to fail the most quietly, because the damage doesn’t show up until a real visitor actually clicks something. A page can look fast and still feel sluggish the moment someone taps “Add to Cart” and nothing happens for half a second.

Separate product-page INP from checkout-page INP

 These are different problems with different stakes. On a product page, a slow variant selector or a laggy zoom feature is frustrating. On a checkout page, a delayed response to a form field or payment button directly threatens the sale. Audit and fix checkout-flow INP as its own priority, not as an afterthought to product-page fixes.

Find and break up long JavaScript tasks

INP problems are almost always caused by the browser’s main thread being too busy to respond to a click. Use Chrome DevTools’ Performance panel to identify long tasks, then break them into smaller chunks or move them off the main thread entirely.

Defer or remove unnecessary third-party scripts

Live chat widgets, analytics trackers, marketing pixels, and A/B testing tools are common INP offenders because each one competes for the same main thread your “Add to Cart” button needs to respond. Audit every third-party script on your highest-traffic pages and remove anything that isn’t earning its performance cost.

Optimize event handlers on interactive elements

Mini-cart drawers that reflow the entire cart on every click, mega-menus that attach dozens of listeners, and live search-as-you-type fields are frequent INP culprits. Simplify the logic behind these interactions wherever the user experience allows it.

Shopify-Specific Fixes

Shopify stores face a particular version of this problem: you don’t control the server or the core platform code, so almost every Core Web Vitals issue traces back to your theme, your apps, or your media.

Audit installed apps ruthlessly

Apps are the most common cause of poor Core Web Vitals on Shopify. Many inject JavaScript and CSS globally — on every page, not just the ones where the app is actually used. Use the Coverage tab in Chrome DevTools to identify unused code, and remove or replace any app whose performance cost outweighs its value. The most effective fix is almost always removing an app, not adding a “speed booster” app on top of the problem.

Check your theme’s built-in image handling

 Modern Shopify themes like Dawn support responsive images and lazy loading natively — but only if implemented correctly in the theme’s Liquid templates. Confirm your hero and product images are using srcset and appropriate sizes attributes rather than serving one oversized image to every device.

Use Shopify’s built-in speed dashboard alongside Search Console

 Shopify Admin includes a basic speed score under Online Store > Themes. It’s simplified, but it’s useful for spotting directional regressions quickly—pair it with the full Core Web Vitals report in Google Search Console for real-user field data.

Re-test after every theme update or app install

Shopify stores regress quietly. A new app, a theme update, or a new product video can silently push LCP or INP back into “Needs Improvement” territory. Make re-testing part of your regular publishing workflow, not an annual event.

WooCommerce-Specific Fixes

WooCommerce inherits WordPress’s biggest structural weakness: you’re responsible for your own hosting, plugins, and theme efficiency, and most stores accumulate technical debt fast.

Start with hosting and server response time

WordPress sites consistently struggle with LCP more than INP, and the root cause is usually slow Time to First Byte (TTFB) from inadequate hosting. Budget shared hosting is rarely sufficient for a store with real traffic. Managed WordPress or WooCommerce-specific hosting with server-level caching solves problems that no plugin can fix on its own.

Audit your plugin count

The average WordPress site runs 20–30 active plugins, and each one can load its own CSS and JavaScript on every page — including a contact form plugin’s scripts loading on your product pages, or a WooCommerce script loading on blog posts where it serves no purpose. Deactivate anything that isn’t earning its keep.

Use a caching plugin correctly, but don’t expect it to fix a slow foundation

 Caching plugins like WP Rocket can meaningfully improve performance, but only after server response time, hosting quality, and theme efficiency are already in reasonable shape. A perfectly configured caching plugin on slow hosting will still produce a poor LCP score.

Choose a lightweight theme and avoid heavy page builders where possible.

Page builders often generate bloated HTML with hundreds of unnecessary wrapper elements and load CSS for every widget type, whether or not that widget is used on the page. A lightweight theme paired with the native WordPress block editor produces a measurably smaller DOM and faster render times.

Other Platforms: Magento and Custom-Built Stores

If your store runs on Magento or a custom-built platform, you have more control than Shopify or WooCommerce merchants — which also means more responsibility for getting the fixes right.

Implement edge caching through a CDN. Fastly and Cloudflare both offer edge caching configurations suited to Magento’s cache-key requirements, and either can meaningfully reduce TTFB, which feeds directly into LCP.

Load JavaScript modules asynchronously. For INP issues, configure asynchronous module loading — through Magento’s RequireJS configuration or your custom build’s equivalent — so third-party and non-critical scripts don’t block the main thread during user interactions.

Set explicit dimensions in your gallery and template files. CLS issues on custom platforms usually trace back to product image templates missing explicit width and height attributes. This is typically a small, direct fix at the template level once identified.

Build performance budgets into your deployment process. Custom platforms give you the flexibility to run automated Lighthouse tests on every deployment. This catches regressions before they reach real visitors, rather than discovering them weeks later in Search Console.

Field Data vs. Lab Data: How to Monitor This Going Forward

Fixing Core Web Vitals once is not the same as passing them permanently. Theme updates, new apps, seasonal content changes, and traffic spikes can all quietly degrade your scores after the fact. Ongoing monitoring depends on understanding the difference between two types of data.

Field data comes from real visitors using your site in real-world conditions, aggregated through the Chrome User Experience Report. This is what Google Search Console’s Core Web Vitals report shows you, and it’s based on a rolling 28-day window — meaning changes you make today won’t fully reflect in Search Console for several weeks.

Lab data comes from simulated tests, like the ones PageSpeed Insights and Lighthouse run on demand. Lab data is useful for debugging a specific page immediately after a fix, but it doesn’t account for the variety of real devices, connection speeds, and conditions your actual visitors use.

The practical workflow: use Search Console’s field data to identify which pages and metrics are failing at the 75th percentile, then use PageSpeed Insights or Chrome DevTools to debug the specific cause on a representative URL. Recheck Search Console again after 28 days to confirm the fix held under real-world conditions — and rerun this check after any significant theme, app, or content change going forward.

Getting Your Store Across the Line

Core Web Vitals are not a one-time checklist — they’re an ongoing discipline that shifts every time you update a theme, install an app, or launch a new campaign. The stores that consistently pass all three metrics are the ones that treat performance monitoring as part of their regular workflow, not a problem they fix once and forget.

If you’ve worked through the fixes above and your store is still showing “Needs Improvement” or “Poor” scores in Search Console, the underlying cause is often buried deeper than a single plugin or image—in template structure, hosting configuration, or script execution order—and requires a closer technical audit. That’s exactly the kind of diagnostic work our technical SEO service is built around, paired with the broader strategy covered in our ecommerce SEO service for stores that need both the technical fixes and the content and link strategy to go with them.