Core Web Vitals and SEO (What Actually Moves Rankings)

A client asked me last month whether fixing their Core Web Vitals scores would get them out of position 8 and into the top 3. The honest answer disappointed them: probably not by itself, but it’s still worth doing, and I’ll explain exactly why. This post covers what LCP, INP, and CLS actually measure, where Core Web Vitals really sit in Google’s ranking systems, what the data shows about the correlation with rankings, and how to fix each metric without turning it into a months-long project.

What Core Web Vitals Actually Measure

Core Web Vitals is a set of three metrics Google uses to quantify real-world page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Each one targets a different failure mode, not a general “speed score,” and that distinction matters because fixing the wrong one wastes time.

LCP measures how long it takes the largest visible element (usually a hero image or headline block) to render, and Google’s target is 2.5 seconds or less.

INP measures how quickly the page responds to a user’s interaction, click, tap, or keypress, with a target of 200 milliseconds or less. CLS measures unexpected visual movement, like a page jumping down because an ad or image loaded late, and the target is a score of 0.1 or less.

All three targets are measured at the 75th percentile of real page loads, across both mobile and desktop, according to Google’s own Core Web Vitals documentation.

That percentile detail matters more than most site owners realize: it means one in four of your visitors can have a worse experience than your reported score and you’d still technically “pass.” A site that looks fine in aggregate can still be genuinely slow for a meaningful chunk of its actual traffic, usually whoever’s on the weakest device or connection.

Metric	What It Measures	Good Threshold	Common Cause When It Fails
LCP	Loading speed of the largest content element	2.5s or less	Slow server response, unoptimized hero images, render-blocking CSS/JS
INP	Responsiveness to user interaction	200ms or less	Heavy JavaScript execution blocking the main thread
CLS	Visual stability during load	0.1 or less	Images/ads without reserved dimensions, late-injected banners, web fonts causing text reflow

Why Mobile and Desktop Scores Almost Never Match

Google scores Core Web Vitals separately for mobile and desktop, and I’ve never once audited a site where the two matched. Mobile almost always fails first, and usually fails hardest on LCP, because mobile devices combine slower processors with slower, less consistent network connections at the exact same time a desktop test doesn’t have to deal with.

This is where a lot of site owners get a false sense of security. If you’re checking your Core Web Vitals from a fast office connection on a desktop machine, you’re testing the best-case scenario, not the one Google actually weighs most heavily for a mobile-first index.

Google has indexed the mobile version of the web as its primary version for years now, which means your mobile Core Web Vitals numbers are the ones that matter most, even if most of your team only ever looks at the site on a laptop.

I always pull the mobile and desktop numbers separately in Search Console rather than trusting a single blended score, because averaging the two hides exactly the gap you need to see to prioritize the fix correctly.

Field Data vs. Lab Data (Why Your Lighthouse Score Never Matches Search Console)

This is the part that trips up almost everyone I’ve worked with the first time they see it: your Lighthouse or PageSpeed Insights score and your Google Search Console Core Web Vitals report can disagree, sometimes badly, and both can be “correct” at the same time.

Lighthouse runs a single simulated page load in a controlled lab environment. It’s useful for debugging exactly which resource is slow, but it’s a snapshot from one test run, not a representation of your real traffic. The number that actually feeds Google’s ranking systems is field data from the Chrome User Experience Report (CrUX), which aggregates real Chrome users visiting your pages over a rolling 28-day window.

That’s why a page can score green in Lighthouse and still show as “needs improvement” in Search Console: your test connection is faster than a meaningful share of your real visitors, especially anyone on a mid-range phone over a patchy mobile connection.

If you only ever check PageSpeed Insights and never open the Core Web Vitals report inside Search Console, or the raw CrUX dataset, you’re optimizing for a number Google doesn’t actually use for ranking.

The gap between the two also explains why a fix can “work” in a lab test the same afternoon you ship it, while Search Console still shows the page failing weeks later. The lab number changes instantly; the field number only changes once enough real visits accumulate on the new version of the page.

How INP Replaced FID (And Why the Switch Mattered)

Interaction to Next Paint didn’t always exist as a Core Web Vital. Before it, Google used First Input Delay (FID), which only measured the delay before the browser started processing a user’s first interaction on the page. INP became the official third Core Web Vital in 2024, replacing FID, and the difference is bigger than a name change.

FID only captured the very first interaction and only the delay before processing began; INP measures every interaction across the full page visit and captures the entire time from input to the next visual update on screen. A page could pass FID easily by responding fast to that first click and still feel sluggish on every interaction afterward, exactly the kind of janky, delayed-feeling page INP was built to catch.

For content-heavy or interactive pages, this matters more than it sounds. A page loaded with third-party scripts, chat widgets, comparison sliders, or heavy ad tech can pass FID comfortably while still failing INP badly, because FID never looked past that first click.

