Core Web Vitals and INP on Shopify: what moves them

Most Core Web Vitals advice is a list of twenty fixes. On a Shopify store only a few of them usually matter, and which ones depends on data most merchants already have. Start with the data, then work on the metric that fails, in the order its parts cost you time.

The three metrics and their thresholds

Each is judged at the 75th percentile of real visits, so a fast experience for most visitors still fails if the slowest quarter is slow. INP replaced First Input Delay because it looks at every interaction in a visit, not only the first. Google says Core Web Vitals are used by its ranking systems, but good scores don’t guarantee top rankings. Treat them as a user-experience target first.

Where to read the numbers

• Shopify’s web performance reports in the admin show LCP, INP and CLS from real visitors at the 75th percentile, broken down by page URL, page type and device. They cover the last 90 days, can lag by up to 36 hours, and mark app installs, theme updates and code changes as numbered lines on the chart. That last feature is the fastest way to link a regression to its cause.
• Search Console’s Core Web Vitals report uses Chrome User Experience Report (CrUX) field data from real Chrome users.
• Lighthouse and PageSpeed lab runs are for diagnosis, not verdicts. INP needs real interactions; in the lab, Total Blocking Time can be a reasonable proxy, but not a substitute.

On low-traffic stores the daily view jumps around. Shopify suggests a weekly or monthly view when traffic is thin.

What moves LCP

LCP breaks into four parts: time to first byte, the delay before the LCP resource starts loading, how long it takes to download, and the delay before it renders. On a Shopify theme the LCP element is usually the hero image or the main product image. In order:

1. Make the LCP image discoverable and first in line. Render it in the HTML with image_url and image_tag so it gets responsive sizes, never with loading="lazy", and mark it fetchpriority="high". Shopify rates both as high-impact LCP practices.
2. Remove what blocks rendering. Render-blocking scripts, whether theme code or app code, delay the moment the image can paint even after it has arrived.
3. Keep preloads for one or two late-discovered resources. Shopify’s guidance is to use preload sparingly; preloading everything flattens the browser’s priorities.
4. Fonts. Host them on Shopify’s CDN or use system fonts, so text doesn’t wait on another connection.

What moves INP

An interaction has three phases: input delay (waiting for the main thread), processing (your event handlers) and presentation delay (rendering the next frame). Shopify’s own guidance is direct about the main cause: JavaScript, whether theme code or scripts from installed apps, runs on the main thread. On most stores the work goes in this order:

1. Cut main-thread work during load. Long tasks from scripts parsing and running make early taps wait. Use defer or async on non-critical scripts and remove what isn’t needed; for apps, see what installed apps add to your storefront’s load.
2. Load code on interaction. A size chart, a review widget or a zoom viewer can load its JavaScript when the visitor first uses it, through dynamic imports.
3. Break up handlers. A variant picker that recalculates price, stock, images and recommendations in one callback is a classic slow interaction. Update what the visitor sees first, then yield to the main thread and do the rest.
4. Shrink what must be rendered. Large DOMs take more work to render, so long product pages built from dozens of sections can pay for it whenever an interaction changes the page. Off-screen content can be deferred with content-visibility.

Start from field data: it tells you which interaction is slow, and on which page type, before you open DevTools.

A working order for a failing store

1. Open the web performance report, switch to mobile, and find the metric and page type that fail. Start with the failing page types that get the most visits.
2. Check the chart’s annotations. If the failure started at an app install or theme change, start there.
3. For LCP, identify the LCP element on that template and check its four parts: is it discovered late, lazy-loaded, too large, or held up by blocking code?
4. For INP, list the interactions visitors actually use on that template (variant picker, add to cart, filters, menu) and profile each in DevTools with CPU throttling.
5. Fix one cause at a time, deploy, and wait for field data to catch up. With a 75th-percentile metric gathered over weeks, several changes shipped together can’t be told apart.

CLS rarely needs this much process on a modern theme. When it fails, the usual cause is content inserted above existing content after load, such as banners, pop-ups or late-loading app widgets, and the fix is to reserve their space in advance.

Changes that rarely move the numbers

• Chasing a Lighthouse score. A lab score of 100 on the home page says little about INP on the product page for real phones.
• Preloading everything. More preloads compete with the LCP image instead of helping it.
• Lazy-loading every image. It helps below the fold and hurts above it, which is where LCP lives.
• Uninstalling an app and assuming its code is gone. Uninstalling and removing its code are separate steps; see what apps add to your storefront’s load.

Does headless fix this?

Not automatically. A headless storefront still loads a hero image and still runs JavaScript on the main thread, so it starts with the same LCP and INP budget problems as a theme and has to solve them the same way. Shopify’s own theme guidance points to Hydrogen for server-side rendering only when a framework is truly required. Snow / Motion, the founder’s Hydrogen showcase, publishes its lab measurements with tool and date on its case study; a demo has no meaningful field data. More in Hydrogen vs Liquid.

How Lintel works on it

We read field data first, find the slowest templates and interactions, trace each one to a theme file, an app or an image, and fix at the source, starting with what affects the most visitors. Then we measure again. We don’t promise a score or a ranking, because neither is ours to promise.