Matt Park

Frontend & Web

INP is the ecommerce interaction budget

By 7 minute read

Editorial illustration of a commerce tap delayed across input, processing and paint, while a background LCP pass does not make the control feel ready.

A product listing can pass Largest Contentful Paint and still fail the customer. The grid is visible. What matters next is whether the filter chip, size selector, quantity stepper and pay button respond. When a tap produces no prompt visual feedback, the store feels broken. People call it slow. Often it is Interaction to Next Paint.

INP is the delay from a click, tap or keypress to the next frame the browser can paint. Tags, hydration and interaction handlers compete for the same main thread. The metric is a conversion budget: how long a buyer is allowed to wait for proof that the control worked.

A passing LCP is not a working checkout

Chrome usage data cited in Google’s INP guidance puts about 90% of time on a page after it has loaded. A hero image that paints inside 2.5 seconds can sit on a page whose add-to-bag handler is still queued behind a tag.

INP observes click, tap and keyboard interactions across the life of the page, then reports a value that all — or nearly all — of those interactions were beneath. Scrolling and hovering do not count. A size selector, a filter, a quantity change and a pay control do. Current web.dev guidance defines good INP as 200 milliseconds or less, needs improvement as above 200 up to 500, and poor as above 500, evaluated at the 75th percentile of page views. Those bands can move. Budget the next paint on the journeys that take money. INP is not a Lighthouse badge.

First Input Delay is the wrong souvenir. FID, retired as a Core Web Vital in March 2024, measured only the input delay of the first interaction. A site could look responsive on that first tap and still stall on later filters and checkout steps. INP keeps watching after load, and it includes processing and the wait until the next paint.

The miss concentrates where the catalogue is heavy

HTTP Archive’s 2025 performance chapter found 77% of mobile origins with good INP, and 97% on desktop. Its ecommerce chapter looks calmer still at platform-origin level: mobile good-INP rates of about 90% for Shopify, 88% for WooCommerce, 87% for Magento and 96% for Squarespace Commerce.

A separate May 2026 CrUX analysis of 1.07 million platform-detected ecommerce origins found good mobile INP at 45.3% among the 139 stores in its top-10,000 popularity tier, versus 94.6% in the long tail. Good LCP remained broadly flat across the tiers. Detection was fingerprint-based and the top cohort was small, so treat this as a directional correlation, not proof that popularity caused the gap. A plausible explanation is feature and JavaScript density: larger catalogues, more apps and more tags competing on the same interaction path.

Three places the tap is lost

An interaction is a group of event handlers for one gesture. Its latency has three parts.

Input delay is the wait before any handler starts. The main thread is already busy: a tag, a hydration pass, a recommendation widget, an experiment rewriting the listing after it looked ready. The buyer tapped a filter. The page is still finishing someone else’s work.

Processing duration is the handlers themselves. Variant logic, filter state, analytics beacons and consent checks on the click path all count. async and defer stop a script blocking the parser. They do not make later execution free.

Presentation delay is what happens after the handlers return and before the next frame. Style, layout and paint still have to finish. A handler that returns quickly can still leave a layout the browser cannot show yet.

INP stops at that next paint. It does not wait for the server to confirm the basket, the inventory check or the payment intent. A spinner that paints while add-to-bag silently fails is a product lie, not a win. Budget the acknowledgement and the completion separately.

How you know which script hurt the tap

The Chrome User Experience Report can tell you whether an origin’s INP is good. It cannot name the control, the template or the script. Guessing from a Lighthouse trace is how teams delete the wrong tag. Total Blocking Time is a lab proxy, not a substitute for field INP.

Field measurement needs the phases, not a single millisecond. Google’s web-vitals attribution build can report the interaction target, the gesture, input delay, processing duration, presentation delay and the load state. That stops the diagnosis collapsing into “JavaScript”.

Long Animation Frames, shipped in Chrome 123, can expose scripts contributing more than five milliseconds to a frame delayed beyond 50 milliseconds. A LoAF entry can include the source URL, invoker type, function name where available and timing data. In Chromium, the web-vitals attribution build can associate relevant LoAF entries with the INP interaction. Rank attributable work rather than arguing from a vendor dashboard.

LoAF remains Chromium-only. It provides script attribution for work on the page’s main thread, including same-origin iframes, but not cross-origin iframes, workers, service workers or extension code running in isolated worlds. A no-CORS cross-origin script may expose only its source URL; fuller detail requires a CORS-enabled request such as crossorigin="anonymous" with compatible response headers. An empty scripts array can also indicate rendering work rather than JavaScript. Missing attribution is a boundary, not innocence.

Event Timing became Baseline Newly available with Safari 26.2 in December 2025, so first-party RUM can now include supporting WebKit sessions. CrUX remains Chrome-only, and browser engines have small differences around paint and presentation timing. Segment first-party RUM by browser and do not present a blended cross-browser number as though it were the CrUX value.

For pages with many interactions, INP ignores one extreme interaction for every 50 interactions. Preserve per-target diagnostic traces alongside page-level INP so the aggregation rule does not hide a painful control.

What leaders should budget

A performance budget that is only an origin Core Web Vitals pass will be gamed, because that is the number visible in Search Console. The useful budget is a journey budget:

A budget needs four things: a scoped journey, a percentile threshold, a named owner and an agreed response when it regresses. Without the response, it is monitoring.

  • the 75th-percentile INP by template — listing, product, basket, checkout — on mobile, not a site-wide rollup;
  • the interaction target that produced the slow visits — filter, variant, quantity, pay;
  • the phase split, so a processing problem is not staffed as a loading problem;
  • the observation window and sample count behind every slice, so low-volume checkout interactions are not mistaken for stable trends;
  • an accountable owner for every script or integration on the journey, including containers and third-party tags that LoAF cannot attribute precisely.

What you measure becomes the behaviour. Do not delete instrumentation to flatter the score, and do not insert an empty paint so a handler looks finished before it has committed the action. If a tag cannot be attributed precisely, restrict where it runs unless its owner can justify and test its cost. Who may add a script still belongs with the people who own the commercial outcome.

INP connects script ownership to peak readiness

Third-party scripts are still an ownership problem: who can introduce main-thread cost, and who can remove it. Peak season is still a readiness calendar. Ecommerce INP is the field evidence between them. LCP can pass. Checkout can still feel broken. The tap is where the store either keeps the buyer or teaches them the control does not work.

Currency note: figures and browser support here reflect sources available as of 12 September 2026. The bands can move. Budgeting the next paint, and attributing the miss, should not.

Sources and further reading