Interaction to Next Paint: The Core Web Vital Most WordPress Sites Are Quietly Failing

Reviewing our monitoring dashboards this morning, the pattern that stands out is not slow page loads. Most of the sites we watch load quickly enough. It is something that happens after the page has already finished loading: a visitor clicks "Add to Basket," taps a date on a booking calendar, or types into a contact form, and the page hesitates for a beat too long before responding. That hesitation has a name now. It is called Interaction to Next Paint, and Google made it an official Core Web Vital in March 2024 ^[1]. Most business owners have never heard of it. Search Console has been quietly scoring their site against it for over two years.

What Interaction to Next Paint Actually Measures

INP replaced an older metric called First Input Delay, and the difference between the two explains why INP catches problems FID never could. First Input Delay only measured the delay before a browser started responding to a visitor's very first click or tap. INP is broader. It watches every interaction a visitor makes across an entire page visit, from the first click to the last, and reports a single number representing how the page performed at its worst common moment ^[2].

A good INP score sits at 200 milliseconds or less, measured at the 75th percentile of real visits. Between 200 and 500 milliseconds counts as needing improvement. Above 500 milliseconds is poor, and a visitor will consciously notice the delay rather than just feel that something is slightly off ^[2].

INP Score	Rating	What a Visitor Experiences
200ms or less	Good	Clicks and taps feel instant
200ms to 500ms	Needs improvement	A noticeable, faint delay after tapping
Above 500ms	Poor	The page feels stuck or unresponsive

So what does that actually mean for a business site? It means the technical score is not an abstract SEO number sitting in a dashboard somewhere. It is a direct read on whether tapping a button on a customer's phone feels instant or feels broken, and Google now measures that experience across the whole platform, not just the homepage. INP is also one of three metrics that together decide whether a site passes Google's combined Core Web Vitals assessment, and we have tracked how often WordPress sites generally come up short on that combined test in our analysis of Core Web Vitals failure rates.

Why This Matters More Than It Sounds

Consider a booking calendar for an outdoor activities business. A kayak and canoe hire operator in Leitrim runs online bookings through a calendar widget embedded on their site. The week a local radio slot sent a spike of new visitors to that booking page, several of them tapped a date and waited. And waited.

On a phone with a weaker connection and an older processor, that pause ran past a second. Some visitors tapped again, assuming the first tap had not registered. A few gave up and rang a competitor instead. Nothing crashed. Nothing showed an error. The booking calendar simply could not keep up with how many people wanted to click on it at once, and the business never saw those lost bookings as a technical problem. It looked, from the outside, like a slow week.

That is the practical stakes of INP. It rarely produces an error message a business owner can point to. It produces a slightly slower click that a percentage of visitors never wait through, on pages that otherwise look and load perfectly fine.

Why WordPress Sites Struggle With INP Specifically

WordPress runs a bit over four in ten websites globally, a share that has held remarkably steady for years even with AI website builders now competing for the same customers ^[3]. That scale is also exactly why INP problems creep in so easily. The platform's openness, its enormous plugin and theme ecosystem, is the whole reason businesses choose it. It is also the main channel through which a responsiveness problem quietly builds up, one small script at a time.

Page Builders and Drag-and-Drop Themes

Visual page builders make WordPress approachable for a non-technical business owner, which is genuinely valuable. The tradeoff is that most of them ship a meaningful amount of extra JavaScript to power drag-and-drop editing, animations, and flexible layouts, and that code keeps running on the visitor's browser long after the page has finished loading. When the browser's main thread is busy running that code, it cannot immediately respond to a click, however small the delay looks in isolation ^[4].

Plugin Stacking

A single plugin rarely causes a serious INP problem on its own. The issue is cumulative. Every additional plugin loading its own script, its own event listeners, its own background checks, adds a small amount of competition for the same main thread. A site running fifteen plugins, each individually reasonable, can end up with an INP score none of those plugin authors would ever see in their own testing, because none of them are testing against each other.

Third-Party Scripts and Embeds

Chat widgets, booking embeds, marketing pixels, and review widgets are useful individually. Each one also attaches its own JavaScript to the page, competing for the same limited window of time the browser has to respond to a visitor's tap ^[4]. This is the category we see catch business owners out most often, because these are typically added one at a time over months, each addition feeling harmless, with nobody watching the cumulative effect on responsiveness.

How to Check Your Own Site's INP Score

Three tools show this from different angles, and it is worth knowing what each one actually tells you before acting on any of them.

Search Console's Core Web Vitals report is the most important one, because it uses real field data from actual visitors rather than a simulated test ^[5]. It groups your pages by URL pattern and flags each group as Good, Needs Improvement, or Poor based on its worst-performing metric. PageSpeed Insights gives the same field data at a single-URL level, alongside a lab test you can run on demand.

Chrome DevTools' Performance panel goes a layer deeper. Record a visit, click or tap somewhere on the page during the recording, and it will show you exactly which script produced the longest task blocking that interaction. This is where you actually find the culprit rather than just confirming a score is poor.

