All subjects

Core Web Vitals

27 established claims - 7 refused by the grounding gate

Verdict

On March 12 2024, Interaction to Next Paint became a stable Core Web Vital metric, replaced First Input Delay, and Chrome stated it was officially deprecating FID support; Chrome tools would no longer guarantee FID availability, and developers were told they had until September 9 2024 to transition. The current set focuses on loading, interactivity, and visual stability, with documented thresholds of LCP 2.5 seconds or less, CLS 0.1 or less and poor above 0.25, and INP 200 ms or less and poor above 500 ms; a page passes if it meets all three recommended targets at the 75th percentile, using the same thresholds for mobile and desktop. As of December 10 2025, Google states that Core Web Vitals are used by its ranking systems, but good results in Search Console or third-party tools do not guarantee top rankings, and trying for a perfect score solely for SEO may not be the best use of time.

Written from the 27 established claims below, then checked against them. How that works.

Documented position14

What the operator of the system says in its own documentation.

Google's documentation page 'Understanding page experience in Google Search results' states that Core Web Vitals are used by Google's ranking systems.

first-party
2 quotes from 1 source
What aspects of page experience are used in ranking?
Core Web Vitals are used by our ranking systems.

The web.dev article on Largest Contentful Paint states that a good LCP value is 2.5 seconds or less.

first-party
2 quotes from 1 source
To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less.
A good LCP value is 2.5 seconds or less.

The web.dev article on Interaction to Next Paint states that an INP below or at 200 milliseconds means a page has good responsiveness.

first-party
1 quote from 1 source
An INP below or at 200 milliseconds means a page has good responsiveness .

The web.dev article on Interaction to Next Paint states that an INP above 500 milliseconds means a page has poor responsiveness.

first-party
1 quote from 1 source
An INP above 500 milliseconds means a page has poor responsiveness .

The web.dev article on Interaction to Next Paint states that one highest interaction is ignored for every 50 interactions when reporting the metric.

first-party
1 quote from 1 source
To give a better measure of the actual responsiveness for pages with a high number of interactions, we ignore one highest interaction for every 50 interactions.

The web.dev article "Defining the Core Web Vitals metrics thresholds" states that taking into consideration the 100 ms threshold supported by research and the achievability criteria, 200 ms is a reasonable threshold for good experiences.

first-party
1 quote from 1 source
Taking into consideration the 100 ms threshold supported by research into the quality of experience and the achievability criteria, we conclude that 200 ms is a reasonable threshold for good experiences

The web.dev article "Defining the Core Web Vitals metrics thresholds" states that the 75th percentile was concluded to strike a reasonable balance between covering most visits and limiting the influence of outliers.

first-party
1 quote from 1 source
Given these goals are a bit at odds, after analysis, we concluded that the 75th percentile strikes a reasonable balance. By using the 75th percentile, we know that most visits to the site (3 of 4) experienced the target level of performance or better. Additionally, the 75th percentile value is less likely to be affected by outliers.

The web.dev article 'Defining the Core Web Vitals metrics thresholds' states that the…

  • recommended Core Web Vitals thresholds are not segregated by device.
  • same threshold is used for mobile and desktop.
first-party
1 quote from 1 source
However, users' expectations of a good or poor experience is not dependent on device, even if the achievability criteria is. For this reason the Core Web Vitals recommended thresholds are not segregated by device and the same threshold is used for both.

The web.dev 'Web Vitals' article states that a page should be considered passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics.

first-party
1 quote from 1 source
Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics.

The web.dev "Web Vitals" article states that the current set of Core Web Vitals focuses on three aspects of the user experience: loading, interactivity, and visual stability.

first-party
1 quote from 1 source
The metrics that make up Core Web Vitals will evolve over time. The current set focuses on three aspects of the user experience— loading , interactivity , and visual stability —and includes the following metrics (and their respective thresholds):

The web.dev 'Web Vitals' article states that stable Core Web Vitals metrics will not change more than once per year.

first-party
1 quote from 1 source
Stable metrics are actively supported, and can be subject to bug fixes and definition changes. Stable Core Web Vitals metrics won't change more than once per year.

