If your Core Web Vitals assessment failed and INP is the metric glowing red, you're in the right place. INP, or Interaction to Next Paint, is the responsiveness vital that quietly replaced First Input Delay in March 2024, and a lot of WordPress guides still haven't caught up. A high INP makes your site feel laggy after a tap, even when it looks like it loaded fast. This is a tight, WordPress-specific guide: what INP actually is, why yours runs high, and the exact fixes that get it back under 200 milliseconds.
What is INP (Interaction to Next Paint)?
INP, or Interaction to Next Paint, is the Core Web Vitals metric for responsiveness. It measures how long your WordPress page takes to visually respond after a click or tap. It replaced FID in March 2024 and should stay under 200 milliseconds.
Here's the plain version. Every time someone taps a menu, opens a dropdown, adds a product to the cart or clicks a button, the browser has to do some work and then paint the result on screen. INP times that whole journey, from the moment of the tap to the next frame the visitor actually sees. It then takes (roughly) the worst interaction across the visit and reports that as your score. So INP isn't about how fast the page loaded, it's about how snappy it feels once people start using it.
| Rating | INP value | What it feels like |
|---|---|---|
| Good | ≤ 200 ms | Taps feel instant and responsive |
| Needs improvement | 200 to 500 ms | A noticeable lag after each tap |
| Poor | > 500 ms | The site feels broken or frozen |
How is INP different from the old FID metric?
INP measures the full delay of every interaction across a visit, from input to the next painted frame. The old First Input Delay only timed the input delay of the first interaction, so INP is far stricter and catches sluggishness FID never saw.
Did INP replace FID?
Yes. Google retired First Input Delay and made INP an official Core Web Vital on 12 March 2024. The difference matters because FID was easy to pass. It only looked at your very first interaction, and it only measured the input delay, not the processing or rendering that follows. INP looks at all interactions during the visit and counts the whole tap-to-paint round trip. That's why plenty of WordPress sites that breezed past FID are now failing INP without changing a thing. The metric got honest, and bloated sites have nowhere to hide.
Why is your WordPress INP high?
A high WordPress INP almost always comes down to JavaScript competing for the browser's single main thread. Heavy themes, too many plugins, long tasks and third-party scripts all queue work, so when a visitor taps, the browser can't respond until it's done.
- Heavy theme or page builder: bloated builders ship large JavaScript bundles that run on every interaction, clogging the main thread.
- Plugin overload: sliders, popups, chat widgets and form plugins each add scripts that fire on tap, and they don't coordinate with each other.
- Long tasks: any single piece of JavaScript that runs for more than 50ms blocks the browser from responding until it finishes.
- Third-party scripts: analytics, ad networks, tag managers and live-chat tools run code you don't control, often at exactly the wrong moment.
Notice the common thread: it's all JavaScript fighting for one resource. A browser has a single main thread for most of this work, so every script waits in the same queue. The more you pile on, the longer a visitor waits after they tap.
It's worth understanding what a "long task" really is, because it's the heart of the problem. The browser processes JavaScript in chunks, and any chunk that runs for longer than 50 milliseconds is flagged as a long task. While that task runs, the browser literally can't do anything else, including respond to a tap. So if a visitor clicks your menu while a 300ms analytics script is mid-execution, they wait the full 300ms before anything visibly happens. Stack a few of those together and you've got an INP of half a second, even though the page looked perfectly loaded. That's why INP catches sites that pass LCP comfortably: the page painted fast, but it can't keep up once people start interacting.
Mobile makes all of this worse, which is why so many sites pass on a desktop and fail in the field. A phone has a slower processor than your laptop, so the same JavaScript takes longer to run, and the same long task blocks for longer. Since most Australian traffic arrives on mobile, your real INP is usually whatever your audience experiences on a mid-range phone on mobile data, not what you see when you test on a fast machine over fibre. Always judge INP by the field data, not by how snappy your own dev environment feels.
Our Core Web Vitals optimization service diagnoses your INP at the root and fixes it, with a guaranteed green result or your money back.
How do you fix WordPress INP?
Fix WordPress INP by freeing the main thread: remove unused plugins, defer non-critical JavaScript, break up long tasks, lighten the page builder, and load third-party scripts late. Do them in order and re-test INP in the field after each change.
- Remove unused plugins. Every active plugin can queue scripts. Deactivate anything you don't genuinely need and you'll cut main-thread work straight away.
- Defer non-critical JavaScript. Delay scripts that aren't needed for the first interaction so the main thread is free to respond when someone taps. A good optimisation plugin handles this with a delay-until-interaction option.
- Break up long tasks. Find JavaScript that runs longer than 50ms and split or remove it, so the browser can respond between chunks instead of after a single big block.
- Lighten the page builder. Trim what your builder ships per page, or switch to a lighter theme, so there's simply less script to process when a visitor interacts.
- Tame third-party scripts. Load analytics, chat and ad code late or only on interaction, so they don't hog the thread during the critical first seconds.
A quick word on WooCommerce, since stores feel INP problems the hardest. Cart and checkout pages are heavy with JavaScript by nature, and every add-on, payment gateway and live-shipping calculator adds more. If your "add to cart" button feels laggy, that's INP you're feeling, and it costs you sales directly. The same fixes apply, but be extra ruthless about which scripts genuinely need to run on the cart page, and load the rest only where they're actually used.
If you want the wider picture of how INP fits alongside LCP and CLS, our Core Web Vitals guide walks through all three vitals and their 2026 thresholds. INP is the one most modern WordPress sites still fail, so it's worth fixing properly.
How do you check your WordPress INP?
Check your INP with the Core Web Vitals report in Google Search Console for real-visitor field data, then confirm in PageSpeed Insights, which shows INP in both its field and lab sections. The Web Vitals Chrome extension also reports INP live as you click around.
One thing to expect: Search Console runs on a rolling 28-day window of real Chrome users, so after you ship a fix, the field number won't flip green the same day. Use the lab tools to confirm the change worked immediately, then give the field data about four weeks to catch up. Don't panic-refresh the report in the meantime.
Key takeaways
- INP replaced FID on 12 March 2024 and is stricter, so old FID advice is out of date.
- A good INP is 200ms or less, measured on real visitors at the 75th percentile.
- High INP is JavaScript fighting for the main thread, so the fixes all free that thread.
- Confirm fixes in the lab, then wait about 28 days for the field data to update.