You click a menu, an accordion, an “Add to cart” button, and for a beat nothing happens. The page isn’t frozen. It just feels sticky. That stickiness has an official name, and Google measures it on every visit: Interaction to Next Paint (INP).
INP is one of the three Core Web Vitals, and it has been one since March 12, 2024, when it officially replaced First Input Delay (FID). Where FID only judged the very first thing a visitor did on your page, INP watches every click, tap, and key press for the entire visit and reports on the slowest of them.
The good news: most INP problems trace back to a handful of usual suspects (plugin JavaScript, page builder bundles, third party tags), and finding them doesn’t require a performance engineering degree.
This guide walks through what INP measures in plain words, how to measure yours before touching anything, and the WordPress fixes ranked by typical impact. Let’s jump right in! 👉
What INP actually measures (in plain words)
INP stands for Interaction to Next Paint. In plain words, it’s the time between a visitor doing something (clicking a button, tapping a link, pressing a key) and the browser painting the next frame on the screen. The menu opening, the cart updating, the form field reacting. If that next paint takes too long, the site feels broken even when it technically isn’t.
A few things make INP different from older metrics:
- It watches the whole visit, not just the load. Google’s own usage data shows people spend 90% of their time on a page after it loads, so a metric that only checks the first impression misses most of the experience.
- It reports your worst typical interaction. INP observes every interaction and lands on roughly the slowest one (a small number of genuine outliers get tossed). The final score is then taken at the 75th percentile of real visits.
- It covers the full interaction. Every interaction has three phases: input delay (the browser was busy doing something else when the visitor clicked), processing time (running the JavaScript that the click triggered), and presentation delay (actually drawing the result). INP measures all three.
- Only real inputs count: clicks, taps, and key presses. Scrolling and hovering don’t.
The scoring lines are simple: 📏
- 🟢 200 ms or less: good responsiveness.
- 🟡 200 to 500 ms: needs improvement.
- 🔴 Over 500 ms: poor.
INP vs FID vs LCP: the 60 second distinction
These three get mixed up constantly, so here’s the clean version:
| Metric | What it measures | Good score |
|---|---|---|
| FID (First Input Delay) | Only the input delay of the very first interaction. A load responsiveness check, nothing more. | Retired (replaced by INP in March 2024) |
| INP (Interaction to Next Paint) | The full duration of essentially every interaction across the whole visit, from input to the next painted frame. | 200 ms or less |
| LCP (Largest Contentful Paint) | Loading, not interactivity: how long the largest visible element takes to render. | 2.5 s or less |
FID was easy to pass by accident: nail the first click and it would never notice a sluggish rest of visit. INP exists because Google wanted the whole story. LCP, meanwhile, answers a completely different question (did the page show up fast?), which is why image optimization helps LCP but does almost nothing for INP. And if a lazy loaded LCP image is your headache instead, there’s a dedicated fix guide on the blog.
This article stays laser focused on INP. For the full picture of all three Core Web Vitals, including CLS and how they affect rankings, check the complete Google Core Web Vitals guide.
Step 1: Measure your INP before changing anything
Resist the urge to start uninstalling things. INP is a field metric, meaning it’s calculated from real visitors on real devices, so the first job is finding out whether you have a problem at all and where it lives.
Start with PageSpeed Insights. Paste your URL, run the test, and look at the “Core Web Vitals Assessment” at the top. That section is field data from the Chrome User Experience Report (CrUX), the official Web Vitals dataset, taken at the 75th percentile of real visits over the trailing 28 days. Here’s this very blog as an example: 👇
INP of 194 ms: passing, but with no room for complacency. If your own URLs land in the yellow or red, keep reading.
ℹ️ NOTE: New or low traffic sites often show “not enough usage data” instead of a score, because CrUX needs a minimum number of real Chrome visitors. Sometimes you get origin level data instead of page level. If neither exists, use the lab approach below and re-check as traffic grows.
Field data tells you that you’re slow. Chrome DevTools tells you why. Open your page in Chrome, then:
- Open DevTools and go to the Performance tab.
- Hit Record, then use your page the way a visitor would: open the mobile menu, run a search, add something to the cart, click a filter.
- Stop the recording and look at the Main thread track.
What you’re hunting for are long tasks: any task that keeps the main thread busy for more than 50 ms. DevTools marks them with a red triangle in the corner and a red striped portion. While a long task runs, your visitor’s click just sits in line waiting, and that wait is exactly what INP measures. The Bottom-up or Summary views at the bottom break down main thread time by first and third party, which is where the culprits get named: 👇
The Performance panel docs have the full tour, and the Search Console Core Web Vitals report gives you the site wide view, grouping URLs that share the same problem.
💡 PRO TIP: Lab tools can’t capture INP on their own because nothing interacts with the page during a lab test. If you have no field data yet, use Total Blocking Time (TBT) from the Lighthouse lab report as a stand in. It’s not a replacement for INP, but a high TBT almost always means INP trouble is coming.
Step 2: Fix the usual WordPress suspects (ranked by impact) 🔧
Almost everything that hurts INP on a WordPress site is JavaScript competing for the main thread. These fixes are ordered by where WordPress sites typically get the biggest wins first, not by how fun they are.
1. Audit your plugin bloat
Every active plugin can add JavaScript to every page, even pages where it does nothing. That contact form plugin from 2023? Its scripts may well load on all 400 of your posts. Go to Plugins → Installed Plugins and deactivate (then delete) anything that isn’t earning its keep. Where possible, prefer plugins that only load assets on the pages that actually use them.
Test on staging if you have one, and re-check INP after the cleanup to see what each removal bought you. 📉
2. Delay or defer non-critical JavaScript
Analytics, popups, chat widgets, and social pixels don’t need to run the second the page loads. Delaying them until the visitor first interacts (or at least deferring them until after the initial render) frees the main thread right when visitors start clicking.
You don’t need to write code for this. WP Rocket (premium) has a Delay JavaScript execution feature, and Flying Scripts (free) does a similar job with a simple keyword rule list. Most serious performance plugins offer script deferral too.
🆘 POSSIBLE ISSUE: Delaying the wrong script breaks things. Sliders, menus, and cookie banners are frequent casualties. Add rules one at a time and click through your key pages after each change. Boring, but faster than debugging a pile at once.
3. Tame page builder and slider scripts
Page builders and slider plugins are frequent INP offenders because they ship large JavaScript bundles, often on every URL of the site. Many builders include performance settings to unload unused widgets or load assets only where they’re used, so dig through those options before assuming you’re stuck. And if a slider appears on exactly one page, it has no business loading sitewide.
The blunt truth: if your INP is poor and a hero slider is the culprit, replacing it with a static hero section is the fix. Nobody has ever mourned a slider. 🪦
4. Put third party tags on a diet
Chat widgets, heatmaps, A/B testing tools, social pixels: each one adds main thread work, and you have zero control over the code quality. The DevTools third party breakdown from Step 1 tells you precisely who’s eating what. Remove the ones you don’t actively use (be ruthless, “might want it someday” is not a use case), and delay the survivors per fix number 2.
5. Remember that hosting is context, not the fix
INP happens in the browser, not on your server, so a faster host won’t directly improve it. Time to First Byte isn’t part of the INP calculation. That said, a slow server delays everything, including the moment the main thread finally calms down enough to respond quickly to early interactions. If your TTFB is also bad, fix it as part of your broader speed work (this WordPress speed guide covers that side). Just don’t expect a hosting upgrade to rescue a JavaScript problem.
What you can’t fix (and what to do instead)
Time for some honesty, because plenty of INP advice pretends everything is tunable. It isn’t. 🤷
Third party embeds you actually need. Support chat, payment forms, embedded videos and maps run their own JavaScript on your page, and interactions inside their iframes (like pressing play on an embedded video) count toward your INP. Your visitors can’t tell whose code made things slow, and neither can the metric. You cannot optimize someone else’s code. What you can do is control when it loads: click to load facades for video, chat widgets that initialize after first interaction, maps that render as a static image until touched.
Ads. If you monetize with display ads, ad scripts are often the heaviest thing on the page, with bidders and refreshes working the main thread all session long. There are ad tech settings that help at the margins, but sometimes the honest fix is removing a placement or a feature, not tuning it. Treat INP as a cost and benefit conversation: every script on the page should pay rent.
Cheap phones. Remember that the 75th percentile includes visitors on budget Android devices with a fraction of your MacBook’s power. When you record in DevTools, turn on CPU throttling in the Performance panel to get closer to what those visitors experience.
Wrapping up 🏁
INP boils down to a simple promise: when a visitor does something, something visible should happen fast. The playbook, in order:
- 📊 Measure first with PageSpeed Insights field data, and hunt long tasks in the DevTools Performance panel before changing anything.
- 🧹 Cut JavaScript at the source: plugin audit, then delay or defer whatever remains non-critical.
- 🏗️ Confront the heavy bundles: page builder and slider scripts, then third party tags.
- ⚖️ Accept the ceilings: embeds and ads you keep can be deferred or facade loaded, and sometimes the right fix is removal.
Do those in order and the 200 ms line stops looking scary. Your visitors won’t send a thank you note, but they’ll click around without friction, and Google will notice.
What’s the worst INP offender you’ve uncovered on your own site? Let us know in the comments section below! 👇
FREE GUIDE
4 Essential Steps to Speed Up Your WordPress Website
Follow the simple steps in our 4-part mini series and reduce your loading times by 50-80%. 🚀