The web.dev article on Cumulative Layout Shift states that good CLS values are 0.1 or less.

first-party
2 quotes from 1 source
To provide a good user experience, sites should strive to have a CLS score of 0.1 or less.
Good CLS values are 0.1 or less.

The web.dev article on Cumulative Layout Shift states that poor CLS values are greater than 0.25.

first-party
1 quote from 1 source
Good CLS values are 0.1 or less. Poor values are greater than 0.25.

Measured finding5

Something someone actually measured, with the method attached.

The web.dev article 'Defining the Core Web Vitals metrics thresholds' states that a candidate good threshold is confirmed achievable only if at least 10% of origins meet it in Chrome User Experience Report data.

first-party
1 quote from 1 source
When evaluating candidate Core Web Vitals "good" thresholds, we verify that those thresholds are achievable, based on data from the Chrome User Experience Report (CrUX). To confirm that a threshold is achievable, we require that at least 10% of origins meet the "good" threshold.

The web.dev article "Defining the Core Web Vitals metrics thresholds" states that by default the worst-performing 10-30% of origins are classified as poor when no relevant research is available for defining a poor threshold.

first-party
1 quote from 1 source
Conversely, we establish the "poor" threshold by identifying a level of performance that only a minority of origins are not meeting. Unless there is research available relevant to defining a "poor" threshold, by default the worst-performing 10-30% of origins are classified as "poor".

The web.dev article 'Defining the Core Web Vitals metrics thresholds' states that research points to 100 ms as a good Interaction to Next Paint threshold.

first-party
1 quote from 1 source
Given this, we conclude that research points to 100 ms as a "good" Interaction to Next Paint threshold for Web Vitals. Additionally, given users reported low quality levels for delays of 300 ms or more, ideally this would be the "poor" threshold.

The web.dev article "Defining the Core Web Vitals metrics thresholds" states that 23% of sites pass the 200 ms INP good threshold on mobile.

first-party
1 quote from 1 source
It should also be noted that the 200 ms "good" threshold is also tougher for these sites, but with 23% of sites still passing this on mobile this still passes our 10% minimum pass rate criteria.

The Google Ad Manager blog post "The need for mobile speed." states that 53% of visits are likely to be abandoned if pages take longer than 3 seconds to load.

first-party
1 quote from 1 source
53% of visits are likely to be abandoned if pages take longer than 3 seconds to load 6

Practical effect3

What is observed to happen in practice, as distinct from what is documented.

Google's documentation page "Understanding page experience in Google Search results" states that getting good results in reports like Search Console's Core Web Vitals report or third-party tools does not guarantee that pages will rank at the top of Google Search results.

first-party
1 quote from 1 source
Keep in mind that getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results; there's more to great page experience than Core Web Vitals scores alone.

Google's documentation page "Understanding page experience in Google Search results" states that trying to get a perfect score just for SEO reasons may not be the best use of a site owner's time.

first-party
1 quote from 1 source
These scores are meant to help you to improve your site for your users overall, and trying to get a perfect score just for SEO reasons may not be the best use of your time.

Google's documentation page "Understanding page experience in Google Search results" states that page experience aspects beyond Core Web Vitals do not directly help a website rank higher in search results.

first-party
1 quote from 1 source
Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results. However, they can make your website more satisfying to use, which is generally aligned with what our ranking systems seek to reward.

Changed on4

A dated change. This is where advice quietly stops being true.

A web.dev blog post dated March 12 2024 announced that Interaction to Next Paint had become a stable Core Web Vital metric.

first-party
2 quotes from 1 source
Today's the day! After years of work, we're finally ready to make Interaction to Next Paint (INP) a stable Core Web Vital metric. This marks a significant step forward in the way we measure interaction responsiveness, addressing many of the shortcomings of First Input Delay (FID) .
Last updated 2024-03-12 UTC.

The web.dev blog post about the INP launch states that…

  • INP has replaced FID as a Core Web Vital metric.
  • Chrome is officially deprecating support for FID.
