Core Web Vitals and SEO: What the Evidence Actually Shows

Few technical SEO topics generate as much disagreement as Core Web Vitals. Ask ten SEOs whether they matter and you'll get answers ranging from "irrelevant hype" to "the most important ranking factor Google gives you direct control over." Both camps can point to real evidence. This guide works through what Core Web Vitals actually measure, what Google has said about them on the record, where the correlation data comes from, and why smart people keep disagreeing about the same set of facts. Every claim below is attributed to its source so it can be checked directly. A changelog at the bottom logs revisions.

What Core Web Vitals measure

Core Web Vitals are three metrics Google uses to approximate real user experience on a page: Largest Contentful Paint (LCP), which measures how long the biggest visible element takes to load; Interaction to Next Paint (INP), which measures how responsive the page feels when someone clicks, taps, or types; and Cumulative Layout Shift (CLS), which measures how much content jumps around unexpectedly while the page is loading. A page passes when at least 75% of real-world visits, measured over a rolling 28-day window through Chrome's own usage data (the Chrome User Experience Report, or CrUX), hit these thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.

That 75th-percentile, real-user-data detail matters. Core Web Vitals scores are not the same as a Lighthouse or PageSpeed Insights lab score run once from a single test location. A page can score perfectly in a lab test and still fail its real-world Core Web Vitals if actual visitors, many on slower connections or older phones, experience something worse.

What changed with INP

Interaction to Next Paint replaced First Input Delay (FID) as the third Core Web Vital on March 12, 2024, after Google spent roughly a year testing it as an experimental metric. FID only measured the delay before a browser started processing the first interaction on a page; INP measures responsiveness across every interaction for the full page visit, which is a more demanding and more representative test. Any guide, tool, or checklist still built around FID is measuring something Google stopped using in 2024.

More recently, in July 2026 Chrome's team confirmed it is shipping "soft navigation" measurement, unflagged, starting with Chrome 151. This addresses a real gap: single-page applications that update content via JavaScript without a full page reload have never been cleanly measured by Core Web Vitals, since the metrics were originally built around traditional page loads. As of this writing, Chrome's own documentation is explicit that soft navigations are not yet reflected in official Core Web Vitals or CrUX reporting; the team has said only that it will "announce how CrUX will change when we have more to share." Sites running as SPAs should treat their current field data as incomplete rather than assume this is already accounted for. The three published thresholds themselves (2.5s / 200ms / 0.1) have not changed.

Source: Chrome for Developers (developer.chrome.com), licensed CC BY 4.0.

What Google has actually said

This is the part most debates skip past. Google's current official position, published in its Search Central documentation and last updated December 2025, is specific: "Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally... trying to get a perfect score just for SEO reasons may not be the best use of your time." The same page states plainly that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par," and that page experience functions as a differentiator "for many queries" where multiple pieces of content are already similarly helpful, not as a factor that overrides relevance.

Google's Search Advocates have reinforced this consistently and specifically, not just in vague terms. In October 2024, John Mueller wrote on LinkedIn: "We've been pretty clear that Core Web Vitals are not giant factors in ranking, and I doubt you'd see a big drop just because of that." He added the actual argument for caring about them anyway: "having a website that provides a good experience for users is worthwhile, because if users are so annoyed that they don't want to come back, you're just wasting the first-time visitors to your site." Three years earlier, in July 2021, Gary Illyes made a similar point more bluntly on Twitter/X, after a wave of SEOs reported ranking drops despite passing Core Web Vitals: "putting work in core web vitals doesn't mean that the site can't lose rankings over time. I also washed my car hundreds of times and it still left me standing on the highway." Google has repeated versions of this message for years: Core Web Vitals are a real, confirmed ranking input, but a light one that mostly acts as a tiebreaker between pages that are already similar in relevance and quality.

Where the disagreement really comes from

Given how consistent and specific Google's own statements are, why does the SEO industry still argue about this? Based on the sources reviewed for this guide, the disagreement mostly isn't actually about what Google has said. It's about two different questions getting treated as one.

Question one: does passing Core Web Vitals meaningfully move a page's position in Google's organic rankings? The evidence, including Google's own statements above, says: a little, at the margins, when competing pages are already close in quality. Not as a primary lever.

Question two: does site speed affect whether visitors convert, stay, or come back? Here the evidence, while messier than commonly presented (more on that below), points toward yes, speed affects user behavior in ways that matter to a business regardless of what Google's algorithm does with it.

