Fixing INP on Shopify.

What Google actually measures

Core Web Vitals are three field metrics, and the word "field" is the important part. Google grades your store on the Chrome User Experience Report: real sessions from real visitors on real devices and real networks, aggregated at the 75th percentile per URL. At least three quarters of your visitors need a good score before that URL is counted as passing.

The thresholds have not moved. Largest Contentful Paint is good under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. You will find articles claiming Google tightened LCP to 2.0 seconds in a 2026 core update. Google's own documentation still says 2.5, and we would not rebuild a theme against a threshold nobody can point at in the docs.

This is also why a green Lighthouse score means less than founders expect. Lighthouse runs one simulated load on one throttled connection from one location, and it cannot measure INP at all, because INP needs a human tapping things. A store can score 92 in Lighthouse and still fail Core Web Vitals in Search Console, and the Search Console number is the one Google uses.

Why INP is the metric that fails

Interaction to Next Paint replaced First Input Delay in March 2024, and the difference in what it measures is the whole story. First Input Delay only looked at the delay before the browser started handling your first interaction. INP looks at every click, tap and keypress across the entire session, measures the full time until the next frame is painted, and reports close to the worst one.

That change moved the goalposts from "does the page respond when it loads" to "does the page respond every time, including after eight apps have booted". On a Shopify store, most interactions happen after everything has loaded: opening the cart drawer, changing a variant, filtering a collection, opening a review widget. Those are exactly the moments a heavy app stack costs you.

The pattern we see repeatedly is a store passing LCP and CLS comfortably and sitting well over 300 milliseconds on INP, with the failing interactions clustered on the product page and the cart.

The five things that usually cause it

• The cart drawer. Nearly every theme now opens the cart in a drawer, and many implementations re-render the whole cart, re-run currency formatting and re-fire app hooks on every open. It is the single most common failing interaction we find.
• Third-party widgets that boot on load. Live chat, reviews, loyalty, back-in-stock, upsell popups. Each one parses and executes its own bundle, and several of them install global click listeners that run before your theme's handler gets a turn.
• Review and rating apps on collection pages. A collection with 24 products can mount 24 separate widget instances, each doing its own DOM work. The page looks fine until someone taps a filter.
• Carousels and sliders. Especially older ones built on jQuery plugins that were carried over from a previous theme and never removed.
• Tag manager containers nobody has pruned. Every tag fires on the main thread. A container that has accumulated three years of pixels, heatmaps and abandoned experiments is a genuine INP problem, and it is invisible in your theme code.

How to find your actual culprit

Guessing is expensive here, because the obvious suspect is often not the one costing you the milliseconds. Work in this order.

• Start with field data, not a lab test. Search Console's Core Web Vitals report tells you which URL groups fail and on which device type. PageSpeed Insights shows the CrUX field data for a URL at the top of the report, above the Lighthouse section. Read the top half.
• Reproduce the failing interaction on a real phone. Mid-range Android on a throttled connection, not your laptop. INP failures are overwhelmingly mobile, and a desktop test will tell you everything is fine.
• Use the Web Vitals extension in the field. It attributes an INP measurement to the specific element that was interacted with, which turns "the product page is slow" into "the variant picker takes 480 milliseconds".
• Record a Performance profile while you tap. Chrome DevTools' Performance panel shows long tasks as red-cornered blocks. Expand one and you get the script and function that owns it. This is where an app's bundle name shows up, and it is the fastest route from symptom to owner.
• Disable one app at a time and re-measure. Slow, but conclusive. Do it on a duplicate theme rather than live, and change one thing per measurement.

The fixes that hold

Once you know the owner, the fix is usually one of five moves, in rough order of how much they buy you.

• Remove the app. The cheapest millisecond is the one you never spend. If an app is not paying for itself, deleting it beats optimising around it. Our Shopify app audit guide covers doing this without losing features.
• Defer what does not need to run on load. Chat widgets, loyalty launchers and review carousels can almost always load on interaction or on idle instead of at parse time. Loading a chat widget when someone scrolls past the fold, rather than immediately, is invisible to customers and material to INP.
• Break up long tasks. If your own theme code does heavy work inside a click handler, yield to the browser so it can paint first. Update the visible state, then do the expensive part in the next task. INP measures time to the next paint, so painting early is the point.
• Fix the cart drawer specifically. Render the drawer once and update it in place rather than rebuilding it on each open, and avoid re-running every app hook on every cart change.
• Prune the tag container. Audit every tag, delete the dead ones, and move anything that does not need to be synchronous off the critical path.

Themes matter too, but less than people hope. Online Store 2.0 themes load assets more sensibly than the legacy generation, and Shopify's own published theme performance data shows a wide spread between the best and worst performing themes. A modern theme gives you a better starting point. It does not protect you from what you install on top of it.

LCP and CLS, quickly

These are usually fixable in a day, and they are worth clearing before you spend a week on INP.

• LCP. Identify the largest above-fold element, which on a product page is almost always the main image. Give it fetchpriority="high" and never loading="lazy". Serve it at the size the layout actually uses. Preload the font you display in, and make sure nothing render-blocking sits ahead of it in the head.
• CLS. Put explicit width and height on every image so the browser can reserve the box before the file arrives. Reserve space for announcement bars, cookie notices and app-injected banners rather than letting them push content down after paint. Avoid fonts that swap to a wildly different metric.

What passing is actually worth

Being honest about this matters, because it changes how much you should spend. Core Web Vitals are a ranking signal, but a modest one, and they mostly act as a tiebreaker between pages of comparable relevance. Nobody outranks better content by shaving 40 milliseconds.

The return is on the commercial side. A store that responds instantly when someone taps add to cart converts better than one that hesitates, and the effect is concentrated exactly where your margin is: mobile traffic, paid traffic, first-time visitors with no patience. Treat the Search Console pass as confirmation that you fixed something real, not as the goal itself.

Common mistakes

• Chasing the Lighthouse number. It is a lab simulation and it cannot see INP. Optimising for it can even hurt, because it rewards tricks that do not change real sessions.
• Treating speed as a one-time project. Your INP changes the moment someone installs an app, updates the theme or adds a campaign script. Stores that hold their numbers monitor field data continuously, usually as part of a maintenance retainer, rather than doing a speed sprint once a year.
• Installing a speed optimiser app to fix a speed problem caused by apps. Some of these help at the margins. None of them remove the JavaScript that is actually blocking your main thread.
• Measuring on desktop. If most of your traffic is mobile, and for D2C it is, then a desktop measurement is not your number.

FAQ