Interaction to Next Paint: The New CWV Metric

Interaction to Next Paint (INP) stopped being "the new metric" a while ago. It replaced First Input Delay as a Core Web Vital on March 12, 2024, and FID was fully retired that September. So if you are still tuning your WordPress site for FID, you are optimizing for a metric Google no longer looks at. This guide explains what INP actually measures, why WordPress sites in particular tend to score badly on it, and exactly what to change to fix it.

What INP actually measures

INP measures responsiveness. Specifically, it watches every tap, click, and key press a visitor makes during a page visit, measures how long each one takes to produce a visible response on screen, and reports (roughly) the worst one. It is a field metric: it reflects what real people experienced, not a single synthetic test run.

The thresholds are:

• Good: 200 ms or less
• Needs improvement: 200 ms to 500 ms
• Poor: over 500 ms

The single most useful thing to understand is that every interaction's latency breaks into three parts, and the fix you reach for depends entirely on which part is slow:

1. Input delay — the gap between the user acting and the browser being free to start handling it. This is time the main thread spent busy with something else (usually a long-running script).
2. Processing time — how long your event handlers actually take to run.
3. Presentation delay — the time to recalculate styles, lay out, and paint the next frame so the user sees a result.

On most WordPress sites, the villain is input delay. The browser wanted to respond instantly, but the main thread was tied up parsing and executing JavaScript, so the click sat in a queue.

Why you cannot measure INP in Lighthouse

This trips people up constantly. Open Lighthouse or the lab section of PageSpeed Insights and you will not get a real INP score, because a lab run has no human poking at the page. Lab tools can only estimate responsiveness using Total Blocking Time as a proxy. TBT is a decent early-warning signal, but it is not INP.

To see your real INP, use field data:

• The field/"Discover what your real users are experiencing" section of PageSpeed Insights, which pulls from the Chrome User Experience Report (CrUX).
• Google Search Console's Core Web Vitals report, which groups URLs by status.
• The web-vitals JavaScript library if you want to attribute slow interactions to specific elements yourself.
• DebugBear or similar RUM tools for continuous, per-URL monitoring.

Crucially, the CrUX-based field data only appears once your URLs have enough real Chrome traffic. Low-traffic pages may show no INP at all, which is a reporting gap, not a passing grade.

Why WordPress sites struggle with INP

INP is almost entirely a JavaScript story, and the typical WordPress stack ships a lot of JavaScript. The usual offenders:

• Page builders. Elementor, Divi, and WPBakery each load substantial front-end JS and inflate the DOM. A deeply nested builder layout makes presentation delay worse because every interaction triggers a heavier style and layout pass.
• Third-party scripts. Live chat widgets (Intercom, Tawk.to), Google Tag Manager containers, ad networks, A/B testing tools, and heatmap trackers all run on your main thread and block interactions. These are frequently the biggest single cause of poor INP.
• Plugin sprawl. Each plugin that enqueues its own script on every page compounds the problem, especially sliders, popups, and "mega menu" plugins that attach heavy event listeners.

The pattern is consistent: the page looks finished, the user clicks something, and a long task that has nothing to do with that click makes them wait.

Fixing INP on WordPress, by component

Reduce input delay: get JavaScript off the critical path

The highest-leverage move is to stop loading non-essential scripts until the user actually needs them.

• Delay JavaScript execution. WP Rocket's "Delay JavaScript Execution" and the equivalent in FlyingPress hold off running listed scripts until the first user interaction (scroll, click, key press). Chat widgets, analytics, and ad scripts are ideal candidates — they do not need to run before someone interacts.
• Load scripts per-page, not site-wide. Perfmatters includes a script manager that lets you disable a plugin's CSS and JS on the pages where it is not used. If your contact-form plugin only appears on one page, there is no reason to load it on the blog.
• Use facades for embeds. Replace auto-loading YouTube iframes and live-chat bundles with a lightweight placeholder that only loads the real widget on click. This removes a large chunk of main-thread work from the initial load.

Reduce processing time: break up long tasks

If your own handlers are slow, the browser cannot respond between them. The fix is to yield to the main thread so the browser can paint. The modern API is scheduler.yield() (with a setTimeout(0) fallback for older browsers), which lets a long handler pause, hand control back so the interaction can render, and then resume. For plugin-heavy sites you cannot rewrite, deferring or removing the offending script is usually more practical than patching its internals.

Reduce presentation delay: lighten the DOM

A huge DOM makes every paint expensive. Switching from a page builder to a lightweight, block-based theme — GeneratePress, Kadence, or Blocksy — typically cuts both the script payload and the node count dramatically. If a full rebuild is off the table, at least audit for unused builder widgets, nested containers, and animation libraries you are not using.

A realistic order of operations

You do not need to do everything. Work in this sequence and re-check field data after each release cycle:

1. Open Search Console and identify which URL groups are "poor" or "needs improvement" for INP. Fix the templates behind your highest-traffic groups first.
2. Use the web-vitals library or DebugBear to find which element the slow interaction belongs to — often a menu toggle, an add-to-cart button, or a tab switcher.
3. Delay or remove the third-party scripts that are blocking the main thread. This alone moves most sites from poor to good.
4. Address your own slow handlers and DOM weight only if field data still shows a problem.

Because INP is collected from real users over a 28-day window, do not expect your score to flip overnight after a fix. Give it a few weeks of fresh traffic before you judge whether a change worked, and resist the urge to ship five changes at once — you will not know which one helped. INP rewards the unglamorous work of shipping less JavaScript, and on WordPress that almost always means fewer scripts running before the user touches the page.