Search Console has flagged a group of your mobile pages with “INP issue: longer than 200 ms”. You open one of them on your laptop, click around, and it feels perfectly fine. So what, exactly, is slow?
That gap is the hardest part of learning how to fix poor INP. The problem is real, but it happens on other people’s phones, during interactions you may not think to try. The method below has three moves: find which interaction is slow, work out which phase of it is slow, then match the fix to the cause. If you are not yet sure what INP counts or why it replaced First Input Delay, read what interaction to next paint actually measures first and come back.
Before you start: know what you are aiming at
Google treats INP as good at 200 milliseconds or less at the 75th percentile of visits. It is one of three Core Web Vitals, and the Core Web Vitals overview explains how it sits beside loading and layout stability.
Two things to note before touching anything:
- Which pages? Search Console groups URLs with similar problems. Pick two or three example URLs from the flagged group, ideally different page types: a product page, a category page, a contact page.
- What is the current figure? Record the field INP for those URLs (or the origin, if the URLs lack their own data) from PageSpeed Insights. Field data covers 28 days, so you need a dated starting point to compare against later.
Stage 1: reproduce the slowness on purpose
You cannot fix what you cannot see. Your laptop is probably several times faster than the phones in your field data, so make it slower.
- Open the page in Chrome, open DevTools and go to the Performance panel.
- Turn on CPU throttling (the options slow the processor down several times). Pick a strong slowdown to mimic a mid-range phone.
- Reload the page and start interacting immediately, while it is still settling. Many INP problems happen in the first few seconds, when scripts are starting up.
- Then interact the way a customer would: open the menu, tap a tab, change a product variation, type in search, open the cart, tick a form checkbox.
Recent versions of DevTools show live metrics in the Performance panel, including an interaction log with the INP of each tap. Watch for the one that jumps out.
Better still, borrow a genuinely ordinary Android phone. If the menu takes a visible beat to open on it, you have found something worth recording.
Stage 2: record the slow interaction and read it
Once you know which tap is slow, record a performance trace while doing just that tap. In the trace, find the interaction in the Interactions track and look at what the main thread was doing around it.
The interaction will break down into the three phases INP is made of. Which phase is largest tells you where to look:
| Biggest phase | What it means | Where to look |
|---|---|---|
| Input delay | The page was busy when the tap arrived | Long tasks running at that moment, usually script start-up or a timer |
| Processing time | The code attached to the tap is slow | Event handlers from the theme, a plugin or a third-party tag |
| Presentation delay | Redrawing the page after the tap is expensive | Page size, complex layout, large sections re-rendered |
Long tasks, anything over 50 milliseconds, are marked in the trace. Click one and use the Bottom-Up or Call Tree view to see which script file the time came from. The file name or domain usually gives away the owner: a theme folder, a plugin folder, or a domain belonging to an analytics or ad company.
Stage 3: how to fix poor INP by cause
Long tasks during and after load
This is a typical pattern on small business sites. Every script on the page starts up at roughly the same time, the main thread is jammed for a second or two, and any tap in that window waits.
- Load less on each page. Sliders, form plugins, gallery scripts and builder add-ons often load on every page even where they are not used. A script manager (Perfmatters and similar tools, or the asset controls some caching plugins include) lets you switch them off per page.
- Delay non-essential scripts. Many optimisation plugins can hold back chosen scripts until the first interaction or until the page is idle. Use it for analytics, pixels and widgets, not for the scripts that make your menu or cart work.
- Remove what nobody uses. An old heatmap tool, a pixel from an ad campaign that ended, a second analytics tag doing the same job as the first. Each one is start-up work for nothing.
Third-party tags
Tag managers, ad pixels, A/B testing tools and consent banners are often the heaviest code on a page, and many of them listen to every click. If your trace keeps pointing at domains you do not own, this is your problem. A full audit of them belongs in our post on auditing external scripts. Chat and WhatsApp widgets are a special case because they can be surprisingly heavy for a small button; see how chat widgets weigh down a page.
Slow event handlers
If processing time is the big phase, the code that runs on the tap is doing too much. Typical examples:
- A shop filter that reloads and redraws the whole product grid for each checkbox.
- A variation picker that recalculates price, stock, gallery and shipping estimate all at once.
- A mega menu that builds its entire contents in JavaScript every time it opens.
- Several plugins all reacting to the same “add to cart” click.
The fix here is often developer work: give the visitor visible feedback first (open the menu, show a loading state), then do the heavier work in a following step. Breaking long work into smaller chunks, so the browser gets a chance to paint in between, is the general principle. For off-the-shelf themes and plugins, check whether an update or setting already addresses it before rewriting anything.
A huge page
If presentation delay dominates, the page itself is expensive to redraw. Page-builder layouts with sections inside columns inside sections can produce a very large number of HTML elements. Lighthouse reports an “excessive DOM size” diagnostic that gives a rough count.
- Flatten nested builder sections where you can.
- Cut long pages that try to hold everything: every product, every review, every FAQ open at once.
- Avoid hidden duplicate content, such as separate mobile and desktop versions of the same section both present in the HTML with one hidden by CSS.
WordPress culprits worth checking early
Every site is different, but these are common and easy to test:
- Page-builder add-on packs loading dozens of widget scripts site-wide.
- WooCommerce product pages with gallery zoom, lightbox, variation swatches and upsell popups all loading at once.
- Cookie consent tools that scan the page and block or release scripts on the first click.
- Delay-JavaScript settings applied too broadly, so the first tap triggers every delayed script at the same moment and that tap becomes the slow one.
- Popups and slide-ins with timers that fire long tasks a few seconds after load, right when visitors start tapping.
That fourth one surprises people. Delaying scripts until interaction is a good technique, but if twenty scripts all wake up on the first tap, you have moved the jam rather than cleared it.
Stage 4: check the fix and wait for the field data
After each change, repeat the same throttled test on the same interaction. You want to see the long task gone or shorter, and the interaction’s time fall. Change one thing at a time, so you know which change helped and can undo the one that broke something.
Then, the patient part. Search Console and PageSpeed Insights field data cover the last 28 days, so improvements appear gradually. Once you are confident the fix is live, use “Validate fix” in Search Console’s Core Web Vitals report so Google tracks the group. Keep your dated notes; they are the only way to show cause and effect later.
Responsiveness is only one strand of performance. If you set out to improve interaction to next paint as part of a wider clean-up, the website speed and performance guide shows how it sits alongside server speed, images and caching.
What not to do
- Do not judge INP from a Lighthouse score. Lighthouse cannot measure INP. Total Blocking Time is a hint, not the result.
- Do not remove scripts you do not understand on a live site. Test on a staging copy, and check that forms, cart, checkout and tracking still work afterwards.
- Do not stack optimisation plugins. Two tools both delaying and combining JavaScript will conflict and make the problem harder to trace.
- Do not only test the homepage. INP problems often live on product and form pages where people actually tap.
Frequently asked questions
How long does it take for an INP fix to show in Search Console?
Field data is based on a rolling 28-day window of real visits, so the figure shifts gradually as new visits replace older ones. Expect a few weeks before the change is clearly visible. If you start validation in Search Console, it also monitors the affected URLs over about that period before confirming the fix.
Can a caching plugin fix poor INP?
Not on its own. Page caching makes the HTML arrive faster, which helps loading metrics, but INP is about how much work the browser does after the page arrives. Some caching plugins also include options to delay or remove JavaScript, and those can help, but it is the reduced script work that matters, not the cache.
Is it worth removing Google Tag Manager to improve INP?
Usually the container is not the problem; the tags inside it are. Review what each tag does, remove the ones for finished campaigns or tools nobody checks, and set the rest to fire only where needed. Removing tracking you genuinely rely on to fix a few milliseconds is rarely a good trade.
Why did my INP get worse after enabling delay JavaScript?
Delaying scripts until the first interaction means they all start running at the moment of that first tap. If many scripts are delayed, that tap has to wait for all of them, so it becomes the slowest interaction on the page. Exclude scripts needed for the first interactions, and delay only those that can genuinely wait.
Traced the slow tap to a theme or plugin you would rather not edit? Hand the trace over. Our speed optimisation service for WordPress and WooCommerce works through fixes like these with your approval, then re-tests and shares a before-and-after comparison.
Next in this series: How to Fix Cumulative Layout Shift on Your Site
