Shopify INP Fix: Pass Core Web Vitals When Apps Slow Your Store

INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, according to Google's web.dev announcement. FID only timed the delay before the first interaction was handled. INP looks at every click, tap and key press during a visit and reports the slowest one, ignoring one outlier for every 50 interactions.

Each interaction has three parts. Input delay is the wait before your code starts running, usually because the browser's main thread is busy with something else. Processing time is your event handlers running. Presentation delay is the browser recalculating layout and painting the result. A slow tap can come from any of the three.

Scrolling and hovering don't count. That's why a store can scroll smoothly and still fail INP: the problem shows up when someone taps a size swatch, opens the cart drawer or applies a filter.

Shopify stores are especially exposed because every app you install can add JavaScript to every page. Shopify's help center says that when INP is poor, the most likely cause is too much JavaScript from theme code, app code or third-party and tag manager code. Each extra script competes for the same main thread your shopper's tap needs.

You'll find the report under Analytics > Reports in your Shopify admin, or from the performance summary on the Themes page. As of September 2026 it rates LCP, INP and CLS as Good, Moderate or Poor, covers the last 90 days, and can lag by up to 36 hours. You can break it down by page type, individual page URL and device type.

The over-time charts carry numbered annotations for events such as app installs, theme updates and new code. If INP got worse the week you installed a new upsell app, the chart will usually show it.

PageSpeed Insights mixes two different things. The top section shows field data from the Chrome User Experience Report (CrUX), a trailing 28-day sample of real Chrome users. The big performance score below it comes from Lighthouse, which, according to Google's PageSpeed Insights documentation, simulates a mid-tier phone on a mobile network. A lab test doesn't tap anything, so it reports Total Blocking Time as a stand-in rather than measuring INP.

Shopify's numbers can also differ from CrUX because Shopify collects data from all Chromium browsers and Firefox, while CrUX only covers Chrome users who opted in. So 'my PageSpeed score is low but the store feels fast' and 'my PageSpeed score is 90 but INP is poor' are both possible. Fix what real visitors experience.

Start in the web performance report with the page-type view. If INP is Good on the home page but Poor on product pages, look at what only runs there: variant pickers, image galleries, review widgets, 'frequently bought together' blocks. If collection pages are the problem, look at filters and quick-add buttons.

Next, reproduce it. Open a product page in Chrome, open DevTools and go to the Performance panel. According to Chrome's DevTools documentation, the panel shows your local INP as you interact, lists each captured interaction, and can compare your local numbers with real-user field data. Turn on CPU throttling so your laptop behaves more like a mid-range phone, then record a trace while you repeat the slow interaction.

In the trace, look at the main thread during the interaction and note which script files the long blocks of work come from. Many app scripts load from the app vendor's own domain, which tells you which app to test. For scripts served from Shopify's CDN, check the file path and the Initiator column in the Network tab to work out which app or theme file requested them.

Finally, isolate apps. Duplicate your theme (Online Store > Themes > Duplicate), open the copy in the theme editor, and switch off app embeds one at a time from the App embeds panel. Preview the copy and repeat the same interaction after each change. Remember that a duplicate theme only isolates theme-level code: apps that load through other routes will still run in the preview.

Google's guidance on optimizing INP explains the mechanics. Scripts that are still loading and evaluating create long tasks that delay a shopper's tap. Event handlers that do too much work block the next paint. Very large pages make every re-render more expensive. Most Shopify INP problems are one of these three in a store-specific form.

The table below lists the patterns we check first. They're starting points for your own trace, not a verdict on any particular app.

Shopify's advice is to evaluate every installed app and every piece of third-party code, and keep it only if it creates enough value to offset the performance cost. In practice that means three kinds of fix, in this order.

Less: uninstall apps you don't use, and turn off app embeds that don't need to be on every page. Where an app offers an app block, place it only on the templates that need it. Shopify also recommends auditing your tag manager and removing unused or low-value tags.

Later: anything the shopper doesn't need in the first seconds, such as chat, review carousels and social feeds, can load when it scrolls into view or when someone asks for it. For your own theme code, Google's INP optimization guide recommends doing as little work as possible inside event handlers and yielding to the main thread so the visual update paints before background work continues.

Lighter: smaller pages re-render faster. Shopify recommends not stacking too many sections on a template, and Google notes that rendering work grows as page size grows. If the theme itself is the bottleneck, it may be time to compare theme customization with a custom theme.

When you're choosing a replacement app, the Built for Shopify requirements are a useful filter. As of September 2026 they say an app must not reduce a storefront's Lighthouse performance score by more than ten points, and online store apps must use theme app extensions rather than editing theme files.

Speed apps range from genuinely useful image compression to all-in-one 'booster' tools. The second group has a basic problem: it's another app, with its own script, running on every page.

Some of these tools work by delaying other scripts until the shopper's first scroll or tap. That can raise a Lighthouse score, because the lab test never interacts with the page. But it also moves all that delayed work into the moment a real shopper taps, which is exactly what INP measures.

Stacking two tools that each try to control when scripts load can also cause conflicts, such as scripts running twice or features that never start. If you trial one, test it on a duplicate theme, measure INP with the same interaction script before and after, and then watch Shopify's field data for a few weeks. A better lab score on day one proves very little.

Uninstalling an app doesn't always remove its code. Shopify's help center confirms that some apps add code to your theme that isn't removed automatically. That code can keep loading scripts for a service you no longer pay for.

A quick check: open your storefront with DevTools' Network tab filtered to JavaScript, reload, and list every third-party domain. Any domain you can't match to an app you still use is a lead. Then search your theme code for that app's name. The full procedure, including how to remove it safely, is in our guide to removing leftover Shopify app code.

One date to note: according to Shopify's developer changelog, as of September 2026 Shopify plans to stop injecting legacy storefront script tags on March 1, 2027. Apps that still rely on them will need to move to app embeds or web pixels.

Google's targets for the other two Core Web Vitals are an LCP (Largest Contentful Paint) within 2.5 seconds and a CLS (Cumulative Layout Shift) below 0.1. Shopify's report tracks both next to INP, so check them while you have the trace open.

INP rarely breaks all at once. It creeps up as apps, tags and sections pile on. A short monthly routine catches it early, and it's also a good moment to fix accessibility in the same components; cart drawers and modals show up in both audits, as our Shopify accessibility checklist explains.