Interaction to Next Paint: 6 Proven INP Fixes for Stores

Google measures how quickly your site responds when a visitor taps, clicks or types. The metric is called Interaction to Next Paint, or INP, and it is one of the Core Web Vitals. A store with a slow INP feels sticky: buttons seem to ignore the first tap, filters lag and the cart updates late.

This guide explains Interaction to Next Paint in plain language, what Google considers a good score, and six proven fixes you can ask your developer to apply. It follows the official web.dev guidance, so every step is one Google itself recommends.

What Interaction to Next Paint measures

Per web.dev’s INP guide, INP reports how long the page takes to respond to user interactions. The reported value is the longest interaction observed, in some cases ignoring outliers. The thresholds are:

• Good: 200 milliseconds or less.
• Needs improvement: between 200 and 500 milliseconds.
• Poor: more than 500 milliseconds.

Google evaluates the 75th percentile of page loads, split across mobile and desktop. That means three in four visits should meet the target, so one fast laptop test is not enough.

What a slow interaction feels like to a customer

INP can sound abstract, so imagine a shopper on a mid-range phone. They open a category page, tap a filter and nothing happens for half a second. They tap again and the page suddenly applies the filter twice. Later they select a size on a product page and the price takes a moment to update. At checkout, the coupon button seems to ignore them.

None of these moments crashes the site, and each looks minor on a report. Together they add up to a feeling that the store is unreliable, and unreliable stores lose sales. INP is Google’s way of putting a number on that feeling, which is why it deserves a place on your list even if page load looks fine.

Why stores struggle with INP

Online stores run a lot of interactive code: product filters, variation selectors, mini carts, popups, chat widgets, analytics and marketing tags. Every script competes for the browser’s main thread, the single lane where clicks are handled. When it is busy, a tap waits.

Six proven fixes

Fix 1: Start with real-user data

web.dev recommends starting with field data from a real user monitoring provider, which shows which interactions are slow. Without one, use Chrome UX Report data in PageSpeed Insights for a summary, then reproduce slow interactions in the lab by following common user flows. Test interactions during page load too, when the main thread is busiest.

Fix 2: Find which phase is slow

Every interaction has three parts: input delay (before handlers start), processing duration (the handlers themselves) and presentation delay (until the next frame is painted). Fixing the wrong phase wastes time, so measure first.

Fix 3: Reduce long tasks

Long tasks block the main thread. During start-up, script parsing, compiling and running can hold up input. Remove scripts you do not need, defer non-critical ones and split large bundles.

Fix 4: Yield to the main thread

Developers can break long work into smaller tasks, for example with setTimeout, so the browser can handle input between them. web.dev notes that even indiscriminate yielding beats none. Run only what is needed for the visual update before the next frame, and defer the rest.

Fix 5: Avoid layout thrashing

Reading layout values right after changing styles forces the browser to recalculate layout immediately. Batch reads and writes together so layout work happens once.

Fix 6: Keep the page small

Large DOMs make rendering slower on load and during interactions. Flatten the structure, add elements as needed and consider content-visibility for off-screen content. Be careful with client-side HTML rendering, since the browser cannot yield until it has parsed and rendered it.

Common scripts that hurt INP on stores

The web.dev guidance is general, so here is how it tends to appear on an online store. These are practical observations, not a Google list:

• Chat widgets and pop-ups that start heavy scripts on load.
• Tag managers loading many marketing and analytics tags at once.
• Review and wishlist widgets that attach handlers to every product on a long category page.
• Product filters that rebuild the whole list on each click.
• Sliders and animation libraries running on the main thread while a visitor is trying to tap.

You do not need to remove them all. Ask which ones earn their keep, load the rest later or only on pages that need them, and test again. Often two or three scripts account for most of the delay.

What to do in WordPress and WooCommerce

