Core Web Vitals and INP: Why Your WordPress Site May Be Losing Rankings in 2026

If your WordPress site has quietly slipped down the search results over the past two years, and you've already checked the obvious things (content, links, keywords), the cause might be sitting somewhere you haven't looked: how your site responds when someone actually clicks on it.

Interaction to Next Paint, known as INP, has been one of Google's three Core Web Vitals since 12 March 2024, when it formally replaced First Input Delay (FID). Most of the advice still circulating online is written for the old metric. That gap is costing WordPress site owners rankings without them realising why.

What Core Web Vitals actually measure

Google's Core Web Vitals are three field metrics that describe how real visitors experience a page, not how it performs in a lab test. As of 2026, they are:

• Largest Contentful Paint (LCP) – how long the main content takes to load. Google's benchmark for "good" is 2.5 seconds or less.
• Interaction to Next Paint (INP) – how quickly the page responds after someone interacts with it (a click, a tap, a key press). Good is under 200 milliseconds.
• Cumulative Layout Shift (CLS) – how much the page jumps around as it loads. Good is a score below 0.1.

Google's own Search Central documentation is careful about how these feed into rankings. There is no single page experience score. Core ranking systems weigh a variety of signals, and Core Web Vitals are among them, alongside HTTPS, mobile-friendliness, and the absence of intrusive interstitials. What that means in practice, according to Google's guidance, is that when two pages are otherwise similarly relevant to a search, the one with the better user experience has the edge.

That "tiebreaker" framing is often used to downplay Core Web Vitals. It shouldn't be. On competitive terms, where dozens of pages are all reasonably relevant, page experience is frequently the difference that decides who ranks first and who ranks eighth.

INP replaced FID, and most site owners haven't noticed

For years, "page speed" advice for WordPress focused on First Input Delay, which only measured the delay before the very first interaction on a page. Google recognised this was an incomplete picture; FID said nothing about how a page behaved for the rest of a visit, when most of the actual clicking, scrolling, form-filling, and menu-opening happens.

INP fixes that by tracking every interaction across the full lifetime of a page visit and reporting the value that represents the slowest (or nearly slowest) of them, measured at the 75th percentile of visits. A low INP means a site stays responsive throughout, not just on the first click. It's a far more demanding, and far more honest, measure of what a visitor actually experiences.

Because so much SEO advice online predates March 2024, it's common for WordPress owners to run a speed test, see a passing score on an outdated metric, and assume the job is done. It isn't.

Where WordPress sites actually stand in 2026

The data tells a consistent story. According to the Core Web Vitals Technology Report, which draws on Google's Chrome UX Report (CrUX) and HTTP Archive data, WordPress has trailed hosted platforms on overall Core Web Vitals pass rates for several years running. Analysis based on June 2025 CrUX data put WordPress at around 43 to 44% of mobile origins passing all three Core Web Vitals, compared with roughly 75% for Shopify, 71% for Wix, and 68% for Squarespace. More recent figures from late 2025 put fully hosted platforms such as Duda close to 85%, against WordPress hovering around 46%.

The most useful figure in that dataset, though, is not the overall pass rate. It's the breakdown by individual metric. WordPress's INP pass rate sits at roughly 86%, comparable to Wix and only slightly behind Squarespace. In other words, WordPress is not, on the whole, an unresponsive platform. The problem dragging the overall score down is LCP, not INP, and the two require completely different fixes.

CrUX data cited in the same research shows only around 32% of WordPress sites recording a good Time to First Byte (TTFB), the very first stage of the loading process, before anything on the page has even started to render. Shared hosting environments typically produce a TTFB of 900 to 1,400 milliseconds at the 75th percentile. Moving the same site to managed hosting with proper server-side caching can bring that down to 120 to 250 milliseconds, which is often enough on its own to move LCP from "poor" to "good".

This is a hosting and infrastructure issue as much as a code issue. It also means WordPress owners chasing INP fixes while their real problem is a £3-a-month shared hosting package are optimising the wrong metric.

That said, INP is still a genuine WordPress weak spot for many sites

An 86% average pass rate is not the same as your site passing. INP failures on WordPress tend to come from a small, repeatable list of causes, all well documented in Google's own developer guidance:

• Long tasks blocking the main thread. JavaScript in the browser runs to completion once it starts, which means a single heavy task, often from a page builder, animation library, or slider plugin, can hold up the browser's ability to respond to a click until that task finishes. Google's guidance on this is explicit: breaking large tasks into smaller ones, and yielding control back to the browser between them, is one of the most effective INP fixes available.
• Third-party scripts. Live chat widgets, tracking pixels, embedded booking systems, and ad scripts all run their own code on your page, often on a timer, often outside your control. Google's own documentation on loading third-party JavaScript acknowledges that when a script schedules recurring background tasks, it can extend the delay before your page responds to a genuine user interaction, even if your own code is fast. On a typical WordPress build carrying six or seven of these at once, the cumulative effect on INP is significant.
• Bloated themes and page builders. Visual page builders generate large, deeply nested DOM structures and often load their own JavaScript framework on top of WordPress and jQuery. A large DOM means more work for the browser every time something on the page changes, which directly affects how quickly it can paint a response to an interaction.
• Plugin stacking. Each plugin that hooks into wp_enqueue_script adds to the JavaScript payload the browser has to parse and execute before the page becomes fully interactive. Individually, most plugins are harmless. A dozen of them enqueuing scripts on every single page, whether that plugin's functionality is used on the page or not, is a common and largely invisible cause of poor INP.

How to start fixing it

You don't need to rebuild the site to make meaningful progress. A sensible order of operations:

1. Check field data, not just a single test. PageSpeed Insights pulls real CrUX field data where your site has enough traffic to qualify; Search Console's Core Web Vitals report shows the same at scale across your site. A single Lighthouse run is a lab simulation and can miss what real visitors experience.
2. Audit hosting and TTFB first if LCP is the bigger problem. Given how much of WordPress's overall Core Web Vitals shortfall comes from server response time, this is often the highest-impact single change available.
3. Profile actual interactions, using Chrome DevTools' Performance panel, to see which specific click or tap on your site is triggering the longest delay, rather than guessing.
4. Audit every plugin and script for necessity. Anything enqueuing JavaScript sitewide that's only needed on one page or one form should be scoped down or removed.
5. Defer and lazy-load what isn't needed immediately, particularly chat widgets, embeds, and anything below the fold.

The bottom line

INP has been a live Google ranking-relevant metric for over two years, and the WordPress ecosystem as a whole is still catching up. The platforms beating WordPress on Core Web Vitals aren't necessarily faster where it counts (responsiveness); they're winning on infrastructure. That's genuinely good news for WordPress site owners, because it means the fix rarely requires abandoning the platform. It requires the right technical audit.

If you don't know where your site currently stands on LCP, INP, and CLS, or whether your hosting is quietly capping your rankings, that's exactly the kind of diagnostic work worth getting a second pair of eyes on before your next content push.

Frequently asked questions

What is a good INP score?

Google's guidance defines under 200 milliseconds as good, 200 to 500 milliseconds as needs improvement, and anything above 500 milliseconds as poor, measured at the 75th percentile of a page's visits.

Did INP replace First Input Delay?

Yes. INP officially became a Core Web Vital and replaced FID on 12 March 2024. FID only measures the delay before a page's first interaction; INP measures responsiveness across every interaction during a visit.

Is Core Web Vitals a direct Google ranking factor?

Google states there is no single page experience ranking signal. Core Web Vitals form part of a broader set of signals its core ranking systems consider, and they can act as a tiebreaker between pages of similar relevance and quality.

Why does WordPress score worse than Shopify or Wix on Core Web Vitals?

Largely because of Largest Contentful Paint and server response time (TTFB), not INP. WordPress's INP pass rate is broadly in line with Wix and Squarespace. Its overall Core Web Vitals gap comes mainly from hosting quality and page weight rather than JavaScript responsiveness.

Can plugins hurt my INP score?

Yes. Plugins that enqueue JavaScript on every page, regardless of whether that page uses the plugin's functionality, add unnecessary work for the browser's main thread and are one of the most common causes of poor INP on WordPress sites.

If your website is struggling with LCP, INP, CLS or slow server response times, the team at Web Choice can help identify what is holding it back.

We can assess your website's performance, identify the technical issues affecting user experience and search performance, and recommend the right fixes.

Get in touch with Web Choice today to discuss your website's performance.