INP Is the Metric Your WordPress Website Is Failing

Interaction to Next Paint measures how long your website takes to visually respond after a user taps or clicks. Google’s threshold for a good score is 200 milliseconds or less at the 75th percentile of real user interactions, measured from field data rather than a lab test. It is the Core Web Vital that most WordPress websites fail, and it is the one that caching plugins do essentially nothing to fix, because INP is a JavaScript execution problem and caching solves a delivery problem.

That distinction is the reason this article is worth reading. The standard South African agency response to a failing Core Web Vitals report is to install a caching plugin, enable a content delivery network, compress the images and re-run the test. That sequence genuinely improves Largest Contentful Paint. It frequently leaves INP exactly where it was, and the client is told the website has been optimised while the interaction that actually matters, the one on the enquiry form, still stutters.

What INP actually measures, precisely

INP replaced First Input Delay as a Core Web Vital on 12 March 2024, and the replacement was not cosmetic. It measured something meaningfully harder.

First Input Delay measured only the delay before the browser began processing the first interaction on a page. It ignored every subsequent interaction, and it ignored everything that happened after processing started. A page could pass FID comfortably and still feel broken, because the metric stopped measuring at the moment the real work began.

INP observes every qualifying interaction across the entire lifespan of the visit and reports the worst one, with a small allowance for outliers: for pages with a high number of interactions, one highest interaction is discarded for every 50 interactions. It measures the full path from input to the next visual update, comprising three parts.

Input delay is the time between the user’s action and the event handler beginning to run, usually because the main thread is busy with something else.

Processing time is how long your event handlers take to execute.

Presentation delay is the time from the handler finishing to the browser painting the updated frame.

The thresholds are 200 milliseconds or less for good, above 200 and up to 500 milliseconds for needs improvement, and above 500 milliseconds for poor. Scrolling does not count, because scroll is handled on the compositor thread independently of the main thread.

Correcting some claims currently circulating

There is a quantity of confidently written misinformation about 2026 Core Web Vitals changes in circulation, and clients have been forwarding it to us, so it is worth addressing directly.

The three thresholds have not changed. Largest Contentful Paint remains 2.5 seconds, INP remains 200 milliseconds, and Cumulative Layout Shift remains 0.1, all assessed at the 75th percentile of real users over a rolling 28-day window in the Chrome User Experience Report. Google’s Search Central documentation and the web.dev metric definitions both still carry those numbers. Claims that Google tightened the LCP threshold to 2.0 seconds are not supported by either.

The 2.0 second figure does circulate legitimately, which is probably where the confusion started. It is a common recommendation for where to set a monitoring alert, placed deliberately below Google’s actual limit so that you get warning before you cross it. That is sensible practice. It is not a change to the classification boundary, and repeating it as one has led businesses to commission performance work against a target Google does not use.

Claims that Google now issues manual actions against pages with poor Cumulative Layout Shift are not supported by anything Google has published. Manual actions are a spam enforcement mechanism, not a performance one.

Claims that Core Web Vitals are now assessed as a domain-wide aggregate, so that weak pages drag down strong ones, misdescribe how the data works. Search Console groups similar URLs together for reporting purposes because many individual URLs lack enough traffic for statistically meaningful field data, and that grouping is often mistaken for domain-level scoring.

Worth remembering: It is also worth keeping Core Web Vitals in commercial proportion. Google’s own documentation describes them as used by ranking systems while being clear that they do not guarantee position. In practice they function as a tie-breaker between pages of comparable relevance rather than a factor that lifts weak content above strong content. The stronger argument for fixing INP has never been rankings. It is that a form which lags for 600 milliseconds on submit loses enquiries.

Why WordPress fails INP specifically

This is structural rather than incidental, and it comes down to how the WordPress plugin ecosystem interacts with the browser’s single main thread.

Every plugin adds main-thread JavaScript