I’ve seen this exact pattern on sites running live odds widgets or embedded calculators: the first tap feels instant, but every interaction after that stacks more JavaScript onto an already-busy main thread, and INP is what finally exposes it.

Where Core Web Vitals Actually Sit in Google’s Ranking Algorithm

Google has been fairly direct about this, more direct than most SEO content gives them credit for. Its own page experience documentation states plainly: “Core Web Vitals are used by our ranking systems,” but immediately qualifies it.

Google Search always seeks to show the most relevant content, even if the page experience is sub-par.

Core Web Vitals function as a tiebreaker, not a primary ranking factor: Google explicitly states that page experience aspects beyond Core Web Vitals don’t directly help a page rank higher, and that relevance wins over experience every time there’s a conflict. Where it actually contributes is in genuinely competitive result sets, queries where multiple pages already cover the topic well and Google needs another signal to sort between them.

I’ve seen this distinction cause real confusion with clients who expect a Core Web Vitals fix to move a page that’s ranking on page 3 for a highly competitive term. It won’t, not because the metrics don’t matter, but because content relevance and topical authority are doing almost all of the work at that distance from the top of the results.

Core Web Vitals starts to matter once you’re already close, competing against two or three pages that are all roughly equally good on content.

It’s also worth knowing that “page experience” isn’t even a standalone ranking factor anymore the way it was originally framed back in 2021. Google retired the dedicated Page Experience report in Search Console and folded those signals into its core ranking systems as one input among many, rather than a bolt-on booster layered over the regular algorithm.

Google also retired the separate Mobile-Friendly Test tool and Mobile Usability report at the end of 2023, another sign that mobile-friendliness and Core Web Vitals are now treated as baseline table stakes inside the main ranking systems rather than a distinct signal you optimize in isolation.

Does It Apply Equally to Every Page Type on Your Site?

No, and this is where a lot of site-wide Core Web Vitals “fixes” go wrong. Google groups pages by URL pattern when it reports Core Web Vitals data, because a single average across an entire domain hides which templates are actually failing.

A blog template loaded with related-post widgets, comment plugins, and social share buttons will almost always score worse than a lean landing page on the same domain, even though they share the same hosting and the same theme. I’ve audited sites where the homepage passed every metric comfortably while the blog template failed CLS badly because of a comments plugin injecting content above the fold after the page had already rendered.

The practical implication is that you should check the Core Web Vitals report grouped by URL pattern in Search Console, not just the domain-wide summary, before deciding a fix is finished. Fixing the homepage does nothing for the hundreds of blog posts running a heavier template underneath it.

What the Data Actually Shows (Ahrefs’ Own Study)

Ahrefs ran one of the largest independent looks at Core Web Vitals passing rates, analyzing Core Web Vitals data across more than 43 million unique pages, with detailed Site Audit data pulled from 5.2 million of them. Only around 33% of websites passed Core Web Vitals thresholds on CrUX’s origin-level data, and just 21.2% passed at the individual page level in Ahrefs’ own Site Audit sample.

What I respect about that study is what it didn’t claim. Ahrefs explicitly said it couldn’t establish a conclusive link between passing Core Web Vitals and ranking position, because the rollout of the metrics overlapped with too many other algorithm changes to isolate the effect cleanly.

Their own framing was that a correlation between “sites that pass Core Web Vitals” and “sites that rank well” isn’t that different from noticing that sites which invest in SEO in general also tend to rank better; it doesn’t prove the specific metric caused the ranking.

That’s the honest state of the evidence, and it lines up with what Google itself says: Core Web Vitals is real, it’s used, and it’s genuinely not the lever most site owners hope it is when their real problem is thin content or weak topical coverage.

What the low passing rates do tell you is that most competitors haven’t bothered fixing this either, which is exactly why it still functions as a usable tiebreaker in a close race.

What I’ve Actually Seen Working Across iGaming, SaaS, and Fintech Sites

In my own work across iGaming, SaaS, and fintech clients, the sites with the worst Core Web Vitals scores are almost never failing because of anything exotic. They’re failing because of third-party scripts: live odds widgets, chat bots, consent management platforms, and marketing pixels stacked on top of each other, each one blocking the main thread a little more.

My take is that Core Web Vitals work pays off fastest as a hygiene fix, not a ranking hack: it protects conversion rate and reduces bounce on already-good content, and it removes one excuse Google has to rank a competitor over you in a close race.

I’ve never seen it single-handedly move a page from nowhere to page one, and I’d be skeptical of anyone who claims it did without controlling for a content or link change that happened at the same time.

One thing that’s genuinely different for multi-market sites: if you’re serving the same site to users across multiple countries or languages, your CrUX field data mixes visitors on very different connection quality and device tiers.

A site that scores well for a domestic audience with mostly fast broadband can still fail Core Web Vitals in aggregate once traffic from markets with slower average mobile connections is folded into the same origin-level report. Testing from a single location, or trusting a lab test run from your own office, will hide that entirely.

