Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in 2024, and by 2026 it’s the metric quietly failing on a lot of WordPress sites that otherwise look fast. The gap is that INP doesn’t measure how quickly your page appears — it measures how quickly your page responds the moment someone actually clicks, taps, or types, and it reports your single worst interaction of the visit, not an average.
What INP Actually Measures
Every time a visitor interacts with your page, the browser has to process that input and paint the next visual update. INP is the time between the interaction and that paint. Unlike Largest Contentful Paint, which is a one-time loading measurement, INP tracks every interaction across the whole visit and takes the worst one — so a page that loads fast but has one sluggish menu, one laggy filter dropdown, or one janky modal can still fail the metric entirely.
Why WordPress Sites Struggle With This Specifically
| Common Culprit | Why It Hurts INP |
|---|---|
| Heavy page builders (Elementor, Divi) | Deep DOM nesting means the browser has more to recalculate on every interaction |
| Plugin stacking | Each plugin can add its own global event listeners, all of which run on every interaction, whether relevant or not |
| Chat widgets | Frequently among the heaviest main-thread consumers on a page, even when idle |
| Long JavaScript tasks | Any task over 50ms blocks the main thread from responding to new input until it finishes |
What Actually Fixes It
- Break up long tasks. Any JavaScript task running longer than 50ms should be split so it yields back to the browser between chunks, letting a pending click get handled instead of queued behind it.
- Use CSS containment. Applying
containto independent sections of the page tells the browser a change in one section won’t affect layout elsewhere, which speeds up the actual repaint step significantly. - Audit your plugin list for event listener bloat. A plugin that adds a global scroll or click listener for a feature used on one page still runs that listener on every page — remove or scope plugins that do this unnecessarily.
- Replace the heaviest page-builder sections with lean, custom blocks where you can, especially for anything visitors interact with directly (filters, accordions, tabs).
How to Check Your Actual Score
Chrome’s own DevTools Performance panel and the Core Web Vitals report in Search Console both surface real INP data from actual visitors (field data), which matters more than a synthetic lab test — INP is fundamentally about real interaction timing, and lab tools can’t simulate every real click pattern.
This pairs directly with LCP work — if you haven’t already, see fetchpriority: The One-Line Fix That Cuts LCP for the loading-side half of Core Web Vitals. Want your site’s real INP numbers checked? Get in touch.
Frequently Asked Questions
Is INP the same as page load speed?
No — a page can load quickly (good LCP) and still fail INP if any single interaction during the visit responds slowly. They measure different things and need different fixes.
Does a caching plugin fix INP?
Caching plugins primarily help loading metrics like LCP and TTFB. INP is almost entirely about main-thread JavaScript execution during interactions, which caching doesn’t directly address.
What’s a good INP score to aim for?
Google’s “good” threshold is under 200ms; 200–500ms is “needs improvement,” and anything over 500ms is classified “poor.”
Featured image: original illustration.