All writing
Speedscope

Shopify Core Web Vitals explained: LCP, CLS, and INP for merchants

2026-06-11·7 min read·Bedrock Content Team

Google's Core Web Vitals have been part of the search ranking algorithm since 2021, yet many Shopify merchants still find the three metrics confusing in practice. This post explains what each one actually measures, why Shopify stores are structurally vulnerable to poor scores, and what it looks like to track them over time rather than just checking once.

What are Core Web Vitals?

Core Web Vitals are three specific metrics Google uses to measure the quality of a user's experience on a web page. They sit within the broader "Page Experience" signals Google applies to organic search rankings, which means they affect both how your store feels and how often it appears in search results.

The three metrics are:

  • LCP — Largest Contentful Paint
  • CLS — Cumulative Layout Shift
  • INP — Interaction to Next Paint

Each one measures a different dimension of experience. Improving all three at once is possible but rarely happens from a single change — they usually require separate attention.

LCP: how fast does the page look ready?

Largest Contentful Paint measures how long it takes for the biggest visible element on the page to finish rendering. For most Shopify storefronts, that element is a hero image, a large product photo, or a prominent block of text near the top of the page.

The threshold Google considers "good" is under 2.5 seconds. Between 2.5 and 4 seconds is labelled "needs improvement." Above 4 seconds is poor.

On Shopify, LCP commonly suffers because of images. A hero image that hasn't been resized or compressed, served in a format the browser spends time decoding, or without proper cache headers can add seconds to LCP on its own. App scripts that load early and compete for the browser's thread can also delay how quickly that main image gets painted, even when the image itself is optimized.

CLS: does the page stay still while loading?

Cumulative Layout Shift measures how much visible content moves unexpectedly during page load. The canonical frustrating example: you're about to tap a link, the page shifts, and you tap something you didn't mean to.

A good CLS score is under 0.1. Between 0.1 and 0.25 needs improvement. Above 0.25 is poor.

Shopify stores tend to accumulate CLS sources in predictable ways:

  • Images without declared dimensions. When the browser doesn't know an image's size before it fetches it, it can't reserve space on the page. Content below the image jumps downward when the image loads.
  • App widgets and chat bubbles. Some third-party embeds push existing content aside when they initialize rather than occupying reserved space.
  • Font swaps. If a custom font loads after the browser has already rendered text in a fallback font, the text can reflow — especially if the fonts have different metrics.

CLS is worth fixing beyond just the ranking signal. A layout that shifts around feels unstable and unreliable, which matters most on mobile where tap targets are already small.

INP: how quickly does the page respond to input?

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. Where FID measured only the delay before the browser began handling the first user interaction, INP captures the full responsiveness of the page throughout an entire visit — taps, clicks, and keyboard events included.

A good INP score is under 200 milliseconds. Between 200 and 500 milliseconds needs improvement. Above 500 milliseconds is poor.

INP tends to degrade as JavaScript load on a page increases. Every app that injects a script into the storefront adds work to the browser's main thread. The browser can only do one thing at a time on that thread, so when enough scripts are running — processing events, polling for data, animating elements — it can't respond to user input promptly, even when the visual page looks ready and complete.

Why Shopify stores are structurally vulnerable

Each of the three metrics can be hurt by the same underlying cause: accumulated scripts from apps.

Shopify's ecosystem makes it easy to install apps, and most apps include a storefront component. A review widget, a loyalty badge, a live chat button, a cookie consent banner — each adds JavaScript that loads on every page of your storefront. Any individual app's contribution to load time may be minor. The cumulative effect of a dozen or more running simultaneously is not.

This accumulation is a normal outcome of growing a store, not a sign that anything specific was installed carelessly. But it does mean Core Web Vitals scores tend to erode gradually over time, without any single change being the obvious culprit. A score that was good when you last checked may have declined since a new app was added or a theme update shipped.

The difference between lab scores and real-user scores

There are two sources of Core Web Vitals data, and they can tell different stories.

Lab data — from tools built on Google's PageSpeed Insights API — loads your page in a controlled environment and reports what it measures. This is reproducible and useful for understanding what on the page is slow, but the simulated environment doesn't match the range of devices, networks, and locations your actual shoppers use.

Field data (real-user monitoring) collects measurements from real visits. This is the data Google uses for ranking purposes, and it reflects what people actually experience. It requires a snippet running on your live storefront to capture and report back the measurements.

Both are worth watching. Lab data tells you what to fix. Field data tells you whether the fix changed anything for real users.

Tracking scores over time

A one-time check of your Core Web Vitals scores is better than nothing, but a snapshot doesn't tell you whether your store is improving, declining, or holding steady. The more useful picture is a trend — so that when a score changes, you can correlate it with what happened around the same time.

Speedscope tracks Core Web Vitals for your Shopify store continuously, giving you historical data rather than isolated readings. It captures both lab metrics (via the PageSpeed Insights API) and real-user measurements (via a theme extension) so you have both views in one place. When a metric dips, the timeline makes it easier to ask the right question: what changed when that score dropped?

Speedscope also includes app-impact analysis, which breaks down how individual installed apps affect your storefront's performance — useful when you suspect a specific app is contributing to a problem but aren't sure which one.

A practical starting point

If you haven't checked your Core Web Vitals recently, Google Search Console shows field data for stores with enough traffic, and PageSpeed Insights gives lab data for any URL on demand. Those are free and available without installing anything.

If your scores are already good, the ongoing challenge is keeping them that way as your store evolves — new apps, theme edits, seasonal campaigns. If they need work, the next step is understanding which metric is worst and what's driving it, rather than treating "slow site" as a single undifferentiated problem.

For stores that add apps and update themes regularly, that's an ongoing monitoring task more than a one-time fix. Speedscope is built for that work.