Content arguing "Core Web Vitals matter enormously" is very often actually making the case for question two, using ranking language borrowed from question one. A revenue lift from faster load times is a real, valuable business outcome. It is not the same claim as "fixing your LCP will make Google rank you higher," and treating the two as interchangeable is where a lot of the industry disagreement actually originates.

What the correlation studies show

The most detailed independent look at Core Web Vitals and rankings remains Ahrefs' 2022 study of over 5 million pages using CrUX data (worth noting: this study predates INP and measured the old FID metric instead). It found around 33% of websites passing Core Web Vitals thresholds at the time, up roughly 10 percentage points from the prior year, and a wide gap by country and connection speed, pages served mostly to users on 3G connections almost never passed LCP, regardless of how well-built the site was. Ahrefs' own conclusion is worth quoting directly rather than summarizing generously: the study's author wrote that due to the timing of the rollout and other updates happening simultaneously, "I don't think there's a good method that is conclusive," and compared any observed correlation to "saying sites that are more likely to work on their SEO also rank better than those that don't," meaning good technical performance may simply travel alongside other quality signals rather than cause better rankings on its own.

This is the honest state of the correlation evidence: real, but not strong enough, or clean enough, to isolate Core Web Vitals as an independent ranking driver. No credible, methodologically transparent study reviewed for this guide claims otherwise.

Why it's still worth doing

Setting the ranking debate aside, there's a separate, better-supported case for treating page speed and responsiveness as a real priority, just not for the reason a lot of SEO content claims.

The commonly cited statistics here deserve some scrutiny, since this is exactly the kind of claim that gets repeated without much scrutiny. Figures like "53% of mobile visitors abandon a site that takes longer than three seconds to load" and "each additional second of load time costs 7% of conversions" trace back to individual industry studies from around 2016 to 2017 (a Google/DoubleClick mobile study and an Aberdeen Group analysis, respectively) that have been recirculated for nearly a decade without much independent replication. They're old enough, and repeated often enough without their original context, that they're better treated as roughly directionally true than as precise, current figures.

What holds up better is more recent, source-specific evidence: a documented Rakuten 24 A/B test reported a 53% increase in revenue per visitor and a 33% increase in conversion rate after improving LCP, and multiple e-commerce case studies (vendor-published, and worth reading with the understanding that vendors publish their wins, not their non-results) report meaningful conversion gains after fixing severe Core Web Vitals failures specifically, not from chasing a perfect score. The pattern across credible case studies is consistent: the gains come from fixing genuinely bad performance, not from polishing an already-passing page.

Practical priorities for a small business site

For an ADMS client site, mobile network conditions in the Philippines make this more than a theoretical concern. Mobile download speeds vary widely by carrier and location; nationally, self-reported speed test data puts average Philippine mobile download speeds in the mid-40 Mbps range, and the Philippines has ranked in the lower half of Ookla's global mobile broadband index in recent standings. A meaningful share of any Philippine business's mobile visitors are on connections slow enough that an unoptimized, image-heavy homepage will genuinely struggle to hit a 2.5-second LCP, independent of anything to do with Google's algorithm.

In practice, this means: prioritize LCP first, since it's usually the hardest metric to pass and the one most affected by unoptimized images and slow hosting, both common issues on small business sites. Compress and correctly size hero images, since an uncompressed, full-resolution banner photo is one of the most common and easiest-to-fix LCP problems on a small business homepage. Avoid render-blocking scripts and unnecessary third-party embeds (chat widgets, tracking pixels, font loaders) stacked on top of each other. Don't chase a perfect Lighthouse score; once a page is passing all three thresholds in real-user data, further optimization has sharply diminishing returns for both rankings and, per the case study evidence above, for conversions.

Quick checklist

At minimum, check a site's Core Web Vitals status in Google Search Console's Core Web Vitals report (real-user CrUX data) rather than relying solely on a single PageSpeed Insights test. Fix any page failing LCP first, since it usually has the largest gap and the clearest fix (image size and hosting speed). Treat CLS issues (ads, embeds, or fonts loading late and shifting content) as the next priority, since they're often quick fixes. Don't treat a passing score as a ranking strategy on its own, and don't treat a failing score as something that alone explains a ranking drop; check content relevance and recent core updates first.

Changelog

August 2, 2026 — Guide published, covering LCP/INP/CLS definitions and current thresholds, the FID-to-INP transition, Google's on-the-record statements on ranking impact (Search Central documentation, John Mueller, Gary Illyes), the Ahrefs correlation study, and the distinction between ranking impact and conversion impact.