How to Improve Core Web Vitals on a Shopify Store

“Make my store faster” is not a single problem. Google's Core Web Vitals break speed into three separate measurements, each caused by different things and fixed by different changes, and treating them as one vague number is why so many speed fixes miss. Here is what each one actually measures on a Shopify store, what usually breaks it, and how to check where you stand before changing anything.

Three numbers, not one vague score

Largest Contentful Paint (LCP) measures how long the biggest visible element – almost always a hero image or a large product photo – takes to render. Interaction to Next Paint (INP) measures how long the page takes to visibly respond after a shopper taps or clicks something, from opening a menu to adding an item to cart. Cumulative Layout Shift (CLS) measures how much content jumps around while the page is still loading. Google's current thresholds call LCP good under 2.5 seconds, INP good under 200 milliseconds, and CLS good under 0.1 – and a store can pass two of the three while badly failing the other, which a single blended “speed score” would hide entirely.

This matters for more than a report card. Core Web Vitals are a confirmed part of how Google ranks pages, and slow interaction handling costs sales directly – a shopper who taps “add to cart” and waits for a visible reaction is a shopper deciding whether to trust the button at all. None of the three thresholds are arbitrary either: they were set from research into the point at which a delay or a jump stops feeling instant and starts feeling broken, which is a lower bar than most store owners assume.

LCP: the hero image is usually the culprit

On most Shopify storefronts, the largest element is a homepage hero banner or the main product photo, and the most common cause of a slow LCP is that image loading later than it needs to – oversized, uncompressed, or set to lazy-load when it should be the first thing requested. A hero image should be served in a modern format, sized to the container it actually renders in rather than a source file three times too large, and explicitly excluded from lazy-loading, since lazy-loading the one image visible the instant the page opens defeats its own purpose.

Fonts loaded from a third-party service add a separate delay here too – another domain to connect to, another file to wait for, before the browser can even measure the text. Self-hosted fonts, limited to one or two weights, remove that extra round trip entirely and tend to move LCP in the right direction on their own.

INP: what happens the instant a shopper taps something

INP is the newest of the three metrics, and it is the one most sensitive to how many scripts a theme and its apps are running in the background. Every app injecting its own JavaScript – a reviews widget, a pop-up, a tracking pixel, an upsell tool – competes for the same main thread a shopper's tap needs to reach. A single heavy script running at the wrong moment can make a perfectly normal “add to cart” button feel broken for half a second, which is long enough for a shopper to tap it twice, or give up.

The fix is rarely one big culprit; it is usually several small ones adding up. Audit installed apps the same way you would for cost – sorted by whether each one is still earning its keep – and remove anything idle. Where a feature is genuinely needed, prefer a theme that builds it natively over a script-injecting app, since native code runs in the same pass as the rest of the page instead of fetching, waiting, and painting afterward.

CLS: nothing should move while a shopper is reading

Layout shift comes from content that has no reserved space before it arrives – an image without a set width and height, a cookie banner that shoves the page down after it loads, a font swap that changes text width, an app-injected bar sliding in above the header a shopper had already started scrolling through. Every one of these is fixable by reserving the space in advance rather than letting the browser guess and then correct itself once the real content shows up.

Well-built themes handle most of this by default – explicit image dimensions, skeleton placeholders, fonts set to swap in without changing line length. Where the problem is an app, it is almost always the same story as with INP: something injected after the page already rendered, shoving everything below it downward.

Announcement bars and cookie banners deserve a specific check, since they are the single most common source of a bad CLS score on an otherwise well-built store. If one has to appear, give it a fixed height reserved in the layout from the first paint, rather than letting it slide the whole page down once it loads a second or two later – the difference costs a few lines of CSS and fixes the problem for every page the banner appears on at once.

Field data and lab data disagree, and that is normal

A tool like PageSpeed Insights or Lighthouse gives you lab data – one simulated visit, on one simulated connection, right now. Google Search Console's Core Web Vitals report gives you field data – what your actual visitors experienced, aggregated over the past 28 days, on their real devices and real connections. The two frequently disagree, and that disagreement is not a bug in either tool; a lab test on a fast connection can pass comfortably while real visitors on patchy mobile signal are failing the same metric daily. Treat lab data as a diagnostic tool for finding and fixing specific issues, and field data as the honest record of what shoppers are actually experiencing, since that is the version Google uses for ranking purposes.

How to check where you actually stand

Start in Search Console's Core Web Vitals report to see which metric is failing for real visitors, not a simulated one. Then run PageSpeed Insights on your homepage and your best-selling product page specifically, since a fast homepage and a slow product page is a common and entirely hideable split if you only ever test one page. Fix the worst-failing metric first – usually LCP on a heavy homepage, or INP on a page carrying several apps – then re-test, because improving one metric can shift what the next bottleneck actually is. Do this after every significant theme or app change too, not only once a year, since a single new app installed six months from now can quietly undo the exact fix you made today.

Start from a foundation built to pass

Our REVUE editorial theme is built lightweight by default – self-hosted fonts, correctly sized and eagerly loaded hero imagery, reserved dimensions on every image, and no required third-party apps adding scripts you did not ask for. The shop's own pages run Lighthouse scores of 100 across accessibility, best practices and SEO, with a measured CLS of 0.00 – we hold every edition to the standard described above rather than treating it as a one-off. See the details in the documentation, or explore the full range at Kiosk.