ShieldThemes Web Development
+1 (415) 555-0142 Get a quote →
← Journal/Performance

INP in practice: fixing the metric that fails most stores

Real traces from five client sites and the fixes that moved them into the green.

Maya Okafor
Maya Okafor
Head of Engineering · Aug 09, 2026 · 5 min read
INP in practice: fixing the metric that fails most stores

Interaction to Next Paint replaced First Input Delay as a Core Web Vital, and it changed which sites pass. FID only measured the delay before the browser started handling the first interaction. INP measures the full time from a tap or click to the next frame painted, across every interaction on the page, and reports roughly the worst one. Sites that sailed through FID now fail INP on mobile, and e-commerce stores fail it more than most. Over the last year we have traced INP problems on five client sites, a mix of Shopify, WordPress and custom React builds. The causes were less varied than you might expect, and so were the fixes.

Start with field data, not Lighthouse

INP is a field metric. It depends on real users, real devices and real interactions, so a lab score is at best a hint. We begin with three sources:

  • The Chrome UX Report through Search Console or PageSpeed Insights, to see the 75th percentile INP by page group and whether the origin passes.
  • Real user monitoring with attribution, using the web-vitals library's attribution build or a RUM product, so each slow interaction is recorded with its target element, event type and the breakdown into input delay, processing time and presentation delay.
  • Chrome DevTools performance traces recorded on a mid-range Android device or with 4x CPU throttling, reproducing the interactions RUM flagged.

Attribution is the critical piece. Without it you know INP is 450 milliseconds; with it you know that the slowest interactions are taps on the variant selector on product pages, and that most of the time is input delay caused by something else running on the main thread.

INP rarely has one cause. It has a queue of small costs that all happen to be standing in line when the customer taps.

It also helps to know which interactions count. INP considers clicks, taps and key presses, but not scrolling or hovering. On stores, the usual suspects are add-to-cart buttons, variant pickers, filter checkboxes, menu toggles and accordion headers on product pages. On content sites, it is often the navigation menu and cookie banner. Knowing the list narrows the investigation before a single trace is recorded, and it tells you which components deserve a performance review whenever they change.

What the traces showed

Across the five sites, the slow interactions fell into four patterns.

  1. Third-party scripts blocking input. On two stores, chat widgets, review carousels and a personalization script were executing long tasks during the first seconds after load, exactly when users started tapping. Input delay made up more than half of the INP value.
  2. Expensive event handlers. A variant selector on a Shopify theme re-rendered the entire product form, recalculated prices for every variant and updated the URL, all synchronously. Processing time alone was around 280 milliseconds on a mid-range phone.
  3. Hydration and re-rendering. A React storefront re-rendered a large product grid on every filter change, including components whose props had not changed.
  4. Layout thrashing. A WordPress mega menu read element dimensions and wrote styles in a loop on open, forcing repeated layout calculations and a long presentation delay.

The fixes that moved the numbers

None of the fixes were exotic. What mattered was applying them to the specific interactions that attribution identified.

Yield to the main thread

The single most effective change was splitting long handlers so the browser can paint a response before finishing the work. Update the visible state first, then defer the rest.

button.addEventListener('click', async () => {
  showSelectedState(button);           // cheap, visible feedback
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0));
  updatePricesAndInventory();          // heavier work after paint
  syncUrlAndAnalytics();
});

On the variant selector, this dropped INP on product pages from around 420 milliseconds to under 180 at the 75th percentile, without changing what the feature did.

Delay third parties until they are needed

Chat widgets were loaded on first interaction with a lightweight placeholder button, and review widgets were loaded when scrolled near the viewport. Tag manager triggers that fired on page load were audited, and several were moved to fire after the window load event or removed entirely.

Render less

On the React build, memoizing grid items, virtualizing long lists and wrapping filter updates in a transition so urgent updates could interrupt them brought filter interactions from roughly 600 milliseconds to around 150.

Batch DOM reads and writes

For the mega menu, we measured once, then wrote styles once, and replaced JavaScript-driven animation with CSS transitions. Presentation delay fell by more than two thirds.

Results across the five sites

Four of the five sites moved their origin-level INP into the good range, under 200 milliseconds at the 75th percentile, within one 28-day CrUX window after the fixes shipped. The fifth improved from poor to needs improvement; its remaining issue is a third-party checkout widget the client has chosen to keep. Two stores saw measurable improvements in mobile conversion on product pages, though as always we treat that as correlation until it holds for more than one season.

The broader lesson is that INP rewards discipline more than cleverness. Keep handlers small, give feedback immediately, and be ruthless about what runs on the main thread during the first seconds of a page's life.

Keeping INP in the green

Fixes decay as sites grow. We leave clients with RUM dashboards segmented by template and device, alerts when the 75th percentile crosses 200 milliseconds, and a review step for any new third-party script. Our Core Web Vitals optimization engagements include this monitoring setup, and for Shopify stores the work runs through store speed tuning. WordPress sites get the same treatment as part of WordPress speed optimization.

Failing INP on your own site?

If Search Console is flagging INP and you are not sure where to start, send us the affected URLs. Ask for a fixed-price quote and we will reply within 24 hours with a scoped plan.

Maya Okafor
WRITTEN BY
Maya Okafor
Maya leads engineering at ShieldThemes. She has shipped more than 120 WordPress and Laravel platforms and writes about architecture that survives its second year.
All articles by Maya Okafor →
Want this on your project?
Get a fixed-price quote from a senior lead within 24 hours.
Request a quote →

Keep reading

How we shipped a support agent that resolves 62% of tickets
AI · 5 min
How we shipped a support agent that resolves 62% of tickets
What to learn in the two weeks before a website redesign
Design · 5 min
What to learn in the two weeks before a website redesign
Migrating to Shopify Plus without losing a single ranking
Shopify · 5 min
Migrating to Shopify Plus without losing a single ranking