Google measures the real experience of your visitors through the Chrome User Experience Report, a dataset built from millions of actual Chrome sessions. Your store is in there. So is every lag your customers feel when they tap "Add to cart" and nothing happens for half a second.
That lag now has a name and a score: Interaction to Next Paint, or INP.
It became an official Core Web Vital in March 2024, replacing the older First Input Delay metric (web.dev). And it is the one metric where Shopify stores tend to struggle the most, because of how they are built: a theme, a checkout, and a stack of third-party apps all fighting for the same main thread.
Here is what you will get from this article. You will know how to measure your own INP with free tools. You will understand why Shopify has a structural problem with this metric, not a "you installed the wrong app" problem. And you will be able to point at the 5 sources that wreck most scores, and know what to do about each one.
No invented numbers. Every figure here is linked to its source. If a precise weight or percentage is not something I can back up, I will say so plainly and give you a way to measure it on your own store instead.
Let's start with what INP actually is, in terms a store owner can use.
INP in plain terms: the metric that measures whether your site responds when clicked
INP answers one question: when a visitor interacts with your page, how long until they see something change on screen?
An interaction is a tap, a click, or a key press. Hovering does not count. The browser measures the delay between the action and the next visual update (the "next paint"). Then it reports a value that represents the worst, or near-worst, interaction across the whole visit.
That last part matters. INP looks at the full session, not one moment. One bad tap among forty good ones is what gets remembered.
It also helps to know what makes up that delay. An interaction splits into three parts: the input delay (how long the click waits before the browser can handle it), the processing time (your event handlers and any app code that runs), and the presentation delay (the time to paint the result). On a Shopify store, the first two are where app scripts do their damage.
Google sets three bands (web.dev):
| Score | INP value | What it means | |-------|-----------|---------------| | Good | under 200 ms | Feels instant | | Needs improvement | 200 to 500 ms | Noticeable lag | | Poor | over 500 ms | Visibly broken |
The difference from the old First Input Delay metric is the part most people miss. FID only measured the very first interaction on a page, and only the input delay portion of it. INP measures every interaction, and the full path to the next paint.
So a visitor can land on your homepage, scroll, and click a clean menu link with no problem. Then they open a product page, tap a variant selector backed by a slow review app, and wait 700 ms. That one slow tap can drag the whole session score into the "Poor" band.
This is why INP punishes Shopify stores specifically. A typical store has dozens of interaction points: variant pickers, quantity steppers, cart drawers, filter menus, popup closers. Each one is a chance to score badly. You do not need every interaction to be slow. You need one. That is the mental model: one slow click can sink the visit.
Why Google has been pushing hard on INP since 2024
In March 2024, Google made INP an official Core Web Vital and retired First Input Delay (web.dev). This was not a quiet documentation change. It was a swap of one of the three signals Google uses to score the experience of a page.
By 2026, Core Web Vitals sit inside the broader "page experience" picture that Google factors into ranking. INP is now one of the three vitals that feed it, alongside loading and layout stability. A poor INP is no longer just a UX annoyance. It is a measurable signal attached to your store in CrUX, the same dataset Google reads.
The business case behind it is older than the metric. Speed and responsiveness move money.
Akamai's 2017 retail performance research found that delays in how fast a page becomes usable hurt conversion and bounce rates (Akamai 2017). Deloitte's 2020 study, "Milliseconds make millions," reached the same conclusion from a different angle: improving mobile site speed lifted conversion rates measurably across retail and other sectors (Deloitte 2020).
INP is the metric that captures the part of that experience customers feel most directly: the wait between an action and a response. When a shopper taps a variant and the page freezes, that is not an abstract score. That is a moment where they decide whether your store feels trustworthy.
INP also reads worse on mobile, which is where most Shopify traffic now lives. Phones have slower processors than laptops, so a script that finishes in a blink on a desktop can stall a mid-range Android for hundreds of milliseconds. A store that feels fine on your office machine can still carry a poor mobile score.
Google formalized what retailers already knew. Responsiveness is part of the product. INP is how it gets measured, and now, how it gets scored.
The structural problem of Shopify stores
Shopify stores have a hard time with INP, and it is rarely the merchant's fault. It is how the platform composes a page. Three technical reasons stack on top of each other.
1. The third-party app stack. This is the big one. Every app you install (reviews, popups, chat, loyalty, upsells) typically injects its own JavaScript into your storefront. That code runs on the same main thread that has to respond when a customer clicks. Based on the stores I audit, it is common to find well over a dozen apps active at once, each adding scripts and event handlers. The browser can only do one thing at a time on the main thread. When an app's script is busy, your customer's click waits in line.
The trouble compounds because apps rarely clean up after themselves. An app you tested once and abandoned often leaves its script in place, still binding listeners on every page. Each app also assumes it is the only one running, so two apps doing "a little" work on tap end up doing it back to back.
2. Heavy themes. Many premium themes ship with carousels, scroll animations, sticky headers, mega-menus, and "quick view" modals. These features look good in a demo. Each one attaches JavaScript that runs on interaction. A product carousel that recalculates layout on every swipe, or a mega-menu that does heavy work on open, turns a simple tap into a long task. The heavier the theme, the more the main thread is occupied when you need it free, and these features sit on the variant picker, cart drawer, and quick-view modal a buyer touches before purchase.
3. Native Shopify scripts you cannot touch. Some of the work is Shopify's own. The cart ajax that updates the drawer, the checkout, the built-in analytics. These run regardless of how clean your theme is, and they are not something you can optimize from the merchant side. They set a baseline of main-thread work that the rest of your stack adds to.
Put together, the picture is clear. A click on a Shopify product page does not just trigger your theme code. It competes with app scripts, theme features, and platform scripts, all sharing one thread. You start from a baseline you cannot remove, and every layer on top eats into the margin before a tap crosses the 200 ms line.
Shopify publishes its own guidance on storefront speed and what merchants can control (Shopify performance). It is worth reading, because it draws the line between what you can fix and what is baked into the platform.
The takeaway: you cannot fix everything, but the third-party app layer is where almost all of your controllable INP problems live. That is the layer worth auditing first.
How to measure your INP in 2026
You do not need paid tools to get a real number. Three free sources cover most of what you need, and each tells you something different. Use them in order: a field score first, then a hands-on trace to name the cause.
PageSpeed Insights
Start here. Go to PageSpeed Insights, paste your URL, and run your homepage and best-selling product page one at a time. Read the "Mobile" tab first, since that is usually where Shopify scores worst.
The page splits results into two parts. At the top, "Discover what your real users are experiencing" shows field data: the INP your actual visitors recorded over the last 28 days, shown as a Core Web Vital with its colored band. This is the number Google uses. Below it, "Diagnose performance issues" shows lab data from a single simulated load.
Trust the field data for your score. Use the lab data and the diagnostics list to find what is slow. The "Avoid long main-thread tasks" and "Reduce JavaScript execution time" entries list the specific scripts eating the thread, and the filenames often name the app vendor outright. Run the product page, not just the homepage, because product pages carry the heaviest app load and usually score worse.
Chrome User Experience Report (CrUX)
PageSpeed's field data comes from CrUX, Google's dataset of real Chrome sessions (CrUX). It is the source of truth for what Google sees, because it reflects real visitors on real devices rather than one simulated load.
CrUX needs enough traffic to report. Smaller stores may not have a public CrUX entry for individual URLs, in which case PageSpeed says there is not enough field data. Google may still report an origin-level score that aggregates all your pages, a useful directional read. If even that is missing, you fall back to lab measurement and your own testing, which is what the next tool is for.
Chrome DevTools Performance
This is where you stop reading scores and start finding the culprit.
Open your store in Chrome, open DevTools (F12), and go to the Performance panel. Before recording, set the CPU dropdown to "4x slowdown" to mimic a mid-range phone. Click record, then perform a real interaction: tap a variant, open the cart drawer, close a popup. Stop the recording after a second or two.
Look for long tasks, the blocks of main-thread work flagged with a red corner in the timeline. Anything over 50 ms is a long task, and the ones overlapping your interaction are what hurt INP. Use the "Interactions" track DevTools draws above the timeline: it marks your tap and shades the time until the next paint, so you can line up the delay against the scripts that caused it. Click into the long task and read the call stack in the bottom panel; the filenames usually point straight at the app responsible. A file from a review or chat vendor inside a long task is your answer.
This is the step that turns "my INP is bad" into "this specific app is blocking the thread when customers tap." That is what you need before you change anything.
The 5 main sources of bad INP on Shopify
Across the stores I audit, the same five app categories show up again and again as the biggest INP offenders. Here is what each one does, how to spot it in DevTools, and how to fix it. No precise JavaScript weights, because those vary by version; measure them yourself with the Performance panel.
1. Review apps (Loox, Judge.me, Yotpo)
The problem: review widgets load on product pages, render star ratings, photo galleries, and review carousels, and attach handlers to interactive elements. When a review widget is heavy, tapping a variant or scrolling reviews can trigger a long task right where customers interact most, so a variant tap hangs for a beat.
How to spot it: record a Performance trace on a product page while interacting with the review section or a variant selector. Look for scripts from the review vendor inside long tasks.
How to fix: load the review widget lazily so it only initializes when the visitor scrolls near it. Check the app settings for a "lazy load" or "load on scroll" option, which most now expose. If you run more than one review app (it happens), keep one, and enable the lighter rendering mode if offered.
To dig deeper into the apps slowing down your store, also read How much your Shopify apps really cost you.
2. Marketing popups (Privy, OptiMonk)
The problem: popup apps watch for triggers (exit intent, scroll depth, time on page) and inject overlay markup. The watching itself runs on the main thread, and the moment a popup opens or closes, the browser does layout work. A popup that fires while someone is mid-interaction competes for the thread.
How to spot it: trace the page and trigger the popup, then close it. Watch for a long task at open and at close, tied to the popup vendor's scripts. Also check the load-time trace, since the trigger-watching logic does setup work before any popup is shown.
How to fix: reduce the number of active popup campaigns. One well-targeted popup beats three. Disable popups on mobile if they hurt the tap experience, since mobile is where INP scores are weakest. Remove any popup app you are not using; merchants often leave one installed and idle, still loading its script on every page.
3. Chat widgets (Tidio, Crisp, Intercom)
The problem: chat widgets load a launcher button plus a messaging framework. That framework is substantial, and it initializes on page load. The launcher's open animation and the widget's first render can both produce long tasks, so the chat bubble pauses before it expands.
How to spot it: trace the page and click the chat bubble. A long task on open, traced to the chat vendor, is the signature. Also check load-time traces, since some chat scripts do heavy work before any interaction, raising the input delay on the first tap.
How to fix: defer the chat widget so it loads after the page is interactive, or only when the visitor clicks a placeholder button. Many chat vendors document a delayed-load setup. If live chat is not staffed, remove it; an unanswered chat widget costs you INP for no benefit.
4. Loyalty programs (Smile.io, LoyaltyLion)
The problem: loyalty apps add a floating launcher and a points panel that opens in an overlay. Like chat, the launcher loads on every page and the panel does work when opened. On stores where loyalty is a small part of the experience, this is a lot of main-thread cost for a feature few visitors touch: a launcher that loads on pages where it is never used, raising the baseline cost of every other tap.
How to spot it: trace the page and open the loyalty launcher. Look for the loyalty vendor's scripts inside the resulting long task, and check whether the launcher also runs on load across product and collection pages.
How to fix: limit where the loyalty widget loads. It rarely needs to be on every page; an account or rewards page is often enough. Use the app's display settings to scope it. If usage is low, weigh whether the launcher belongs on the storefront at all versus a dedicated rewards page.
5. Upsell carousels (ReConvert, Honeycomb)
The problem: upsell and cross-sell apps inject "you may also like" carousels and bundle widgets, often on the cart and product pages. Carousels are interaction-heavy by nature: each swipe or arrow click can trigger layout recalculation and image work. Place one on the cart drawer and every cart interaction inherits its cost. Shoppers feel it as a cart drawer that lags on each swipe.
How to spot it: trace the cart drawer or product page and interact with the upsell carousel (swipe, click an arrow, add a recommendation). Long tasks tied to the upsell vendor confirm it. Watch the cart drawer specifically, since a slow widget there taxes the highest-intent moment.
How to fix: limit upsell widgets to the pages where they convert, usually the cart or post-purchase. Reduce the number of items the carousel renders at once, since each card carries image and layout cost. Disable carousel animations if the app allows it, since that animation work is often what blocks the thread on each swipe.
INP, LCP, CLS: don't mix them up
INP is one of three Core Web Vitals. They measure different things, and fixing one does not fix the others. Each maps to a different moment in the visit: arriving, acting, and watching the layout settle. Keep them straight:
- LCP (Largest Contentful Paint) measures loading. How long until the largest visible element (usually your hero image or main heading) finishes rendering. A slow LCP means the page takes too long to show up, mostly an image and server problem. Good is under 2.5 seconds.
- INP (Interaction to Next Paint) measures responsiveness. How long until the page reacts to a tap or click. A poor INP means the page is slow to respond once it is there. It is mostly a JavaScript and main-thread problem. Good is under 200 ms.
- CLS (Cumulative Layout Shift) measures visual stability. How much content jumps around as the page loads. A high CLS means elements shift under the user's finger, often because an image loads without reserved space. Good is under 0.1.
The reason this matters in practice: a store can pass LCP and still fail INP. Fast to appear, slow to respond. App scripts are usually the cause, and they are invisible to a metric like LCP that only watches the first paint. This is also why a single "performance score" misleads. The lab score in PageSpeed leans on loading metrics, so a store can show a healthy lab number while real visitors suffer an INP the lab never triggers, because it never clicks anything. Treat the three vitals as three separate jobs, each with its own cause and fix.
INP in 2026: act now or fall behind
INP is the Core Web Vital where Shopify stores lose the most ground, and it is now a scored signal in the dataset Google reads. The good news: most of the damage comes from a layer you control, the third-party apps.
The five usual sources, in order of how often they cause trouble:
- Review apps (Loox, Judge.me, Yotpo): lazy-load the widget, keep one.
- Marketing popups (Privy, OptiMonk): fewer campaigns, remove idle apps.
- Chat widgets (Tidio, Crisp, Intercom): defer load, remove if unstaffed.
- Loyalty programs (Smile.io, LoyaltyLion): scope to fewer pages.
- Upsell carousels (ReConvert, Honeycomb): limit pages, cut animations.
Start by measuring with PageSpeed Insights, confirm what Google sees through CrUX, then open Chrome DevTools and trace a real interaction to name the culprit. The Performance panel turns guesswork into a filename. A field score tells you whether you have a problem, and a trace tells you which app to touch first.
One habit makes the process cleaner: change one thing, then measure again. Disable an app, re-trace the same interaction, and compare the long task before and after. CrUX field data lags by weeks, so the DevTools trace is your fast feedback loop.
Torn between doing the audit yourself or outsourcing it? I compared DIY vs expert in detail. And if you want the full picture on what your stack is costing you, How much your Shopify apps really cost you breaks it down.
The merchants who measure and trim their app layer now will have a quieter main thread, faster taps, and a healthier signal than the ones who wait. INP is not going away. It is getting more weight.