One honest limitation worth flagging here: lab data from DevTools or a one-off Lighthouse test will not always match the real INP score in Search Console. Different visitors use different devices, different networks, and click in different places on the page. Treat lab testing as where you diagnose the specific slow script. Treat the Search Console field score as the number that reflects real visitors and actually affects how Google reads the page.

The Practical INP Fix, In Four Steps

Audit. Open the Core Web Vitals report in Search Console and check PageSpeed Insights for the affected URL group to confirm which pages are flagged Poor or Needs Improvement for INP specifically, not LCP or CLS.

Isolate. Use the Performance panel in Chrome DevTools to record a real interaction on the flagged page and identify which single script is producing the longest task on the main thread.

Defer. Push non-essential third-party scripts, such as chat widgets or marketing pixels, to load only after the visitor's first interaction rather than immediately, and remove or replace the single heaviest plugin if it is not earning its place on the page.

Verify. Re-run PageSpeed Insights immediately for a quick sanity check, then confirm the fix in the Search Console field data after a few weeks of real visits, once enough data has accumulated to move the 75th-percentile score rather than just the lab test.

I once told a client a plugin removal would fix their responsiveness problem within days. It took closer to three weeks for the Search Console field score to catch up and confirm it, because that report only updates once enough real visits have rolled in. I do not promise overnight score changes anymore. I promise the fix and give an honest range for when the report will show it.

Which Pages Feel a Bad INP Score the Most

• Booking and appointment systems. A calendar widget that hesitates on tap directly costs a business the booking itself, not just a bounce.
• eCommerce checkouts. A delayed response on "Add to Basket" or a payment field is the single most expensive place for a slow interaction to happen.
• Lead generation forms. A form field that lags while typing reads as broken to a visitor, and broken forms get abandoned rather than retried.

Where Managed Hosting Helps, and Where It Cannot

If you are running an enterprise WordPress deployment with a dedicated front-end team continuously profiling every release against a performance budget, a specialised monitoring vendor alongside an enterprise platform like Kinsta's top tier, built for teams shipping code multiple times a day, will genuinely catch micro-regressions faster than a managed platform built for single-site small businesses. That is a real advantage for that specific setup. It is not the situation most small business owners running a WordPress site with a handful of plugins are actually in.

Here is the honest scope of what hosting can and cannot do for INP. Web60's stack runs Nginx, PHP-FPM, Redis object caching, and FastCGI page caching, which meaningfully improves how fast the server responds and how quickly the page arrives in the first place. That is a real win for load speed and for metrics like Largest Contentful Paint. INP, though, is mostly decided after the page has already arrived, by how much JavaScript is competing for the visitor's browser. No hosting stack can rewrite a bloated page builder's code for you.

What a solid hosting setup does give you is a safe way to test the fix. Web60's staging environments let you strip out a heavy plugin or defer a script on a copy of the site before touching production, with automatic pre-update safety snapshots in case a change breaks something unexpected. That combination, covered in more depth in our complete guide to WordPress performance, removes the fear of trying a fix, which is often what stops a business owner from touching plugin bloat in the first place.

Conclusion

An INP problem rarely announces itself. No error message appears, no page goes down, and the site looks entirely normal to whoever built it. It shows up instead as a fraction of visitors who tap once, wait, and quietly leave, which is exactly why it survives unnoticed on so many WordPress sites. Checking the Core Web Vitals report in Search Console takes ten minutes. Finding the one script or plugin actually responsible takes a bit longer, but not much. What happens after that, whether it gets fixed this week or sits on a list for another quarter, decides whether that next tap gets a response or gets a competitor's number instead.

Frequently Asked Questions

What is a good INP score for a WordPress website?

200 milliseconds or less, measured at the 75th percentile of real visits in Search Console's Core Web Vitals report. Between 200 and 500 milliseconds needs improvement, and anything above 500 milliseconds is rated poor ^[2].

Does INP completely replace First Input Delay?

Yes. Google retired First Input Delay as a Core Web Vital in March 2024 and replaced it with INP, and Search Console stopped reporting FID from that point onward ^[1].

Will installing a caching plugin fix my INP score?

Sometimes, but not reliably on its own. Caching mostly improves how fast a page arrives, which helps Largest Contentful Paint more directly than INP. Some caching plugins include a "delay JavaScript" feature that can help INP by postponing non-essential scripts, but the bigger wins usually come from removing or replacing the specific plugin or script causing the longest main-thread task.

How long does it take for an INP fix to show up in Search Console?

The Core Web Vitals report relies on rolling field data from real visits, so a fix typically needs a few weeks of traffic before the report reflects it. A lab tool like PageSpeed Insights will show improvement immediately, but treat that as a preview rather than confirmation.

Does every WordPress plugin hurt INP?

No. A single well-built plugin rarely causes a noticeable problem. The risk builds cumulatively as more plugins, page builder features, and third-party embeds each add their own script competing for the same browser main thread.

Does managed WordPress hosting improve INP automatically?

Not directly. Hosting infrastructure has more influence over metrics like Largest Contentful Paint than INP, since INP is largely decided by JavaScript running in the visitor's browser after the page arrives. A good hosting setup does make it safer to test and remove the plugins or scripts actually causing the problem, through staging environments and automatic pre-update backups.

Sources