A typical WordPress business website runs somewhere between fifteen and thirty active plugins. A contact form plugin, a slider, a cookie banner, a chat widget, an analytics stack, a security plugin with a front-end component, a page builder. Each loads its own JavaScript, and that JavaScript competes for the same main thread that has to respond to the user’s tap. None of these plugins is individually unreasonable. Collectively they produce a main thread that is never quite free.

Page builders generate deep DOM trees

Elementor, Divi and similar builders produce heavily nested markup, often five to eight wrapper elements deep where hand-written markup would use one. Every interaction that triggers a style recalculation or layout has more nodes to process. The effect is invisible on a development machine and pronounced on a mid-range Android phone.

WooCommerce cart fragments

The cart fragments request is one of the most reliable performance problems in South African ecommerce. It appears in your Network tab as wc-ajax=get_refreshed_fragments, it exists to refresh the mini-cart markup, and it boots the entire WordPress and WooCommerce stack to do it. Because it is uncacheable by design, no caching layer will save you from it, and on a slow connection it can occupy the main thread at exactly the moment a shopper is trying to add something to their cart.

WooCommerce narrowed this in version 7.8, so the script is no longer enqueued on every page of every store. It now loads where the cart widget is genuinely present, where a third-party script declares cart-fragments as a dependency, or where it has been enqueued deliberately in code. That middle condition is why so many stores still load it everywhere. One plugin declaring the dependency reinstates the behaviour across the whole website, and nobody notices, because it does not show up in a Lighthouse score.

Third-party scripts you did not choose

Marketing tags, remarketing pixels, chat widgets and heat-mapping tools are frequently added by someone other than the developer, often directly through a tag manager, and they execute on the same main thread as everything else. We regularly inherit websites where the single largest contributor to poor INP is a chat widget nobody has used in a year.

The South African variable that changes the maths

The 75th percentile is the part most people misunderstand, and in this market it is decisive.

Passing INP requires that at least 75 percent of real interactions complete within 200 milliseconds. Not the average interaction. Not the interaction on your laptop. Google is grading you on roughly the fourth-slowest user in every four, which in South Africa means a mid-range Android device on a variable mobile connection, not a MacBook on fibre in Bryanston.

INP is particularly sensitive to device capability because it is dominated by JavaScript execution time, and execution time scales almost directly with processor performance. The same page that responds in 90 milliseconds on a current iPhone can take 400 milliseconds on a three-year-old mid-range Android handset. Given the device mix in this market, a website that only ever gets tested on the developer’s hardware is being assessed on a population that barely resembles its actual users.

This is why lab tools mislead. Lighthouse cannot produce a real INP score, because INP requires actual human interactions to measure. A PageSpeed Insights performance score of 95 tells you nothing reliable about your INP. The field data section of the same report, drawn from real Chrome users, is the part that matters, and it is the part most people scroll past.

Diagnosing it properly

In order, because doing these out of sequence wastes time.

Start with field data. PageSpeed Insights shows the Chrome User Experience Report data at the top of the report. If your website lacks the traffic for page-level field data, you will see origin-level data instead. That is still useful. If there is no field data at all, install a real user monitoring solution and wait, because you cannot optimise what you cannot observe.

Identify which interactions are slow. The web-vitals JavaScript library can attribute INP to specific elements and report which interaction produced the worst score. This is the step most teams skip, and skipping it means optimising blind. Knowing that your INP is 480 milliseconds is not actionable. Knowing that it is 480 milliseconds on the mobile menu toggle is.

Profile the interaction in Chrome DevTools. The Performance panel shows the breakdown of input delay, processing time and presentation delay for a given interaction, which tells you which of the three you are actually fighting. A long input delay points to main-thread contention from other scripts. A long processing time points to your own handler. They require completely different fixes.

Fixing it, in order of return

Remove before you optimise

The highest-return work on almost every website we inherit is deletion. Audit every active plugin and every third-party script against actual business use. In our experience a genuine audit removes somewhere between three and eight scripts from a typical business website, and no amount of clever optimisation beats not loading the code at all. Running that audit on a schedule rather than once is exactly what website maintenance and performance optimisation is for.

Break up long tasks

