Core Web Vitals for ecommerce: what LCP, INP and CLS mean for your store

Core Web Vitals are three measurements Google takes of how a page behaves for a real visitor. One is how long the main content takes to appear, one is how quickly the page reacts to a tap, and one is how much the layout jumps while it loads. On a store, those numbers describe the few seconds in which a shopper on a phone decides to wait for your product page or go back to the search results.

SwiftForge Web was founded by Aleš Gaber, who has been building web software since 1998 and online stores since 2005, and we have measured a lot of slow stores along the way. Below is what each number means, where Google draws the line, and what we see actually change them in WooCommerce and PrestaShop.

The three numbers

Largest Contentful Paint (LCP) is the time until the biggest visible element on the screen shows up. On a store that is usually the product photo or the hero banner. Google counts 2.5 seconds or less as good.

Interaction to Next Paint (INP) is the delay between a tap or click and the page visibly responding, for example when someone opens the menu, picks a variant or presses add to cart. Good is 200 milliseconds or less. A page can look finished and still fail this one, because the browser is busy running scripts in the background.

Cumulative Layout Shift (CLS) measures how much things move around during loading. You reach for "Add to cart", a banner finishes loading above it, the button slides down and you tap something else. A score of 0.1 or less is good.

Google reports all of this in two forms. Field data comes from real visitors using Chrome and covers the last 28 days. Lab data comes from a single Lighthouse test under controlled conditions. That is what PageSpeed Insights shows you straight away, and the 0 to 100 Performance score is built from it. Lighthouse treats 90 and up as good, 50 to 89 as needing improvement and anything under 50 as poor.

Why a store is harder than a blog

A blog page is some text and a picture. To build a single product page, a store runs a query for the product, another for its variants or combinations, more for price rules and stock, several for the menu and the layered navigation, and it has to handle a cart that can never come out of a cache. Any of those can be slow, and you won't see any of them by looking at the theme.

That is why a new theme rarely fixes a slow store. The theme is the last thing the browser receives. By then the time has already been lost on the server, before the first byte went out.

What actually changes the numbers

When we open a slow WooCommerce store, a slow LCP almost always means the server needs seconds to build the page. We find wp_options autoloading megabytes of data on every request, a dozen plugins each running their own queries on every page, and a wp_postmeta table with millions of rows and no index that fits the queries. Full-page caching was either never set up, or set up so broadly that it broke the cart and someone switched it off again. Put the same theme on a cleaned-up database, with caching configured around the cart and checkout, and LCP drops by seconds.

In PrestaShop the usual culprit is a module running a heavy query on every page, even on pages where it shows nothing. After that come Smarty cache settings that make every template compile again, and combination or layered-navigation queries that were fine at launch and got slower as the catalog grew. A generic host sees a PHP process using too much CPU and offers a bigger plan. What the store needs is someone to open the module.

INP problems are nearly always scripts: tracking pixels, chat and review widgets, A/B testing tools, and JavaScript from plugins nobody uses any more. Any one of them is small. A store running thirty of them has a problem.

CLS comes from images without declared dimensions, banners inserted after the page loads, and fonts that swap in late. It is the easiest of the three to fix, and the one people most often leave alone.

Underneath all of this, on both platforms, there is usually software that is years behind. An outdated PHP, an old version of the platform and stale plugins or modules are slower on their own. They also stop you from installing the newer, faster versions of everything else. In most of the stores we fix, bringing the software up to date is the biggest single step.

What speed is worth in sales

The study most people quote was done by Deloitte for Google. It found that making a retail site's mobile pages 0.1 seconds faster brought 8.4% more orders on average. That is an average across 37 brands, not a forecast for your store, and we would be wary of anyone who gives you a figure before looking at your analytics. The direction is clear, though, and the work we do moves load times by whole seconds rather than tenths.

We have one example we can show, because both versions are still online. Kozelj.net is a PrestaShop store we upgraded and still maintain. On Google's mobile test the old store's home page scored 42, and its main content took 14.5 to 15.9 seconds to appear. The new store scores 92, with the main content showing in 2.8 seconds. Same products, same business. The details and links to both stores are on our results page.

Measuring your own store

Open PageSpeed Insights and test your home page, your top category and your top product page. Look at the mobile result, not desktop. Single runs vary, so run each page three times and keep the middle value. Write the numbers down before anyone changes anything. Without that baseline you can't tell later whether the work was worth paying for.

Then see where the time goes. If the server response time alone is over a second, front-end work won't save you, because the problem is in the database and the plugins or modules. A quick server with a slow LCP points at images and scripts. A fast page with a poor INP points at third-party scripts.

How we handle it

We sell speed work at a fixed price, because guessing gets expensive. It starts with a free store review: we measure those three pages the way Google does and look for what is slow in the code, database, server and settings, on a copy of the store. Within 3 business days you get the findings ranked by what they cost you and a fixed quote, with no charge and no obligation. The Speed Fix then brings the software up to date, tunes the settings and sets up caching properly around the cart and checkout. Afterwards the store runs on a server we manage, and the guarantee is in writing: a mobile Lighthouse Performance score of 80 or more within 30 days of the fix being finished, or the next month is free.

Prices and the exact measurement method are on the speed optimization page, and there is a separate page for WooCommerce and for PrestaShop. If you only want to know where you stand today, the speed check on our pricing page runs Google's test on your store while you wait.