Start with field data, not a lab score. Interaction to Next Paint (INP) measures the latency of qualifying interactions across a page visit, and Google's guidance is to keep it at 200 milliseconds or less at the 75th percentile, segmented by mobile and desktop devices. If your filter or add-to-cart interactions sit above that line in field data, reproduce the specific interaction in the lab before changing code.
Why filters and add-to-cart are the usual suspects
INP is a stable Core Web Vital that assesses a page's overall responsiveness by observing the latency of qualifying interactions throughout a visit; the final value is the longest interaction observed, sometimes ignoring outliers (web.dev, Optimize INP). Core Web Vitals currently cover loading (LCP), interactivity (INP) and visual stability (CLS), and INP is the interactivity metric with a 200 ms target (web.dev, Web Vitals).
On a store, two interaction families dominate:
- Filters and facets — a click or tap triggers re-rendering of a product grid, sometimes with sorting, pagination and URL updates.
- Add-to-cart — a click or tap triggers validation, a network request, cart state updates and often a drawer or badge animation.
Both are single interactions that can carry a lot of work. That is exactly the shape INP penalises.
What the field data has to tell you before you touch code
A single INP number for a template is not enough. You need to know which interaction produced it. A Real User Monitoring (RUM) provider can give you the page's INP value plus contextual data: the specific interaction responsible, whether it happened during or after page load, and the interaction type (click, keypress or tap) (web.dev, Optimize INP).
Ask your analytics or RUM setup for these cuts:
- Mobile vs desktop, separately. Google's guidance is to measure at the 75th percentile segmented across mobile and desktop devices (web.dev, Optimize INP). A store that looks fine on desktop can be failing a large share of mobile sessions.
- Interaction target. Group by element or component: filter checkbox, sort control, add-to-cart button, quantity stepper.
- Page type. Category, search results, product detail. A filter problem is usually a category or search problem; an add-to-cart problem is usually a product-page problem.
- Timing. Interactions during load behave differently from interactions after load.
If your tooling cannot name the interaction, that is the first gap to close. Without it you are guessing.
A diagnostic method you can run in one sitting
This is a field-to-lab loop, not a one-off audit.
Step 1 — Set the threshold. Write down 200 ms at the 75th percentile, mobile and desktop separately, as the pass line (web.dev, Optimize INP).
Step 2 — Rank the offenders. From field data, list the interactions above the line, sorted by how many sessions they affect. A slow interaction that almost nobody triggers is a lower priority than a moderately slow one on every product page.
Step 3 — Reproduce in the lab. Open the exact page type on a throttled mobile profile, perform the exact interaction, and record a performance trace. The goal is to see the delay between the input and the next paint.
Step 4 — Classify the delay. For each trace, decide where the time goes:
- Input delay — the main thread was busy before your handler ran.
- Processing time — your event handler itself is heavy.
- Presentation delay — the browser needs time to render the result.
Step 5 — Fix the dominant bucket, then re-measure in the field. Lab traces tell you what to change; field data tells you whether it worked for real users.
Hypothetical example: a filter that feels broken on mobile
The following is an illustrative example, not a real store measurement.
Imagine a category page where field data shows mobile INP at the 75th percentile well above 200 ms, and the RUM breakdown attributes most of it to the "apply filter" interaction. In the lab, a throttled mobile trace shows the handler synchronously re-sorting a large product array, then re-rendering the grid, then updating the URL — all before the next paint.
The classification is processing time. The fix direction is to reduce work in the handler and let the browser paint sooner, rather than to add a spinner and call it solved. A spinner changes perception; it does not change INP.
Hypothetical example: add-to-cart that waits on the network
Also illustrative, not an actual measurement.
Suppose the add-to-cart button shows no immediate state change because the UI waits for the cart API response before painting anything. The trace would show a long gap between the click and the next paint, classified as presentation delay driven by a network dependency.
The fix direction is to paint an immediate acknowledgement of the interaction and reconcile with the server response afterwards. The exact implementation depends on your framework; verify it by re-running the same trace and confirming the next paint arrives earlier.
What to check on filters specifically
- Does the filter re-render the whole grid, or only the changed parts?
- Is sorting or filtering done on the main thread during the interaction?
- Does the URL update block the paint?
- Are images in the grid decoded lazily enough to avoid a burst of work at the moment of filtering?
What to check on add-to-cart specifically
- Does any visual feedback depend on a network round trip?
- Is cart state updated in a way that forces a large re-render?
- Are analytics or tag-manager calls running synchronously in the click handler?
- Does a drawer or modal animate in a way that competes with the paint?
Where this fits in a wider store review
INP work is one part of a store diagnosis. If you are still deciding what to fix first across discovery, content and performance, the checks in Ecommerce SEO audit: the checks that come first give you a prioritisation frame. If the underlying issue is that shoppers cannot find the right category at all, start with Ecommerce SEO: build a store people can actually find.
What the evidence does not settle
INP thresholds and the 75th-percentile, device-segmented measurement approach are documented by Google (web.dev, Optimize INP; web.dev, Web Vitals). What the public documentation does not give you is a store-specific rule for which interaction to fix first, or a guaranteed conversion outcome. Those depend on your own field data, your template architecture and your traffic mix. Treat any claim that a specific INP improvement will produce a specific revenue change as unverified unless you have measured it yourself.
What should I do if my RUM tool cannot identify the slow interaction?
Treat that as a measurement gap, not a dead end. Add interaction-level attribution to your monitoring, or run a controlled lab reproduction of the most likely candidates — filter clicks and add-to-cart taps — on throttled mobile profiles. Compare the traces against the field INP value for the same page type. If the lab cannot reproduce the field delay, the cause may be device or network conditions you are not emulating, which is itself useful information.
Does a good lab score mean my INP is fine?
No. Lab tools measure a controlled run, not your users. INP is defined by real interaction latency across real visits, and Google's guidance is to evaluate it in the field at the 75th percentile, segmented by device (web.dev, Optimize INP). A clean lab trace is a starting point for a fix, not proof that the field problem is solved. Re-check field data after each change.