How to Improve INP (Interaction to Next Paint) in WordPress

In March 2024, Google replaced First Input Delay with Interaction to Next Paint (INP) as a Core Web Vital — and a lot of WordPress sites that passed the old metric started failing the new one. INP is a tougher, more honest measure of how responsive your site actually feels. This guide explains what it measures, why WordPress struggles with it, and how to improve it.

What INP measures (and how it differs from FID)

INP measures the delay between a user interaction — a click, tap, or key press — and the moment the browser visually responds. Crucially, it looks at all interactions across a visit and reports a value close to the worst one, then measures the full response time, not just the initial delay. First Input Delay only measured the wait before the browser started processing the very first interaction, which made it easy to pass. INP is far harder to fool. The targets: 200 milliseconds or less is good, 200 to 500 needs improvement, and over 500 is poor.

Why WordPress sites have poor INP

INP is almost always a JavaScript problem. When a user interacts, the browser needs the main thread free to respond — but on a typical WordPress site the main thread is busy executing scripts:

• Too many plugins loading JavaScript on every page, each adding event handlers and work.
• Heavy page-builder and theme scripts running on load.
• Third-party scripts — analytics, chat widgets, ad tags, embeds — competing for the main thread.
• Large, unoptimised scripts that take a long time to parse and execute.

While the main thread is occupied, every tap and click waits in line. That wait is your INP.

How to improve INP in WordPress

1. Delay JavaScript until interaction. Hold non-essential scripts — chat widgets, analytics, social embeds — until the user first interacts with the page, so they do not occupy the main thread during the critical early window. This is often the single biggest INP win.
2. Defer non-critical JavaScript. Load scripts that are not needed immediately after the page has rendered, rather than blocking it.
3. Remove unused JavaScript. Stop loading scripts on pages that do not use them — a contact-form script does not need to run on your blog posts.
4. Audit heavy plugins. Identify plugins adding disproportionate JavaScript and replace or remove the worst offenders.
5. Break up long tasks. For custom code, split long-running JavaScript into smaller chunks so the browser can respond to input between them.

The easy path in WordPress

You do not need to hand-edit script loading to make a dent in INP. Easy Optimizer includes delay JavaScript and defer JavaScript controls that hold non-essential scripts until interaction and move the rest out of the render path, plus tools to identify which plugins are loading the most. That directly frees the main thread, which is exactly what INP rewards. After enabling it:

1. Turn on delay and defer for JavaScript, then test your interactive elements — menus, sliders, add-to-cart, forms.
2. Exclude any script that a feature needs immediately (so nothing breaks).
3. Use the analyzer to find the heaviest plugins and decide what to trim.
4. Re-check INP in field data, since responsiveness is measured on real interactions.

A note on measuring INP

INP is best judged on real-user (field) data, because it depends on how actual visitors interact with your pages — a lab test cannot click everything. Check the field data in PageSpeed Insights or your Search Console Core Web Vitals report, and give it a few weeks to reflect your changes. For the full picture alongside LCP and CLS, see Core Web Vitals for WordPress.