INP Is the Core Web Vital Most WordPress Sites Are Failing in 2026 (and How I Fix It)

Interaction to Next Paint (INP) has quietly become the Core Web Vital that trips up more sites than any other. Since it replaced First Input Delay as Google’s official responsiveness metric, I’ve watched clients who used to pass every audit suddenly land in the “needs improvement” column — not because their sites got slower to load, but because they got slower to respond. If you build or run a WordPress or WooCommerce store in 2026, INP is the number I’d tell you to check first.

What INP actually measures (and why it’s harder than the old metric)

INP measures how long it takes your page to visually respond after a user interacts with it — a tap, a click, a key press. It doesn’t just look at the first interaction like FID did. It watches the worst interactions across the entire visit and reports a value that represents the overall experience. That single change makes INP much harder to game. You can no longer optimise one fast first-click and call it a day; every menu toggle, every “add to cart,” every filter has to stay snappy.

The thresholds are simple to remember. An INP at or below 200 milliseconds is good. Between 200 and 500 milliseconds needs improvement. Anything above 500 milliseconds is poor, and users feel it as that laggy, unresponsive quality where they tap a button and wonder if the page even registered it.

Most sites are failing, and here’s the data

This isn’t a niche concern. According to Chrome UX Report data from May 2026, only about 56% of tracked origins pass all three Core Web Vitals. Mobile pass rates have climbed steadily — from roughly 32% in 2021 to 48% in 2025 — but that still leaves half the web falling short on real devices. And “real devices” is the key phrase, because INP is where the gap between your machine and your visitor’s phone shows up most brutally.

A modern laptop executes JavaScript something like eight to twelve times faster than a mid-range Android phone. Mobile browsers are also memory-throttled, and sustained JavaScript execution gets slower over a session rather than faster. So a WooCommerce product page that feels instant on your development machine can stutter badly for the shopper on a three-year-old Android — the exact shopper you’re trying to convert.

Why WordPress and WooCommerce sites struggle with INP

In my experience, poor INP on a WordPress site almost always comes down to too much JavaScript doing too much work on the main thread. A few repeat offenders show up again and again:

• Heavy page builders and their add-ons. Elementor, in particular, ships a lot of JavaScript, and third-party widget packs pile on more. Every interactive element that re-runs scripts on click adds to your INP.
• Third-party tracking and chat scripts. Analytics, heatmaps, live chat, and ad pixels all compete for the main thread. They’re often the single biggest cause of interaction lag on otherwise lean sites.
• WooCommerce cart and AJAX interactions. Mini-cart updates, variation swatches, and AJAX “add to cart” buttons can block the thread while they process, which is exactly the moment a shopper is interacting.
• Unnecessary JavaScript for things CSS can do. Accordions, tabs, and simple animations built in JavaScript when modern CSS would handle them natively.

How I fix INP on client sites

When I take on an INP problem, I work through a fairly consistent playbook. None of it requires ripping the site apart.

1. Measure with real-user data, not lab scores

Lighthouse gives you a lab estimate, but INP is a field metric. I start with the Core Web Vitals report in Google Search Console and the CrUX data for the domain, then reproduce issues with the web-vitals JavaScript library so I can see which interactions are actually slow. Optimising blind is a waste of everyone’s time.

2. Cut and defer JavaScript ruthlessly

The fastest wins usually come from removing scripts that don’t need to be there, then deferring the rest. I audit every plugin that enqueues JavaScript site-wide and dequeue it on pages that don’t use it. A slider script has no business loading on a checkout page.

3. Break up long tasks

Any task that occupies the main thread for more than 50 milliseconds blocks interaction. Where I control the code, I break long-running work into smaller chunks and yield back to the browser — using techniques like setTimeout, requestIdleCallback, or the newer scheduler.yield() where support allows. This lets the browser respond to a tap before finishing background work.

4. Delay third-party scripts until interaction

Tools like chat widgets and non-critical analytics can load after the user first interacts, rather than during the initial render. Several performance plugins now offer “delay JavaScript execution” as a setting, and used carefully it can dramatically improve INP without breaking functionality.

5. Prefer CSS and native HTML

Every accordion, dropdown, or animation I can move from JavaScript to CSS is one less thing blocking the main thread. Modern CSS handles a surprising amount of interactivity that we used to reach for a library to do.

The business case is real

This isn’t optimisation for its own sake. Sites that pass all three Core Web Vitals commonly see conversion gains in the 15 to 30% range, and INP maps directly onto the moments that matter for a sale — the tap on “add to cart,” the filter on a collection page, the checkout button. A store that feels responsive earns more trust, and trust converts.

If you’re not sure where your site stands, pull up your Search Console Core Web Vitals report and look specifically at the INP column on mobile. If you’re sitting above 200 milliseconds, there’s almost certainly a straightforward path to fixing it — and it usually starts with doing less JavaScript, not more. That’s the counterintuitive lesson INP keeps teaching me: in 2026, a fast site is often a simpler one.