Any JavaScript task running longer than 50 milliseconds blocks the main thread and delays any interaction arriving during it. The fix is to break long tasks into smaller pieces and yield to the main thread between them, which lets pending user input be processed rather than queued behind your work. This is genuine development work rather than a plugin setting, and it is where most of the remaining gain sits once the deletion pass is done. That is WordPress development services in Johannesburg territory rather than something a settings panel exposes.

Defer what does not need to run immediately

Chat widgets, analytics beyond the core page view, remarketing pixels and social embeds rarely need to execute during initial load. Deferring them until after the page is interactive, or until first user interaction, removes them from competition for the main thread at the moment it matters most.

Deal with cart fragments deliberately

On WooCommerce, restrict cart fragments to the pages that genuinely need a live cart count, which is usually far fewer than the number currently loading it. Start by identifying which plugin declares cart-fragments as a dependency, because since version 7.8 that is normally the reason it is still running site-wide. This is a targeted change rather than a blanket one, because removing fragments where the cart count does need updating produces a confusing experience. It is one of the few WooCommerce-specific optimisations that reliably moves INP. We deal with this routinely in ecommerce and WooCommerce development work.

Simplify the markup you control

Where a page builder is generating eight levels of nesting for a two-column layout, rebuilding that section properly reduces the work every interaction has to do. This is slow, unglamorous work with real returns, and it is the strongest argument for building templates properly rather than assembling them from builder defaults.

The reporting trap

One operational point that causes more client friction than any technical issue. Search Console and the Chrome User Experience Report use a rolling 28-day window. A fix deployed today will not fully appear in reporting for four weeks, and partial improvement will appear gradually as the window rolls forward.

Set that expectation before the work starts, not after the client asks why the report is still red. We commit the deployment date in writing and diarise the review for 28 days later, and we use lab profiling to demonstrate the improvement in the interim. Anyone promising a fixed Core Web Vitals report next week is either not using field data or not being straight with you.

The strategic read

That is why it is the metric most WordPress websites fail and the one most agencies avoid discussing. It is the honest scorecard for whether a website was engineered or assembled. A website built from a premium theme, eleven plugins and a page builder, all installed to hit a deadline, will fail INP no matter how much is subsequently spent on hosting and caching. The wider version of that argument sits in Search Experience Optimisation: The Next Evolution of SEO.

The commercial argument for fixing it has very little to do with Google. A 500 millisecond delay on a form submit is a delay the user experiences as the website being broken, on the interaction closest to your revenue. That was worth fixing before it had a name and a threshold attached. If your INP is failing and you want to know why, request a quotation and we will diagnose it against field data rather than a lab score.

Frequently Asked Questions

What is a good INP score?

200 milliseconds or less at the 75th percentile of real user interactions. Between 200 and 500 milliseconds is classified as needs improvement, and above 500 milliseconds is poor. It is measured from field data over a rolling 28-day window, not from a lab test.

Will a caching plugin fix my INP?

Almost never. Caching addresses how quickly content is delivered, which helps Largest Contentful Paint and server response time. INP measures JavaScript execution on the main thread after the page has loaded, which caching does not touch.

Why does my PageSpeed score say 95 but my Core Web Vitals fail?

The performance score is a lab simulation from a single synthetic load. Core Web Vitals assessment uses field data from real Chrome users. INP in particular cannot be measured in a lab, because it requires actual human interactions. Read the field data section of the report, not the score.

How long before a fix shows in Search Console?

Up to 28 days for the full effect, because both Search Console and the Chrome User Experience Report use a rolling 28-day window. Improvement appears gradually as the window moves forward past the deployment date.

Does WooCommerce make INP worse?

Often, yes. The cart fragments request, which appears as wc-ajax=get_refreshed_fragments, is a common culprit because it is uncacheable by design and boots the full WooCommerce stack to refresh the mini-cart. WooCommerce 7.8 limited where it loads, but any plugin declaring cart-fragments as a dependency reinstates it site-wide. Restricting it to pages that genuinely need a live cart count usually helps.