Core Web Vitals in 2026: Which Scores Still Move Rankings and Which Google Stopped Rewarding

Core Web Vitals Were Never a Primary Ranking Factor

Let's start with the thing most SEO content refuses to say plainly: Core Web Vitals have never been a primary ranking factor. Google has said this repeatedly and consistently. A fast site with thin, unhelpful content still loses to a slow site with the best content on the topic. Treating CWV as a magic lever that will push you up the rankings is a mistake, and it's a mistake a remarkable number of site owners and agencies still make.

The confusion is understandable. When Google introduced Core Web Vitals in 2020 and rolled them into the page experience signal in 2021, the SEO industry reacted as though a new ranking gold rush had started. Agencies sold "Core Web Vitals optimisation" as a service. Blog posts promised that fixing your CLS would jump you three positions. Tooling companies built entire dashboards around the three metrics. The reality was always more modest.

Google's own language has been careful and consistent: Core Web Vitals are a tiebreaker. If two pages are roughly equal on relevance, authority, and content quality, the one with better page experience signals may get the edge. That is a narrow scenario, and it means CWV optimisation is the last thing you reach for, not the first. Get your content right, get your technical foundation right, get your internal linking right, and then worry about whether your LCP is 2.4 seconds or 2.6 seconds.

The "fix CWV and rankings will follow" trap

We have taken over accounts where the previous agency spent months chasing all-green Core Web Vitals scores while the site's content was thin, the internal linking was broken, and key commercial pages had no schema markup. The CWV scores were perfect. The rankings were not. Performance optimisation is real work, but it does not substitute for the fundamentals, and treating it as a shortcut is how budgets get burned on the wrong things.

What Changed: FID Is Gone, INP Replaced It

If you optimised Core Web Vitals back in 2021 or 2022, you were working with three metrics: LCP (Largest Contentful Paint), FID (First Input Delay), and CLS (Cumulative Layout Shift). Of those three, one no longer exists. Google replaced FID with INP (Interaction to Next Paint) as a stable Core Web Vital in March 2024.

The change matters because FID and INP measure different things, and a site that was comfortably green under FID may now be amber or red under INP without anything on the site having actually gotten worse. Understanding the difference is the first step to understanding why your scores shifted.

FID (retired March 2024)

Measured the delay between a user's first interaction (click, tap, keypress) and the browser beginning to process it. Only counted the first input on the page. For most content-heavy sites, the first input happened after the page had finished loading, so FID was almost always low. It was, in hindsight, a metric that was easy to pass and hard to fail.

INP (current metric)

Measures the full latency of all interactions throughout the page lifecycle, not just the first one. It captures the time from input to the next paint, which includes processing time plus the time to render the visual response. A page can have a fast first input and a catastrophically slow second or third one. INP catches that. FID did not.

The practical consequence: sites with heavy JavaScript, interactive widgets, or slow event handlers that looked fine under FID now show their real interaction latency. A page where clicking a menu, opening an accordion, or submitting a form takes 400ms to respond is now flagged, where before it sailed through. If your INP score dropped and you cannot figure out why, the answer is almost certainly that FID was hiding a problem INP now exposes.

LCP and CLS remain unchanged. LCP still measures how long the largest visible element takes to render. CLS still measures how much the visible page layout shifts around while loading. The thresholds for those two have been stable since launch. Only the interaction metric changed.

The Current Thresholds (and Why Your Green Score May Have Turned Amber)

Google evaluates Core Web Vitals using field data, which means real user measurements collected through the Chrome User Experience Report, not lab simulations. This is an important distinction. A lab tool like Lighthouse might show your LCP as 1.8 seconds on a fast connection with a powerful device, while real users on mid-range phones on 4G are experiencing 3.5 seconds. Google ranks on the field data, not the lab score.

The thresholds Google uses for the page experience signal, as of 2026:

Metric	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	≤ 2.5s	2.5s to 4.0s	> 4.0s
INP (Interaction to Next Paint)	≤ 200ms	200ms to 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1 to 0.25	> 0.25

If your site was all-green in 2022 and is now showing amber on INP, this is almost certainly the FID-to-INP transition, not a regression you caused. The old FID threshold for "good" was 100ms, and most sites passed it easily. The INP threshold for "good" is 200ms, which sounds more generous, but INP measures every interaction on the page, not just the first one. A single slow click anywhere in the session can push your INP into the amber band.