For fintech and iGaming clients specifically, regulatory-driven consent banners and identity checks tend to be the biggest CLS and INP offenders, because they’re often built by a compliance vendor with no incentive to optimize for page experience. I’ve had more success negotiating a lighter-weight consent script with the vendor than trying to code around a script I don’t control.

How to Actually Fix Each Metric

Fixing Core Web Vitals is rarely one change. It’s usually three or four smaller ones stacked together, specific to whichever metric is actually failing, and going after the wrong metric is the single biggest waste of a development sprint I see on this kind of work.

Fixing LCP

LCP failures almost always trace back to either a slow server or an unoptimized hero asset, so start there before touching anything else on the page.

• Compress and correctly size hero images, and serve modern formats like WebP or AVIF instead of unoptimized JPEGs
• Preload the LCP element (usually the hero image or headline font) instead of letting the browser discover it late in the loading sequence
• Reduce server response time (TTFB); a slow backend delays everything downstream, no matter how optimized the front end is
• Remove or defer render-blocking CSS and JavaScript that loads before the main content is visible

Fixing INP

INP is almost always a JavaScript problem, specifically too much of it running on the main thread at once, which is why the fixes below all aim at breaking that work up or moving it off the critical path.

• Break up long JavaScript tasks so the main thread isn’t blocked for hundreds of milliseconds at a time
• Defer or lazy-load third-party scripts (chat widgets, ad tech, analytics tags) that aren’t needed for the first interaction
• Avoid heavy work inside event handlers; move anything non-essential off the critical response path

Fixing CLS

CLS is usually the cheapest of the three to fix, because most of it comes down to telling the browser how much space to reserve before content actually loads.

• Always set explicit width and height attributes on images and embeds so the browser reserves space before they load
• Reserve space for ad slots and dynamically injected banners instead of letting them push content down after the fact
• Use font-display: optional or preload web fonts to avoid visible text reflow when a custom font swaps in

Tools for Monitoring This Over Time

A one-time audit tells you where you stand today; it doesn’t tell you when a new deploy quietly tanks your INP three weeks from now. The Core Web Vitals report inside Google Search Console is the free baseline every site should be checking monthly, because it’s built directly on the same field data Google’s ranking systems use, not a lab simulation.

Beyond that, the raw CrUX dataset is available through Google’s public BigQuery project if you want to pull historical trends or compare yourself against competitors at scale, though that’s overkill for most single-site owners.

PageSpeed Insights is still the fastest way to get a quick lab-plus-field snapshot for one URL, and Chrome DevTools’ Performance panel is where I actually go to find which specific script is blocking the main thread once I already know INP is the problem.

For any site where Core Web Vitals genuinely affects revenue, like a checkout flow or a lead form, I’d rather catch a regression the week it ships than the month it shows up in a quarterly report, which is the real argument for setting up an alert on the Search Console report rather than checking it manually.

A Quick-Reference Checklist

If you’re triaging a site with mixed results, this is roughly the order I work through it in, from highest impact to lowest for most sites I’ve audited.

Step	Action	Where to Check It
1	Open the Core Web Vitals report in Search Console, not just PageSpeed Insights	Google Search Console
2	Identify which of the three metrics is actually failing at the 75th percentile, and on mobile specifically	Search Console / CrUX dashboard
3	Audit third-party scripts first if INP is the failure	Chrome DevTools Performance panel
4	Check hero image size and server response time if LCP is the failure	PageSpeed Insights
5	Check for missing image/embed dimensions if CLS is the failure	PageSpeed Insights, live page inspection
6	Re-test with real field data after 28 days, not immediately	CrUX / Search Console

That last step catches people constantly: field data only updates on a rolling basis, so a fix you shipped yesterday won’t show up as “passing” in Search Console for weeks.

Judging a fix by tomorrow’s Lighthouse score instead of waiting for the field data to catch up is one of the most common mistakes I see teams make, and it usually leads to someone declaring victory too early or, worse, reverting a genuinely good fix because the number didn’t move overnight.

My Take: Fix It, But Don’t Expect a Rankings Miracle

Core Web Vitals is worth fixing on every site I work on, and I do it as standard practice, but I stopped selling it as a rankings lever a long time ago.

The realistic value of Core Web Vitals work is as a tiebreaker and a conversion-rate improvement, not a primary path to more organic traffic, and treating it as anything bigger than that sets the wrong expectation with a client or a boss who’s watching a rankings dashboard.

If your content is genuinely thin, or you haven’t earned topical authority on the subject yet, spend your time there first. Come back to Core Web Vitals once you’re already competing at the level where every other signal is close, because that’s exactly the scenario Google built it to break ties in.

For more on what actually earns that ranking authority in the first place, I’ve written a plain breakdown of how organic search rankings actually get built from the ground up.

I’m an SEO specialist who’s spent the last 6+ years watching clients chase the wrong lever for a ranking problem, and Core Web Vitals is one of the most common ones. Fix it because it’s good practice, not because it’s a shortcut.