first-party
1 quote from 1 source
Now that INP has replaced FID as a Core Web Vital metric, Chrome is officially deprecating support for FID.

A web.dev blog post about the INP launch states that developers had until September 9, 2024 to transition over to INP.

first-party
1 quote from 1 source
What this means is that Chrome tools will no longer guarantee FID availability and developers will have until September 9, 2024 to transition over to INP.

Echoed without a primary source1

Widely repeated in the field, but traceable only to other repetitions. Listed because knowing something is merely echoed is worth as much as knowing it is documented.

The websitespeedy.com article "Why 53% of Mobile Users Abandon Sites That Take Over 3 Seconds to Load" states that recent research by Google revealed that 53% of mobile users abandon sites that take over 3 seconds to load.

medium confidenceother
2 quotes from 1 source
The recent research by Google revealed that 53% Of Mobile Users Abandon Sites That Take Over 3 Seconds To Load.
TL;DR: A research by Google reveals that 53% of mobile users leave sites that take more than 3 seconds to load. This increases the bounce rate of a site and harms user experience. You can focus and boost your Core Web Vitals and optimize your site for mobile devices, as more traffic is coming from mobile devices nowadays.

Refused7

Claims the research produced that the grounding gate would not accept, with its reason. They are here because a site that only shows what passed gives you no way to judge whether the gate does anything.

Show what was refused

Core Web Vitals, according to Google's documentation page 'Understanding page experience in Google Search results', has no single page experience signal that Google Search uses for ranking.

Refused: The quotes establish that there is no single page experience signal, but they do not mention Core Web Vitals.

Unsupported: Core Web Vitals

What it rested on
Is there a single "page experience signal" that Google Search uses for ranking?
There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.

Core Web Vitals' documented position, as stated in Google's documentation page "Understanding page experience in Google Search results", is that Google Search always seeks to show the most relevant content even if the page experience is sub-par.

Refused: The quote states a page-experience principle but never mentions Core Web Vitals, so attributing it specifically as Core Web Vitals' documented position overreaches.

Unsupported: Core Web Vitals' documented position

What it rested on
Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.

The Google Ad Manager blog post "The need for mobile speed." sources Core Web Vitals' 53% abandonment figure to aggregated, anonymized Google Analytics data.

Refused: The quote identifies the data source but does not mention Core Web Vitals or a 53% abandonment figure.

Unsupported: Core Web Vitals' 53% abandonment figure

What it rested on
6 Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016

The Google Analytics data for Core Web Vitals' 53% abandonment figure comes from a sample of mWeb sites opted into sharing benchmark data.

Refused: The quote describes a sample of mWeb sites opted into sharing benchmark data but does not mention Core Web Vitals or the 53% abandonment figure.

Unsupported: Core Web Vitals' 53% abandonment figure

What it rested on
6 Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016

The sample for Core Web Vitals' 53% abandonment figure is global, has n=3.7K, and is from March 2016.

Refused: The quote states the n, global scope, and date but does not mention Core Web Vitals or a 53% abandonment figure.

Unsupported: the sample for Core Web Vitals' 53% abandonment figure

What it rested on
6 Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016

Core Web Vitals has an average load time of 19 seconds for mobile sites over 3G connections, as reported by the Google Ad Manager blog post 'The need for mobile speed.'

Refused: The quote states the average mobile site load time over 3G is 19 seconds, but it never mentions Core Web Vitals.

Unsupported: Core Web Vitals

What it rested on
Unfortunately, based on our analysis of 10,000+ mobile web domains, we found that most mobile sites don't meet this bar: the average load time for mobile sites is 19 seconds over 3G connections. 1

Core Web Vitals' average load time is based on an analysis of 10,000+ mobile web domains, as reported by the Google Ad Manager blog post 'The need for mobile speed.'

Refused: The quote mentions average mobile-site load time from 10,000+ domains but never ties it to Core Web Vitals.

Unsupported: Core Web Vitals' average load time

What it rested on
Unfortunately, based on our analysis of 10,000+ mobile web domains, we found that most mobile sites don't meet this bar: the average load time for mobile sites is 19 seconds over 3G connections. 1