Short answer
The three Core Web Vitals are Largest Contentful Paint (good at 2.5 seconds or less), Interaction to Next Paint (good at 200 milliseconds or less) and Cumulative Layout Shift (good at 0.1 or less). Google judges each at the 75th percentile of page loads, separately for mobile and desktop.
Why these three metrics exist
For years, website speed was measured with technical timings that meant little to visitors, such as when the HTML finished downloading. Core Web Vitals were designed to describe the experience instead. Each covers a different moment: the wait for content, the wait after you tap something, and the frustration of a page that moves while you read it. web.dev describes them as the subset of Web Vitals that apply to all web pages [1].
Largest Contentful Paint (loading)
Largest Contentful Paint, or LCP, measures how long it takes for the largest image or block of text in the viewport to appear. It is a proxy for "the main content is here". web.dev's guidance is that "LCP should occur within 2.5 seconds of when the page first starts loading" [1].
The LCP element is often a hero image, a product photo or a large heading. HTTP Archive's 2024 Web Almanac, as cited by web.dev, found that 73% of mobile pages have an image as their LCP element [2], which is why image delivery comes up so often in speed work. web.dev divides LCP into four stages, starting with the server response and ending with the moment the element is drawn [3]. If you know which part is too long, you know where to look.
| Subpart | What it measures | Usual cause when it is long |
|---|---|---|
| Time to first byte | Until the first byte of HTML arrives | Slow server, no page cache, no CDN |
| Resource load delay | Gap before the main image starts downloading | Image found late, for example set in CSS or lazy-loaded |
| Resource load duration | Time spent downloading the main image | Oversized or poorly compressed file |
| Element render delay | Gap between download and display | Render-blocking CSS, fonts or scripts |
Interaction to Next Paint (responsiveness)
Interaction to Next Paint, or INP, measures how quickly the page shows a visual response after a click, tap or key press. It looks at interactions throughout the visit, not just the first one. web.dev says "pages should have a INP of 200 milliseconds or less" [1].
Google swapped First Input Delay out for INP on March 12, 2024 [4]. FID only measured the delay before the first interaction's handler started; INP covers the whole time until the next frame is painted, which makes it a stricter and more realistic test. An interaction has three phases: input delay, processing duration and presentation delay [5]. Most INP problems come from JavaScript keeping the main thread busy. Our INP guide goes into the fixes.
Cumulative Layout Shift (visual stability)
Cumulative Layout Shift, or CLS, measures how much visible content moves unexpectedly while the page is in use. A score of 0 means nothing moved; pages should maintain a CLS of 0.1 or less [1]. Shifts that happen shortly after a visitor interacts are treated as expected: web.dev says shifts within 500 milliseconds of an interaction are generally excluded [6].
Common causes are images, ads, embeds and iframes without dimensions, content injected above existing content, and web fonts that swap in at a different size [6]. 66% of pages have at least one unsized image, according to HTTP Archive's 2024 Web Almanac, as cited by web.dev [2].
How a page passes: the 75th percentile
A page does not pass because one test was fast. Google recommends measuring "the 75th percentile of page loads, segmented across mobile and desktop devices" [1]. In practice, at least three out of four visits need to meet the threshold for the page to count as good. This matters because a page can feel fine on a fast office connection and still fail, because a quarter of real visitors use slower phones and networks.
The same rule applies to each metric separately. A page needs all three to be good to pass the Core Web Vitals assessment. Search Console groups similar URLs and gives each group the status of its worst metric, separately for mobile and desktop [7].
Where the numbers come from
Real-user data comes from the Chrome User Experience Report, which collects anonymous measurements from Chrome users who have opted in. CrUX only includes pages and origins that are publicly discoverable and "sufficiently popular", and it excludes Chrome on iOS [8]. Lab tools such as Lighthouse run a page once under controlled conditions. Both are useful, but they answer different questions. Our field and lab data guide explains when to trust which.
How common it is to fail
Passing all three metrics is not the norm. HTTP Archive's 2025 Web Almanac, which analyzed July 2025 data, found that 48% of mobile websites and 56% of desktop websites had good Core Web Vitals. On mobile, 62% had good LCP, 77% good INP and 81% good CLS [9]. LCP is the metric that most often holds mobile sites back.
Do Core Web Vitals affect search rankings?
Google says "Core Web Vitals are used by our ranking systems" and recommends that site owners achieve good scores "for success with Search" [10]. It also says it "always seeks to show the most relevant content, even if the page experience is sub-par" [11]. The honest summary is that good Core Web Vitals help, especially when competing pages are equally relevant, but they do not replace useful content. Our speed and SEO guide covers the details.
Reading your own Core Web Vitals
You do not need special software to see where you stand. Two free Google tools cover most of it. PageSpeed Insights shows field data for a URL and for the whole origin when CrUX has enough visits, plus a lab test from a simulated load [12]. Search Console's Core Web Vitals report shows groups of similar URLs across the whole site, split by mobile and desktop, each labeled Good, Need improvement or Poor [7].
A sensible routine is to open the Search Console report first to see which groups and which metric are failing, then run PageSpeed Insights on a representative URL from each failing group. The field section tells you how bad the problem is for real visitors; the lab section and its diagnostics help explain why. Write down the date and the numbers before anyone changes anything, so you have a fair starting point to compare against later.
What "good", "needs improvement" and "poor" mean
Each metric has three bands. The good thresholds are the ones quoted above: 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS [1]. Values between good and poor fall into "needs improvement". Because the assessment uses the 75th percentile, a page in the middle band is one where a meaningful share of visits, more than one in four, are slower than the good threshold. That is worth fixing even if the page feels fine to you.
Search Console applies the strictest view to groups: a group of URLs takes the status of its worst metric, so a single poor metric marks the whole group poor [7]. When you fix one metric and the group stays poor, check whether another metric is now the one holding it back.
The metrics behind the metrics
Core Web Vitals are not the only performance measurements, and some of the others help explain them. Time to First Byte is the first part of LCP and reflects server and network speed [3]. First Contentful Paint shows when anything at all appears. Total Blocking Time, a lab metric, measures how long the main thread was blocked during load and often points to the same scripts that hurt INP. In the Lighthouse performance score it carries 30% of the weight, more than any other metric [13]. These supporting numbers are useful for diagnosis, but they are not what the Core Web Vitals assessment is based on.
A common mistake: fixing the score instead of the visit
It is possible to raise a lab score without helping real visitors, for example by delaying every script until the first scroll so the lab test never runs them. The lab number improves, but visitors who scroll still wait for the same scripts, and INP can get worse. The better test is always whether field data improves over the following weeks. If a change only makes sense because of how a lab tool works, it is probably not worth making.
Core Web Vitals questions
Is a PageSpeed score of 100 the same as passing Core Web Vitals?
No. The score is a lab result from one simulated load. Passing Core Web Vitals is judged on real-user field data at the 75th percentile, which can differ a lot from the lab score.
Does First Input Delay still matter?
No. Interaction to Next Paint replaced it as a Core Web Vital on March 12, 2024. Older reports and plugins that still show FID are out of date.
Why is my desktop result good but mobile poor?
Phones usually have slower processors and networks, so the same page takes longer to load and respond. Google reports mobile and desktop separately for this reason.
Sources
Opened and checked on November 3, 2026.
- Web Vitals, web.dev (Google Chrome team). Primary documentation, last updated October 31, 2024.
- The most effective ways to improve Core Web Vitals, web.dev. Primary documentation (cites HTTP Archive and Chrome data), last updated October 31, 2024.
- Optimize Largest Contentful Paint, web.dev. Primary documentation, last updated March 31, 2025.
- Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev blog, Jeremy Wagner and Rick Viscomi. Primary announcement, last updated January 31, 2024.
- Optimize Interaction to Next Paint, web.dev. Primary documentation, last updated September 2, 2025.
- Optimize Cumulative Layout Shift, web.dev. Primary documentation, last updated February 7, 2025.
- Core Web Vitals report, Search Console Help. Primary documentation, checked November 3, 2026.
- CrUX methodology, Chrome for Developers. Primary documentation, last updated June 20, 2024.
- Performance, The 2025 Web Almanac, HTTP Archive (Himanshu Jariyal, Prathamesh Rasam, Humaira and Aaron T. Grogg). Research report (secondary analysis of public datasets), published January 15, 2026, last updated May 5, 2026, based on July 2025 data.
- Understanding Core Web Vitals and Google search results, Google Search Central. Primary documentation, last updated December 10, 2025.
- Understanding Google Page Experience, Google Search Central. Primary documentation, last updated September 22, 2026.
- About PageSpeed Insights, Google for Developers. Primary documentation, last updated October 21, 2024.
- Lighthouse performance scoring, Chrome for Developers. Primary documentation, last updated September 19, 2019.