Core Web Vitals are three metrics Google uses to describe the user experience of a web page. They cover loading (Largest Contentful Paint, LCP), responsiveness to input (Interaction to Next Paint, INP), and visual stability (Cumulative Layout Shift, CLS), measured with data from real Chrome users.
At a glance
- Metrics
- LCP (loading), INP (responsiveness), CLS (visual stability)
- Assessment
- 75th percentile of page loads, mobile and desktop separately
- Data source
- field data from real Chrome users (Chrome User Experience Report, CrUX)
- Since
- May 2020; INP replaced FID on March 12, 2024
Last checked:
What are the thresholds?
Assessed at the 75th percentile of page loads, mobile and desktop separately. Sources: web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS). Last checked: .
A page passes a metric when the 75th percentile of page loads falls in the good range. Mobile and desktop are assessed separately.
INP became a Core Web Vital on March 12, 2024, and replaced First Input Delay (FID), which only measured the delay of the first input. Articles that still list FID with a 100 ms threshold are out of date. According to web.dev, stable Core Web Vitals change at most once a year.
- Google introduces Web Vitals. The first Core Web Vitals are LCP, FID and CLS.Source: blog.chromium.org
- Google announces a page experience ranking signal that combines Core Web Vitals with existing signals.Source: developers.google.com
- Google sets the date: the signals are to be used in ranking from May 2021.Source: developers.google.com
- Postponed: gradual rollout from mid-June 2021, full effect only by the end of August 2021.Source: developers.google.com
- Page experience update for mobile: Core Web Vitals become part of the ranking systems.Source: developers.google.com
- Page experience update for desktop, using the same Core Web Vitals thresholds as on mobile.Source: status.search.google.com
- INP is no longer experimental. Google announces that INP will replace FID as a Core Web Vital in March 2024.Source: web.dev
- INP replaces FID. Since then the Core Web Vitals are LCP, INP and CLS. Articles citing “FID 100 ms” as a threshold are out of date.Source: web.dev
- Chrome tools end support for FID.Source: web.dev
End of the mobile rollout: Google says “between June and August 2021”; the often-cited date of September 2, 2021 comes only from a Google Search Central post on X. Last checked: .
How are they measured?
Field data from real Chrome users is collected in the Chrome User Experience Report (CrUX). PageSpeed Insights and the Core Web Vitals report in Search Console show this data. Lab tools such as Lighthouse simulate a page load. Because a lab test has no real user input, Lighthouse uses Total Blocking Time as a stand-in for INP.
| Metric | Measures | Core Web Vital? | Field or lab | “Good” per web.dev |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Render time of the largest image, text block or video visible in the viewport, from the start of navigation | yes (loading) | field and lab | 2.5 s or less |
| INP (Interaction to Next Paint) | Latency of interactions across the whole visit until the next paint; one value that all (or nearly all) interactions fall below | yes (interactivity), since 2024-03-12 | field; in the lab only with simulated interactions, Lighthouse does not measure INP | 200 ms or less |
| CLS (Cumulative Layout Shift) | Largest burst of unexpected layout shifts during the entire lifecycle of the page | yes (visual stability) | field and lab | 0.1 or less |
| TTFB (Time to First Byte) | Time from the start of navigation until the first byte of the response arrives | no (helps diagnose LCP) | field and lab | 0.8 s or less |
| FCP (First Contentful Paint) | Time from the start of navigation until any part of the page's content is rendered | no (helps diagnose LCP) | field and lab | 1.8 s or less |
| TBT (Total Blocking Time) | Total time after FCP during which the main thread was blocked long enough to prevent input responsiveness | no (lab proxy for INP) | lab; web.dev does not recommend field measurement | less than 200 ms on average mobile hardware |
| Speed Index | How quickly content is visually displayed during page load (from a video of the load) | no | lab (Lighthouse) | Threshold according to Lighthouse: mobile up to 3.4 s “fast” (web.dev gives no value) |
| FID (First Input Delay), historical | Time from the first interaction until the browser can begin processing event handlers | until 2024-03-12, replaced by INP | field only | 100 ms or less |
According to web.dev, the 75th percentile of page loads is assessed, mobile and desktop separately. A page passes the Core Web Vitals when LCP, INP and CLS are “good” at the 75th percentile. Chrome tools ended FID support on September 9, 2024. Sources: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Last checked: .
Do Core Web Vitals affect rankings?
Google says good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward. Google gives no weighting. Its page experience documentation adds that Google always seeks to show the most relevant content, even when the page experience is below average.
Example
A product page (hypothetical) loads a large hero image without width and height attributes. The image appears late (LCP 3.8 s), and the text below jumps down once it loads (CLS 0.22). Setting fixed width and height on the image and serving a smaller, compressed file improves both values.
Common mistakes
- Images without dimensions. Without
widthandheightattributes or a CSS aspect ratio, the browser reserves no space and content shifts as the image loads. web.dev lists this among the most common causes of poor CLS. - Ads, embeds and iframes without reserved space. When they are injected later, they push the rest of the content down and raise CLS.
- Lazy-loading the LCP image. With
loading="lazy"or a JavaScript library that hidessrcasdata-src, the largest image starts loading late. web.dev advises never to lazy-load the LCP image. - Treating the Lighthouse score as the benchmark. Lab tests run under fixed network and device conditions and only partly reflect real users. When field data is available, web.dev recommends using it to prioritize work.
Frequently asked questions
How can I measure the Core Web Vitals of my website? Field data is available in the Chrome User Experience Report, PageSpeed Insights and the Core Web Vitals report in Search Console. In the lab, Chrome DevTools measures all three metrics. Lighthouse measures LCP and CLS and uses Total Blocking Time as a proxy for INP.
How do I pass the Core Web Vitals assessment? A page passes when LCP, INP and CLS are all in the good range at the 75th percentile of page loads. Mobile and desktop are assessed separately.
What is a good LCP score? According to web.dev, an LCP of 2.5 seconds or less is good. Above 4 seconds it is poor.
Sources
- Web Vitals – web.devweb.dev
- Understanding Core Web Vitals and Google search results – Google Search Central (last updated 2025-12-10)developers.google.com
- Understanding page experience in Google Search results – Google Search Central (last updated 2026-09-22)developers.google.com
- Interaction to Next Paint becomes a Core Web Vital on March 12 – web.devweb.dev
- Optimize Cumulative Layout Shift – web.devweb.dev
- Optimize Largest Contentful Paint – web.devweb.dev
- Why lab and field data can be different – web.devweb.dev
Last updated: