How Do Core Web Vitals Affect SEO and Rankings?

Ever since Google announced them in 2020, Core Web Vitals have been one of the most discussed and most misunderstood topics in SEO. One camp says speed is everything; the other says the ranking effect is negligible. As Google's own documentation makes clear, the truth sits somewhere in between.

This article explains how Core Web Vitals relate to SEO, based on Google's official guidance: what the three metrics measure, where the thresholds come from, why field and lab data disagree, and how much time the work actually deserves.

What are Core Web Vitals?

Core Web Vitals are a set of metrics that measure three core aspects of the experience real users have on a page:

• LCP (Largest Contentful Paint): Loading. Measures when the largest image or text block in the viewport is rendered.
• INP (Interaction to Next Paint): Responsiveness. Measures how long the page takes to paint the next frame after clicks, taps and key presses. INP replaced First Input Delay (FID) as a Core Web Vital in 2024.
• CLS (Cumulative Layout Shift): Visual stability. Measures unexpected movement of content while the page loads or is being used.

Thresholds

According to web.dev's thresholds article, values fall into three bands:

The key detail: these thresholds apply to the 75th percentile of page loads, not a single visit, and mobile and desktop are assessed separately. In other words, a page is "good" only if at least three out of four visits stay under the threshold. web.dev's Web Vitals overview adds that a page passes only when it meets the target at the 75th percentile for all three metrics.

Do Core Web Vitals affect rankings?

Short answer: yes, but in a limited, context-dependent way. Here is what Google's page experience documentation says:

• Core Web Vitals are used by ranking systems. Google states this plainly and recommends that site owners achieve good Core Web Vitals.
• There is no single "page experience signal". Core ranking systems look at a variety of signals that align with overall page experience.
• Good scores do not guarantee top rankings. Good results in Search Console's report or third-party tools do not mean a page will rank at the top.
• Relevance comes first. Google tries to show the most relevant content even if its page experience is sub-par. But for many queries there is plenty of helpful content available, and in those cases a great page experience can contribute to success.
• Perfect scores are rarely the best use of time. Google explicitly says that chasing a perfect score purely for SEO may not be the best use of your time.

In practice: if your content is as relevant and useful as your competitors', page experience is one of the things that can make a difference. If your content does not match the search, a fast page will not close that gap.

Page-level or site-wide?

Google says its core ranking systems generally evaluate content page by page, while some site-wide assessments also exist. The practical takeaway is to treat each main template (product page, category, blog post) separately rather than staring at one site-wide score.

Field data vs lab data

This is where most of the confusion comes from. PageSpeed Insights shows both a "real user experience" section and a performance score, and they often disagree.

• Field data: Collected from real Chrome users visiting your site. The Chrome UX Report (CrUX) is the public source for this data and reflects a rolling 28-day window. Search Console's Core Web Vitals report is also based on field data.
• Lab data: Measured by tools such as Lighthouse by simulating a single page load with predefined device and network settings. Because it is reproducible, it is invaluable for debugging.

web.dev's article on the difference explains why the two diverge: real users have different devices, networks, cache states, navigation patterns and entry points than a lab test. INP also depends on real user interactions, so a lab run may not capture it the same way.

Which one to trust? Use field data to understand what users actually experience and what Google evaluates; use lab data to find the cause and test the fix.

What if there is no field data?

CrUX only publishes data for pages and origins with enough visits. A new or small site with little traffic may have no CrUX data at all. In that case, fixing obvious issues with lab tests and waiting for field data to build up as traffic grows is a sensible approach.

Common causes and where to look first

If LCP is slow

• The hero image is too large, uncompressed or discovered late (for example, as a CSS background or injected by JavaScript)
• High server response time (TTFB)
• The LCP element is lazy-loaded
• Too much render-blocking CSS and JavaScript

Detailed guide: web.dev on optimising LCP.

If INP is high

• Long JavaScript tasks that keep the main thread busy
• Many third-party scripts (chat widgets, ads, analytics tags)
• Large DOM updates after an interaction

Detailed guide: web.dev on optimising INP.

If CLS is high

• Images, videos and iframes without dimensions
• Ad slots and banners injected late
• Web fonts that load late and shift text
• Notification bars inserted above existing content

Detailed guide: web.dev on optimising CLS.

Prioritising: how much effort is worth it?

Taking Google's "don't chase perfect scores" advice seriously, we suggest this order:

1. Find templates in the "poor" band. Start with page groups rated poor, especially the ones that bring traffic and conversions.
2. Prioritise mobile. Mobile and desktop are assessed separately, and mobile devices usually face tougher conditions. For more on device differences, see mobile vs desktop rankings.
3. Aim for "good", then stop. Taking LCP from 2.4 seconds to 1.2 seconds may be nice for users, but spending that time on content or internal linking usually pays off more.
4. Confirm the change in field data. Because CrUX looks at a 28-day window, the effect of a fix shows up gradually over several weeks.

Before blaming Core Web Vitals for a ranking drop

It is tempting to blame a ranking drop on Core Web Vitals because they are measurable and concrete. But the cause usually lies elsewhere: relevance, a competitor's update, an algorithm update, an indexing issue or lost links. A sudden multi-position drop caused by Core Web Vitals alone, especially on a highly relevant page, is not a scenario Google's documentation leads you to expect. Work through our Google ranking drop checklist first.

Likewise, speed cannot hide content problems: pages that give users little value remain a problem however fast they load. Our guide to thin content and zombie pages can help there.

Monitoring Core Web Vitals over time

A one-off test is a snapshot. A new plugin, ad script or theme update can change the numbers overnight, so monitoring needs to be regular:

• Search Console Core Web Vitals report: Groups URLs as good, needs improvement or poor.
• PageSpeed Insights: Shows CrUX field data and a Lighthouse lab result side by side for a single URL.
• Our free Core Web Vitals checker: Lets you quickly check a URL's LCP, INP and CLS against the thresholds.

The SEOLOK SEO site audit pulls your site's Core Web Vitals field data from the Chrome UX Report every day and shows how it changes over time, noting that sites without enough traffic may have no CrUX data. When values are poor, an "improve Core Web Vitals" action is added to your to-do list. For how to present these metrics in a monthly report, see which metrics belong in an SEO report.

Quick checklist

• I looked at field data (CrUX / Search Console) and lab data separately
• I assessed mobile and desktop separately
• I ranked "poor" templates by traffic and conversions
• I identified the LCP element, long JavaScript tasks and shifting elements
• I set "good" as the target
• I monitored field data for several weeks after the fix

The healthiest way to think about Core Web Vitals is not as a ranking trick but as a measure of how people experience your site. Whatever the ranking effect, a page that loads quickly, responds to taps without delay and does not jump around while someone reads is simply a page that respects its visitors.