Core Web Vitals for Shopify: What Actually Moves LCP

Core Web Vitals conversations usually start with a Lighthouse score and end with an argument about whether it matters. The score is a lab simulation. What matters is field data — what real customers on real phones experience — and it is measured by three numbers.

The three, briefly

LCP (Largest Contentful Paint) — when the biggest thing above the fold finishes rendering. Target under 2.5s. On ecommerce this is almost always the hero image or the product image.

CLS (Cumulative Layout Shift) — how much the page moves around while loading. Target under 0.1. Causes mis-taps and makes a site feel cheap.

INP (Interaction to Next Paint) — how long the page takes to respond to a tap. Target under 200ms. Usually a JavaScript problem.

LCP: it is nearly always images

On a Shopify store the LCP element is the hero or the first product image, and the fix is almost always about bytes and timing.

Serve modern formats. A 2MB JPEG hero becomes 40-60KB as AVIF at the same visual quality. This is usually the single biggest win available and it requires no design change.

Serve the right size. A phone at 390px wide does not need a 2000px image. Responsive srcset with real breakpoints means the phone downloads a phone-sized file.

Do not lazy-load the hero. Lazy loading is right for everything below the fold and wrong for the LCP element — it delays the exact thing being measured. Mark it fetchpriority="high" and load it eagerly.

Do not put the LCP image behind JavaScript. A hero inside a slider that initialises on load cannot start downloading until the script runs. Render the first slide in HTML.

CLS: reserve the space

Layout shift comes from content arriving without a reserved slot.

Images without dimensions. Every image needs width and height attributes or an aspect-ratio in CSS. Without them the browser reflows when the image arrives.

Late-arriving banners and app widgets. Announcement bars, cookie notices, review widgets, and express-payment buttons all commonly inject themselves and push content down. Reserve the height in the initial layout.

Fonts. This one is subtle and costs real CLS: if the webfont has different metrics from the fallback, headings rewrap when it loads. A heading that fits on one line in the fallback and two in the real font moves everything below it. Use a size-adjusted fallback, and reserve a minimum height on display headings that sit near a wrapping boundary.

INP: audit the JavaScript

INP is dominated by third-party scripts competing for the main thread.

The usual offenders, in rough order of cost: review widgets, chat, analytics stacks with several tags, personalisation, and upsell apps that run on every page.

Three moves:

1. Remove what does not earn its place. Most stores are running at least two apps nobody has looked at in a year.
2. Defer what is not needed immediately. Chat, reviews below the fold, and analytics beyond the core can load after interaction or on scroll.
3. Replace apps with theme sections. A review widget that renders server-side in the theme costs nothing at runtime. Four apps replaced this way is often 500ms+ of main thread back.

The app tax is measurable

Take a product page, record the network waterfall, and attribute every request to its source. Most stores are surprised: a third or more of the page weight is apps, and a meaningful share is apps that produce no measurable revenue.

The exercise is worth doing annually. Uninstall in a staging theme, measure, and only keep what pays for itself.

Measure in the field, not the lab

Lighthouse on a developer's laptop tells you almost nothing about your customers. Use field data:

• Google Search Console has a Core Web Vitals report from real Chrome users
• PageSpeed Insights shows field data at the top when there is enough traffic
• A real-user monitoring tool if you want it segmented by template and device

Segment by template. Home, collection, product, and cart fail for different reasons and averaging them hides all of it.

What it is worth

The ranking effect of Core Web Vitals is real but modest. The conversion effect is larger and better established: load time and conversion rate move together, and mobile is where the loss concentrates.

The pragmatic framing: you are not optimising for Google, you are optimising for the customer on a three-year-old Android on a train. Google's metrics just happen to be a decent proxy for that.