During our quarterly performance review this month, I pulled up a batch of sites flagged for closer monitoring. The pattern was the same across half a dozen accounts. I have been seeing it with increasing frequency over the past year.

LCP: good. CLS: good. INP: needs improvement, or outright poor.

One of those sites belonged to a solicitor's practice in Sligo. Professional-looking, fast page loads, no obvious breakdowns when you browse it manually. When I cross-referenced their Core Web Vitals data against the organic search performance they had shared with us, the story was different. Search impressions down since mid-2024. Not dramatically. Gradually. The kind of quiet erosion that business owners routinely attribute to algorithm noise or seasonal variation, because they do not know what else to blame it on.

The cause was INP. And the owner had no idea the metric existed.

What Changed in March 2024

On 12 March 2024, Google retired FID (First Input Delay) and replaced it with INP (Interaction to Next Paint) as an official Core Web Vitals ranking signal ^[1]. Google had been announcing the transition for two years before it happened. But the practical impact on WordPress sites landed harder than many business owners have yet registered.

FID measured one interaction: the very first input a visitor made on the page, and specifically the delay before the browser began processing it. The bar was relatively easy to clear because that first interaction often happened before the page's JavaScript had fully loaded. An early click on an unresponsive page would register as fast because the scripts responsible for slowness had not yet executed.

INP measures something fundamentally different ^[2]. Every click, every form submission, every mobile menu tap, every keystroke in a search box throughout the entire session. The metric captures the worst interaction time and uses that as the score. The threshold is strict: 200 milliseconds or under is good. Between 200ms and 500ms needs improvement. Above 500ms is a failing score.

INP sits alongside LCP and CLS as one of the three Core Web Vitals signals that feed into Google's page experience assessment. For a fuller picture of how these metrics relate to each other and what they mean for your site's overall performance health, our complete WordPress performance guide for business owners covers the full stack in plain terms.

Why INP Is Harder to Pass Than FID Was

The practical problem is that INP exposes JavaScript execution delays that FID completely ignored. FID was measured before most of your page's scripts had a chance to cause problems. INP is measured while those scripts are running.

If your site is loading a popular theme builder, a cookie consent plugin, a live chat widget, a booking system script, a Google Analytics implementation, and a social sharing toolbar (which describes a large proportion of small business WordPress sites), every one of those scripts registers event listeners that compete for the browser's main thread. When a visitor taps your mobile menu at the moment several of those scripts are executing simultaneously, the browser cannot respond immediately. INP records that delay.

I will be honest about something here. When INP became a ranking signal in March 2024, our own monitoring dashboards were still surfacing FID data in some views for several weeks before we caught it and updated the reports. That is precisely why INP tracking is now a standing item in every quarterly performance review we run.

What a Failing INP Score Actually Costs

It costs rankings. Core Web Vitals are a confirmed Google ranking signal, and INP contributes directly to the page experience assessment ^[4]. These signals function as tiebreakers at scale. In competitive local searches, when two businesses are competing for the same organic position and their content quality and authority are roughly matched, performance becomes the differentiating factor. The site with better Core Web Vitals tends to hold the better position.

The data on Core Web Vitals passage rates across Irish WordPress sites makes for uncomfortable reading. The mobile performance gap is larger than most business owners expect, and INP is a significant contributor to those failures. According to HTTP Archive's Web Almanac 2025 ^[3], roughly half of all websites are still failing at least one Core Web Vitals metric on mobile. WordPress installations running multiple plugins and third-party scripts are disproportionately represented in that failing half.

There is also a cost that never shows up in a Search Console dashboard. A site that takes 400 milliseconds to respond to a tap feels slightly slow. The visitor will not diagnose it as an INP problem. They will feel a vague friction, something slightly off, something not quite right, and that feeling shapes whether they call or quietly look elsewhere. The conversion loss from that friction is real. It simply does not come with a label.

INP measures every interaction throughout a session, not just the first click

What Infrastructure Can Fix, and What It Cannot

Server response time is a genuine contributor to INP. When a visitor interaction triggers a server request (a search, a form submission, a dynamic product lookup), the latency of that server response shows up directly in the interaction measurement. A server that takes 800 milliseconds to respond is starting your INP count from 800ms before the browser has even begun rendering the result.

On a properly configured managed hosting stack, server-side INP contributions drop to near-zero for production pages that are appropriately cached:

Nginx serves cached pages without invoking PHP at all
Redis object caching handles dynamic lookups in single-digit milliseconds
FastCGI page caching returns full page responses before database queries are needed

Web60's enterprise-grade WordPress infrastructure is built around exactly this performance profile: Nginx, PHP-FPM, Redis object caching, and FastCGI page caching working together to minimise the server-side window that contributes to INP.

But here is the honest part. If your site is loading 1.5MB of unminified JavaScript from a premium theme builder, or running eight active plugins that each register their own input event listeners, no server configuration resolves that. The delay is happening in the visitor's browser. The browser's main thread is occupied processing your JavaScript at the moment the visitor tries to interact. That is a JavaScript problem and it requires a JavaScript solution.

For sites running complex interactive functionality (multi-step booking systems, heavily customised WooCommerce checkouts built on stacked plugins, or page builder layouts with multiple animated sections), infrastructure optimisation is still worthwhile. But the honest recommendation is that a developer auditing and optimising the JavaScript will move the needle further than any hosting upgrade alone. No hosting provider, regardless of how well their stack is configured, will fix client-side JavaScript that is blocking the main thread. Know the difference before you spend time or money on the wrong fix.

Checking Your Own INP Score

Open Google Search Console and navigate to the Core Web Vitals report. The data is segmented by mobile and desktop, and by URL group across your production pages. If INP is showing as poor or needs improvement across a significant portion of your pages, you have a confirmed ranking factor working against you.

PageSpeed Insights ^[2] provides INP data for individual URLs if you want to diagnose specific pages rather than wait for aggregated Search Console data. Enter your homepage URL, scroll to the Core Web Vitals section, and look specifically at the INP score alongside LCP and CLS.

The first thing the report tells you is whether the failure is consistent across your site or concentrated on specific pages: booking pages, contact forms, product listings. Concentrated failures on specific pages usually point to particular plugins or scripts. Consistent failures across all pages usually point to a heavy theme or a tracking script loading on every page.

Conclusion

The metric has been active since March 2024. The HTTP Archive data from 2025 ^[3] shows that roughly half of all websites are still failing at least one Core Web Vitals metric on mobile, and INP is a primary contributor on plugin-heavy WordPress installations.

Most business owners running WordPress sites have not looked at their INP score because they did not know the metric existed, or assumed their developer had it covered. The businesses that have checked are sitting in organic positions above the ones that have not. The fix, whether it is a hosting configuration or a JavaScript audit, starts with knowing where you actually stand.