web.dev’s article is about general techniques and does not cover WordPress, so treat these as practical applications of it. List the scripts each plugin loads and remove those you do not use. Test product filters, variation dropdowns and the mini cart on a mid-range phone. Avoid page builders that produce very large pages on product and checkout templates. Our speed optimisation guide for WooCommerce covers caching and plugin audits that help here.

Where INP problems usually appear in a store

Not every page is equally at risk. Pages with the most interactive elements tend to have the highest INP:

• Category pages with filters, sorting and infinite scroll or “load more” buttons.
• Product pages with variation selectors, galleries, zoom and tabs.
• The cart and checkout, where coupons, shipping options and payment methods change the page on each step.
• The header, with mega menus, search suggestions and the mini cart, which exist on every page.

Because the header and shared scripts load everywhere, a single heavy script there can hurt every URL on the site. Start with those shared parts, then move to the templates with the worst results in your report.

Reading your Core Web Vitals report

Google Search Console groups URLs into good, needs improvement and poor for each Core Web Vitals metric. Start with the poor group for mobile, since most shoppers browse on phones. Click into a group to see which templates are affected, such as product pages or the cart. Fixing one template often fixes hundreds of URLs, because they share the same scripts.

Remember that field data lags behind your changes, because it is collected over time. After you deploy a fix, expect to wait before the report improves, and confirm the change with your own testing in the meantime.

Questions to ask your developer

• What is our INP on mobile and desktop, from real users?
• Which interactions are the slowest, and which phase is slow?
• Which scripts from plugins or tags run on those pages?
• Can any of them be removed, deferred or loaded only where needed?
• How will we know the fix worked?

How to measure progress

Re-test the same flows after each change, and judge by field data over several weeks, because it reflects real visitors. Record INP on mobile and desktop separately. A fix that helps a laptop may not help a phone.

A one-week INP improvement plan

Small, regular steps work better than a single big project. A realistic week looks like this:

1. Day 1: read your Core Web Vitals report and note the worst mobile templates.
2. Day 2: record real interactions on those pages with the browser’s performance tools, and identify the slow phase.
3. Day 3: list every script on the page and mark each one keep, defer or remove.
4. Day 4: apply the safest changes first, such as deferring a widget or removing an unused plugin script.
5. Day 5: re-test on a mid-range phone, compare, and write down the result.

Repeat the loop the following week with the next worst template. After a month most stores see clear progress, and the notes you keep make the next round faster.

A short INP checklist

• Field data reviewed for mobile and desktop.
• Slowest interactions reproduced in the lab.
• Slow phase identified: input delay, processing or presentation.
• Unneeded scripts removed or deferred.
• Long handlers split into smaller tasks.
• Large DOM sections simplified.

Our WordPress and React teams can run an INP audit and fix what is slowing your store.

Does INP affect search rankings?

Google lists Core Web Vitals, including INP, among the signals used by its page experience systems. It is one signal among many, and great content still matters more. Treat INP as a quality measure for your customers first. A store that responds quickly feels better to use, and that tends to help conversions regardless of any ranking effect.

Free tools worth knowing

You do not need an expensive tool to start. Google’s PageSpeed Insights shows field data where enough visitors exist. Search Console reports Core Web Vitals by group of URLs. Chrome DevTools has a performance panel that records interactions and shows long tasks, and it labels input delay, processing time and presentation delay for each interaction. Together they cover measuring, finding and checking a fix, which is all most stores need. Add real user monitoring later if you want continuous data across devices and countries.

A realistic expectation for results

INP rarely improves with a single change. Most stores see gradual progress: removing a heavy script helps, splitting a long handler helps again, simplifying a template helps a little more. Expect to measure over weeks, since field data builds slowly, and expect some pages to stay slower than others because of what they must do.

Do not chase a perfect number on every page. Aim to get your most visited and most valuable templates into the good range first, hold them there with a short test after every release, and treat new plugins and tracking tags as suspects when a score slips. That steady approach protects both customer experience and your time.

Frequently Asked Questions