The other common reason scores shift is traffic composition changes. Field data is aggregated from real Chrome users over a rolling 28-day window. If your audience shifted toward more mobile users, more users on slower devices, or more users on slower connections, your field data scores will reflect that even if your code has not changed. This is why chasing a specific lab score is less useful than understanding what your real users are experiencing.

Where Core Web Vitals Genuinely Matter (Hint: Not the SERP)

Here is the part most CWV content skips: the business case for fixing performance is not a ranking boost. It is retention and conversion. A 4-second LCP does not just cost you a fraction of a ranking signal. It costs you the visitor who left before the page finished loading. That is a much bigger and much more measurable number.

The data on this has been consistent across every industry we have worked in: faster pages retain more visitors, and more retained visitors means more conversions. The relationship is not subtle. When a page's LCP drops from 4 seconds to 2 seconds, bounce rate drops, time on page rises, and conversion rate improves. Not because Google rewarded you, but because fewer people gave up waiting.

CLS is the same story in a different form. A page that shifts its layout as it loads is not just failing a Core Web Vitals check. It is causing visitors to misclick, lose their place in an article, or lose trust in the site. A user who clicks a button and the button moves out from under their finger at the last millisecond is a user who has just had a bad experience, and they remember it.

INP is the most directly commercial of the three. If a user clicks "Add to Cart" or "Submit" and nothing happens for 600ms, they click again. They wonder if the site is broken. Some of them leave. The conversion cost of a slow interaction is immediate and concrete, and it has nothing to do with whether Google bumps you up a position.

The honest framing

If you are making the case to invest in performance work, do not make it on rankings. Make it on the visitors you are losing before the page loads, the clicks that are not registering, and the trust that erodes every time the layout jumps. Those numbers are real, measurable, and usually larger than any ranking signal CWV provides. The ranking benefit, if it comes, is a bonus on top of the actual business benefit.

The Scores Worth Chasing and the Ones to Deprioritise

Not all Core Web Vitals work is equal. Some fixes produce real, visible improvements for your users. Others are diminishing returns that eat time better spent on content, internal linking, and conversion work. Here is how we prioritise.

Worth chasing: LCP under 2.5 seconds (field data)

This is the metric with the clearest user-experience payoff. If your largest visible element takes more than 2.5 seconds to render on real user connections, people are leaving. The fixes are usually concrete and high-impact: optimise and preload your hero image, defer non-critical JavaScript, use a CDN, and server-cache your HTML where possible. Getting LCP from 4 seconds to 2.5 seconds is work that pays for itself in retained visitors, regardless of any ranking effect.

Worth chasing: INP under 200ms

INP problems are usually caused by long JavaScript tasks blocking the main thread when a user interacts with the page. The fixes: break up long tasks, defer third-party scripts that do not need to run on interaction, and audit your event handlers for synchronous work that could be moved off the main thread. If your forms, menus, or interactive elements feel sluggish, fixing INP directly improves the experience of the people who are already engaged enough to interact, which is your highest-intent audience.

Worth chasing: CLS under 0.1

Layout shift is the most fixable of the three and the one with the most obvious user-experience symptom. Reserve space for images and embeds before they load (set width and height attributes, or use aspect-ratio CSS). Avoid injecting banners or popups that push content down. Make sure font loading does not cause text to reflow. These are straightforward fixes with immediate, visible results.

Deprioritise: optimising past the "good" threshold

Once your LCP is under 2.5 seconds, your INP is under 200ms, and your CLS is under 0.1, stop. The ranking benefit of going from 2.4 seconds to 1.9 seconds is negligible, and the engineering effort to squeeze out those last few hundred milliseconds is usually better spent on content, internal linking, or conversion work. Diminishing returns set in fast past the "good" threshold. Do not let perfect become the enemy of good enough.

Deprioritise: lab-score chasing when field data is already green

If your field data (real user data from the Chrome User Experience Report, visible in Google Search Console and PageSpeed Insights) is all green, but Lighthouse in the lab shows amber, do not panic. Google ranks on field data. Lab tools run on a simulated device and connection that may not represent your actual users. A lab amber score with green field data is not a problem that needs fixing.

The short version: fix the things that are genuinely slow for real users, stop when you hit the "good" thresholds, and move on to the work that moves rankings (content, authority, relevance). Performance is table stakes, not a competitive advantage, once you are in the green band.

