Type “Core Web Vitals 2026” into Google right now and you’ll find articles insisting the thresholds have been tightened, that Google introduced a mysterious “Visual Stability Index,” that rankings are now scored as a domain-wide aggregate, that manual penalties are being issued for bad CLS scores. Some of it might eventually turn out to be true. Right now, a lot of it doesn’t match what Google’s own documentation actually says, and a fair amount of it looks like the kind of confident-sounding claim that spreads through SEO blogs faster than anyone checks it.
So it’s worth starting with what’s actually confirmed, because that distinction matters more than any individual metric.
What Google Has Actually Said, and What’s Still Rumour
Interaction to Next Paint replaced First Input Delay as the official responsiveness metric back in March 2024 — that part is settled and well past debate. As of Google’s current published guidance, a “good” score still means Largest Contentful Paint under 2.5 seconds, INP under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured from real Chrome users through the Chrome UX Report rather than a lab test, at the 75th percentile over a rolling 28-day window.
What isn’t settled, despite plenty of blog posts stating it as fact, is whether Google has quietly tightened the LCP threshold to 2.0 seconds, or started scoring performance as a site-wide aggregate rather than per template, or issuing manual actions over layout shift. If you see a number quoted with total confidence and no link back to Search Central or web.dev, treat it the way you’d treat an unsourced client testimonial — plausible, but not something to build a strategy on until it’s confirmed.
What Google has been consistent about, repeatedly, is a more boring but more useful point: Core Web Vitals are used by ranking systems, but they function closer to a tie-breaker than a lever. They rarely lift a mediocre page above a genuinely better one. What they do reliably is drag down a page that would otherwise be competitive, and quietly cost a business money regardless of where it ranks.
The Business Cost Nobody Puts on the Website Audit
This is the part that gets buried under the metric definitions. A one-second delay in page load has been shown, in research going back years, to measurably reduce conversion rates — the effect compounds the longer the delay runs. A retailer doing meaningful monthly revenue through its site doesn’t need a ranking drop to feel this. Visitors on a patchy mobile connection simply leave before the page finishes rendering, and that happens whether or not Google ever notices.
Layout shift causes a specific, avoidable kind of damage that’s easy to underestimate until you’ve watched it happen: someone goes to tap a button, and in the half-second before their finger lands, an ad or an image loads in above it and shifts the whole page down. They tap the wrong thing. On an e-commerce site, that’s sometimes the difference between “add to basket” and an accidental click on a completely different product.
INP Is the One Catching Sites Off Guard
Of the three metrics, INP is the one most businesses haven’t properly reckoned with, because it measures something genuinely different from what came before it. FID only checked how long the browser took to respond to a visitor’s very first click or tap. INP checks every interaction across the entire visit and reports something close to the worst delay experienced — meaning a single slow moment deep into a session, not just a slow start, can drag the whole score down.
In practice, the sites that struggle most with INP are the ones carrying a lot of third-party JavaScript: chat widgets, marketing pixels, personalisation scripts, heavy filtering systems on a product listing page. None of these show up as an obvious problem when someone glances at the homepage. They show up when a visitor tries to filter a product list by size and colour at the same time and the page hesitates for half a second before responding — long enough to notice, not long enough to obviously explain why.
Where WordPress Sites Specifically Run Into Trouble
A meaningful share of the WordPress sites that struggle with Core Web Vitals aren’t struggling because of WordPress itself. They’re struggling because of what’s been layered onto it over time — a page builder plugin, a slider plugin, three different analytics scripts nobody remembers approving, and a theme that loads its entire icon library on every page regardless of whether any icons are used.
The fix is rarely one dramatic change. It’s usually a slow audit: checking which plugins are actually earning their keep, removing render-blocking scripts that load before the page’s main content, and making sure images are properly sized and compressed rather than relying on the browser to shrink an oversized file on the fly. A lean, purpose-built WordPress theme tends to hold up far better under this kind of scrutiny than a heavily templated one, simply because there’s less unnecessary code fighting for the same rendering budget.
E-commerce Sites Carry a Harder Version of the Same Problem
Product pages tend to be the worst offenders on any retail site, mostly because they’re carrying the most weight — high-resolution images, a review widget, a recommendation carousel, a live chat box, and a checkout script, all loading roughly at once. Each one, on its own, seems reasonable. Together, they compete for the same limited slice of the browser’s attention during the page’s most important seconds.
Category pages with heavy filtering are usually where INP problems concentrate, since filtering by price, size, or colour typically triggers a burst of JavaScript work each time a shopper touches a filter. Breaking that work into smaller chunks, rather than running it all at once, tends to be the difference between a filter that feels instant and one that feels like it’s thinking about it.
The AI Search Angle That’s Easy to Overlook
There’s a newer reason page speed matters beyond the traditional ranking argument. When an AI system is deciding which pages to pull into a generated answer, it needs to fetch and parse that page efficiently. A page that’s slow, bloated, or structurally messy is simply harder work for a system that’s often comparing dozens of candidate sources in a short window. It’s not that speed directly earns a citation — content and relevance still do that. It’s that a slow, cluttered page makes itself a worse candidate before the content quality is even weighed.
Where to Actually Start
The most common mistake isn’t ignoring Core Web Vitals. It’s fixing the wrong one first. A business that spends weeks compressing images when its real problem is a slow server response time, or one that chases a perfect Lighthouse lab score while ignoring what real visitors on mid-range Android phones are actually experiencing, ends up with very little to show for the effort.
The more reliable starting point is Search Console’s own Core Web Vitals report, which groups pages by template and shows which ones are failing and on which metric. From there, the fix usually follows the failing metric: slow LCP points toward server response time and render-blocking resources; poor INP points toward third-party scripts and JavaScript execution; layout shift points toward images and ads loading without reserved space. None of these are exotic fixes. They’re just specific enough that guessing rarely gets there faster than checking.
Good Core Web Vitals scores won’t rescue thin, unhelpful content, and no amount of content quality fully compensates for a page that frustrates people before they’ve read a word of it. Treated as part of the same foundation — alongside technical SEO and genuinely useful content — they’re one of the few parts of SEO that can be measured, fixed, and verified with real data rather than guesswork.
