WordPress INP Optimization: How to Fix a Slow Interaction to Next Paint Score

Your WordPress site loads in under a second, passes every speed test you throw at it, and still feels sluggish the moment someone clicks a button. That gap between “fast” and “feels fast” is INP, short for Interaction to Next Paint, and it’s the Core Web Vital most WordPress sites fail without ever knowing it. WordPress INP optimization isn’t about how quickly a page loads at all. It’s about how quickly the browser responds after a visitor actually touches the page.

What Is INP (Interaction to Next Paint)?

INP measures the time between a visitor’s interaction, a click, a tap, or a key press, and the moment the browser visually updates the screen in response. Google made Interaction to Next Paint an official Core Web Vital in March 2024, replacing First Input Delay (FID), and it has remained a live ranking and user-experience signal through 2026. Unlike FID, which only measured a page’s first interaction, INP tracks every interaction across the entire page visit and reports the worst one.

This is why a WordPress site can pass Largest Contentful Paint (LCP) with flying colors and still feel broken to a real visitor. A dropdown menu that takes a second to open, an “Add to Cart” button that doesn’t respond right away, a mobile menu that lags behind a tap: all of that is INP, and none of it shows up in a basic page load speed test.

What Is a Good INP Score for WordPress?

According to web.dev, an INP of 200 milliseconds or less is rated “good,” between 200 and 500 milliseconds is “needs improvement,” and anything above 500 milliseconds is rated “poor.” Google requires at least 75% of a site’s real visitor page views to fall under that 200ms threshold before the metric counts as passing.

Mobile INP scores tend to run worse than desktop scores on the same WordPress site, simply because mobile CPUs are slower and have less headroom to handle JavaScript competing for the main thread. It’s also worth knowing there are two different kinds of INP data: lab data from a single test run in a tool like PageSpeed Insights, and field data collected from actual visitors through the Chrome UX Report (CrUX). Field data, not lab data, is what Google uses for ranking purposes, so a good lab score doesn’t guarantee a good real-world score.

Why WordPress Sites Struggle With INP

WordPress sites typically fail INP because of JavaScript, not images or server speed. Page builders, sliders, popup plugins, and marketing scripts all add code that runs on the browser’s main thread, and while that thread is busy running scripts, it can’t respond to a visitor’s click. The more plugins loading their own JavaScript on a page, the longer that main thread stays occupied, and the slower the site feels to actually use, even after it has visibly finished loading.

A site running a heavy page builder with a dozen active plugins can easily stack up enough competing JavaScript to push INP well past 500ms on mobile, even while its Lighthouse performance score looks fine. Speed optimization plugins that focus purely on caching and image compression, the kind covered in a typical WordPress speed guide, often leave INP completely untouched, because caching solves load time and INP is a runtime problem.

Common WordPress INP Culprits and Fixes

The table below lists the WordPress-specific causes of poor INP that show up most often, along with the direct fix for each one.

How Do You Fix a Bad INP Score on WordPress?

Fixing INP on WordPress comes down to reducing and delaying JavaScript that runs on the main thread: audit which plugins load scripts, defer or delay the non-critical ones, remove plugins that aren’t earning their weight, and keep any long-running function under the browser’s roughly 50 millisecond task budget. None of this requires touching hosting or a caching plugin, since caching does not address a runtime JavaScript problem.

1. Check the site’s real INP score first in Google Search Console’s Core Web Vitals report before changing anything, so there’s a baseline to compare against.
2. Audit every active plugin for the JavaScript it adds to the front end, and remove or replace any plugin that isn’t actually needed on a given page.
3. Delay third-party scripts like chat widgets, marketing pixels, and heatmap tools so they load only after the visitor’s first interaction, not on initial page load.
4. Disable the WordPress Heartbeat API on the front end and anywhere in wp-admin it isn’t strictly needed, since it adds recurring background work on the main thread.
5. Move hosting to PHP 8.2 or newer if the site is still running an older version, since faster server-side execution reduces the delay before the browser can process a response.
6. Break up any long custom JavaScript functions into smaller pieces so no single task blocks the main thread for more than about 50 milliseconds.

Disabling the Heartbeat API is one of the simplest wins on this list and takes one small snippet in a site’s functions.php file or a custom plugin:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
    wp_deregister_script( 'heartbeat' );
}

This snippet fully removes Heartbeat rather than just throttling its interval, so it’s worth testing on a WordPress staging site first if the site relies on features like post-locking or autosave notices in wp-admin.

Where to Check a WordPress Site’s Real INP Score

The most reliable place to check a WordPress site’s real INP score is the Core Web Vitals report inside Google Search Console, since it uses actual visitor field data rather than a single lab test. PageSpeed Insights is useful for a quick lab-based check while making changes, but Search Console’s field data is what determines whether the site actually passes the metric for ranking purposes.

Anyone who hasn’t already set up Google Search Console for their WordPress site should do that before trying to fix INP, since there’s no way to know whether a fix worked without field data to compare before and after.

Does Caching Fix INP Problems?

Caching does not fix INP on its own, because caching speeds up how fast a page loads, not how the browser’s main thread behaves once a visitor tries to interact with it. A well-configured caching plugin can help indirectly by bundling in features like JavaScript delay or deferral, but the caching layer itself, the part that serves a static HTML snapshot instead of rebuilding the page from PHP, has no effect on INP.

Some caching plugins do include a “delay JavaScript execution” setting that can meaningfully help INP, which is one more reason to compare options carefully. A closer look at how two popular caching plugins handle JavaScript delay and other performance settings is worth reading before assuming a caching plugin alone will solve a bad INP score.

Plugin bloat is the more direct cause of poor INP, and it’s the same root problem behind a lot of unrelated WordPress issues. The same process used to find which plugin is causing a conflict, deactivating plugins one at a time and re-testing, also works for tracking down which plugin’s JavaScript is dragging down INP.

Get Ahead of INP Before It Becomes a Ranking Problem

INP has been an official Core Web Vital since March 2024, which means it already factors into how Google evaluates a page’s experience, not something coming later. A WordPress site with a fast load time and a poor INP score is still failing a metric Google actively measures, so it’s worth checking the Core Web Vitals report in Search Console today rather than waiting for traffic or rankings to make the problem obvious.

Frequently Asked Questions