How to Monitor Without Becoming a Performance Engineer

The problem with Core Web Vitals is not that they are hard to measure. Google Search Console gives you field data for free. PageSpeed Insights gives you both field and lab data. The problem is that nobody checks them often enough, and when a regression happens, it goes unnoticed for weeks.

Here is what typically goes wrong. A developer adds a new third-party script (a chat widget, a tracking pixel, an embedded video). The script adds 300ms to LCP or introduces a layout shift. Nobody notices because the CWV report is not part of anyone's weekly routine. The regression sits there for a month, quietly degrading the experience of every visitor, until someone happens to run a PageSpeed test and sees the damage.

The fix is not to become a performance engineer. The fix is to set up automated monitoring that flags regressions against Google's thresholds the day they happen, not the day someone remembers to check. This is one of the automated workflows we build for SEO clients: scheduled checks against your field data, with an alert when a metric crosses from "good" into "needs improvement" or "poor." You find out a layout change broke your CLS before it affects a month of visitors.

The same principle applies to the other side of performance monitoring: knowing when a score is not worth investigating. If your field data is green and stable, an automated check that confirms "nothing changed" is just as valuable as one that flags a regression. It means you can spend your time on content and strategy without wondering whether something quietly broke.

The honest caveat

Alerts only help if someone acts on them. An alert that says "your INP regressed to 280ms" is useless if nobody knows what to do about it. The monitoring is the easy part. Having someone who can diagnose the cause and fix it is the part most sites do not have. That is where ongoing technical SEO support earns its keep, not in the initial audit but in catching and fixing the regressions that happen every time someone adds a script or changes a layout.

Frequently Asked Questions

Do Core Web Vitals still affect rankings in 2026?

Yes, but only as a tiebreaker, which is what they have always been. Google has not elevated Core Web Vitals to a primary ranking signal. If two pages are roughly equal on relevance, content quality, and authority, the one with better page experience signals may get the edge. That is a narrow scenario. For most sites, the ranking impact of CWV optimisation is small compared to the impact of improving content, fixing technical issues, and building authority. The bigger business case for performance is retention and conversion, not rankings.

My Core Web Vitals were all green and now INP is amber. Did my site get worse?

Probably not. The most likely explanation is the FID-to-INP transition in March 2024. FID only measured the first input on a page, which most sites passed easily. INP measures every interaction throughout the page lifecycle, so it catches slow event handlers that FID missed. Your site did not get worse; the metric got more honest. The fix is to audit your JavaScript event handlers for long tasks that block the main thread, particularly on interactive elements like menus, forms, and accordions.

Should I use lab data or field data to guide my optimisation?

Field data, which is real user measurements from the Chrome User Experience Report, is what Google uses for the page experience signal. It is visible in Google Search Console and in the field data section of PageSpeed Insights. Lab data, from Lighthouse or similar tools, runs on a simulated device and connection and is useful for diagnosing the cause of a problem, but it does not always match what your real users experience. If your field data is green and your lab data is amber, you are fine. If your field data is red, use lab tools to figure out why, but do not optimise toward lab scores alone.

How fast is fast enough? When should I stop optimising?

Stop when your field data is in the "good" band for all three metrics: LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1. Past those thresholds, the ranking benefit of further optimisation is negligible and the engineering effort is better spent on content, internal linking, and conversion work. Performance is table stakes once you are green. It is not a competitive advantage to have an LCP of 1.5 seconds instead of 2.4 seconds, and the time it takes to close that gap is rarely worth it.

My Lighthouse score is low but my Search Console data looks fine. Should I worry?

No. Lighthouse runs on a simulated mid-range device with a throttled connection that may not represent your actual audience. If your Search Console Core Web Vitals report shows green, your real users are having a good experience. Use Lighthouse to diagnose specific issues when field data flags a problem, but do not treat a lab amber score as a crisis when field data is healthy. Google ranks on field data, not lab data.

Do you need to manage our site to monitor Core Web Vitals?

No. We can set up automated monitoring as part of an SEO retainer without taking over your development. The monitoring flags regressions against Google's thresholds so they get caught the day they happen, not at the next monthly review. If a regression needs a code fix, we will tell you what changed and what needs fixing, and your own developers can implement it. The value is in catching the problem early and diagnosing it accurately, not in owning the fix.

Core Web Vitals in 2026:
Which Scores Still Move Rankings

In This Article