Your WordPress site loads in under two seconds. PageSpeed gives you a green LCP — and yet visitors say clicking around feels sluggish. Menus hesitate, buttons lag, forms take a beat to respond.
That’s an INP problem. Interaction to Next Paint measures how quickly your site responds to clicks, taps, and key presses, and since March 2024 it has been one of Google’s three Core Web Vitals. If you want to improve INP in WordPress, you have to look somewhere different from loading speed: not the server, but the browser’s main thread — and everything competing for it while your visitor is trying to click.
What INP actually measures
INP replaced First Input Delay (FID) in March 2024, and it’s a stricter test. FID only measured the delay of the first interaction. INP watches every interaction across the whole page visit — every click, tap, and key press — and reports the near-worst one, measured at the 75th percentile of real users.
Each interaction breaks into three phases: input delay (the browser is busy and can’t start handling your click), processing time (your event handlers run), and presentation delay (the browser repaints). A page that answers the first click instantly but stalls on the third can still score Poor.
Google’s thresholds are the same for mobile and desktop:
| Rating | INP value |
|---|---|
| Good | 200 ms or less |
| Needs improvement | 200–500 ms |
| Poor | More than 500 ms |
A page only passes Core Web Vitals when all three metrics — LCP, INP, and CLS — are Good. One Poor metric fails the set.
Why WordPress sites struggle with INP
WordPress itself isn’t slow — the ecosystem around it usually is. The usual suspects:
- Plugin sprawl. Every active plugin can enqueue its own CSS and JavaScript, and much of it loads on pages that never use it.
- Page builders. Builders like Elementor ship large JavaScript bundles so every widget works everywhere — including pages that use three widgets.
- Third-party scripts. Chat widgets, analytics, heatmaps, ad pixels, social embeds. You don’t control their code quality, and they all run on the same main thread your visitor’s clicks need.
- Heavy event handlers. Sliders, mega menus, and animation libraries that do expensive layout work inside click handlers.
The pattern is always the same: too much JavaScript fighting over one thread at the exact moment the visitor interacts.
Find what’s hurting your INP before you touch anything
Don’t start deleting plugins blindly. Diagnose first:
- Google Search Console → Core Web Vitals report. This is field data from real visitors (the Chrome UX Report, a 28-day rolling window), grouped by page template. If INP is Poor here, that’s the score that counts.
- PageSpeed Insights. Run your worst template’s URL. The field-data section shows your real INP; the diagnostics below point at long tasks and heavy scripts.
- Chrome DevTools → Performance panel. Hit record, click around your page like a visitor would, stop, and open the Interactions track. You’ll see each interaction’s input delay, processing time, and presentation delay — and which one dominates. Long tasks (anything over 50 ms) show up clearly.
One trap to know: Lighthouse doesn’t measure INP directly — it reports Total Blocking Time (TBT) as a lab proxy. TBT correlates with INP but isn’t the same thing. Use lab tools to reproduce problems, and field data to judge whether you fixed them. (Google’s INP documentation explains the metric in full.)
7 practical ways to improve INP in WordPress
1. Delay non-critical JavaScript
Analytics, chat widgets, social pixels, popups, heatmaps — none of these need to run the second the page loads. Delaying them until the visitor’s first interaction (or at least until after the initial render) frees the main thread exactly when people start clicking.
You don’t need to write code for this. WP Rocket’s “Delay JavaScript execution” does it with a few clicks, the free Flying Scripts plugin does something similar with a keyword list, and most serious performance plugins include script deferral options.
Warning: delay the wrong script and things break — sliders, mobile menus, and cookie banners are the usual casualties. Add rules one at a time and click through your key pages after every change.
2. Put third-party scripts on a diet
Record a performance profile in DevTools and look at how much main-thread time belongs to code you didn’t write. Then be ruthless: remove tools you no longer check, load the chat widget only on the contact page, and replace embedded YouTube videos with a click-to-play preview image so the heavy player loads only when someone actually wants the video. Every script you remove can save tens or even hundreds of milliseconds. (This overlaps with general INP guidance for WordPress from across the community — the fix is always less JavaScript, better timed.)
3. Delete plugins you don’t use
Not deactivate — delete. Deactivated plugins don’t run, but they’re still a liability, and as I covered in my WordPress security hardening checklist, outdated code sitting on your server is a risk. Fewer plugins means fewer scripts competing for the main thread. Audit your plugin list quarterly and remove anything without a job.
4. Tame your page builder
If you build with Elementor, dig into its performance settings before assuming you’re stuck: disable widgets you never use, switch on the experiments that improve asset loading, and make sure slider and carousel scripts only load on pages that actually have a slider. And be honest with yourself — if your INP is Poor and a hero slider is the culprit, replacing it with a static hero section is the fix.
5. Don’t starve the scripts that matter
Here’s the mistake that undoes all of the above: delaying interaction-critical JavaScript. Your mobile menu, cart drawer, and form validation need to run the moment someone clicks — delay those and the site feels slower even if lab scores improve. The rule is simple: delay everything the visitor doesn’t interact with, and load what the first click needs early.
6. Keep the DOM lean
Every HTML element costs memory and rendering work, and the bill comes due on your visitor’s phone — especially mid-range Android devices. An excessive DOM size drags down INP noticeably, so avoid stacking page-builder sections and nested containers you don’t need, and audit your templates once a quarter. (Server speed is the other half of a snappy site — my guide to reducing TTFB in WordPress covers that side.)
7. Clean the database and cache aggressively
Months of edits leave post revisions, expired transients, and spam comments behind, and on larger sites leftover autoloaded data quietly adds hundreds of milliseconds to every page build. Run a database cleanup monthly. Pair it with full-page caching and a CDN so repeat visits get served fast — caching won’t fix a bad INP by itself, but it takes the server out of the critical path so the browser can focus on responding to clicks.
How long until your score changes
Set expectations correctly: your DevTools profile improves the moment you deploy a fix, but the Search Console number moves on a 28-day rolling window of real-user data. Make one change at a time, verify it in a lab profile, then watch the field data over the following weeks. INP is the one Core Web Vital you can’t fix with a plugin toggle and a prayer — but every millisecond you shave off is a click that feels instant, and visitors notice that more than any score.
Want this handled for you? I optimize WordPress sites for Core Web Vitals — INP included — so your pages don’t just load fast, they feel fast. Get in touch and I’ll take a look.