- The Core Web Vitals are three metrics. LCP measures loading, INP responsiveness to input and CLS visual stability. INP replaced FID on March 12, 2024.
- The assessment uses the 75th percentile of real page views, split by mobile and desktop. A good Lighthouse score does not replace this field data.
- Google uses the Core Web Vitals in ranking. According to Google, however, relevance comes first, and good scores do not guarantee a top position.
What are Core Web Vitals?
Core Web Vitals are the metrics Google and Chrome use to measure the user experience when a page loads and is used. They are part of the Web Vitals program on web.dev. Since 2024 there have been three.
| Metric | Measures | Question |
|---|---|---|
| LCP, Largest Contentful Paint | Loading | When is the largest visible element displayed, such as a product image or a text block? |
| INP, Interaction to Next Paint | Responsiveness | How quickly does the page respond to clicks, taps and key presses? |
| CLS, Cumulative Layout Shift | Stability | How much does the content shift unexpectedly while someone is reading? |
INP replaced the First Input Delay metric on 12 March 2024. FID only measured the delay of the first input. INP assesses interactions throughout the entire page visit. According to web.dev, the stable metrics change at most once a year, and Google announces changes in advance.
Thresholds
There are three ranges for each metric. What counts is the 75th percentile of all page views, split by mobile and desktop. So three out of four views must be in the good range.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | up to 2.5 s | over 2.5 s to 4 s | over 4 s |
| INP | up to 200 ms | over 200 ms to 500 ms | over 500 ms |
| CLS | up to 0.1 | over 0.1 to 0.25 | over 0.25 |
A page passes the assessment when all three metrics are good. In Search Console, a group of URLs always gets the status of its worst metric. If CLS is poor and LCP and INP are good, the whole group counts as poor.
How are the values calculated?
- LCP counts images, videos, CSS background images and text blocks. The largest of these elements in the visible area determines the value.
- INP takes the slowest interaction of a page visit. With many interactions, the measurement ignores the highest value for every 50 interactions. Scrolling and hovering do not count.
- CLS groups shifts into windows of at most five seconds and takes the largest window. Shifts within 500 ms of a click or key press do not count.
Field data and lab data
Field data comes from real visitors, lab data from a simulated page load. Both are useful and answer different questions.
| Field data | Lab data | |
|---|---|---|
| Source | Chrome User Experience Report (CrUX) or your own real user monitoring | Lighthouse, Chrome DevTools |
| Measurement | Real users, many devices and networks | One device, fixed network conditions |
| Period | In PageSpeed Insights the last 28 days | A single page load |
| INP | Yes | No, Total Blocking Time is the substitute |
| Good for | The assessment as Google sees it | Finding causes and testing fixes |
The Core Web Vitals report in Search Console uses CrUX field data and groups similar URLs. Lighthouse loads a single page under fixed conditions. A page can score 95 points in Lighthouse and still fail in the field data, for example because real visitors use slower smartphones or a consent banner only appears for them.
Who counts in CrUX?
CrUX covers Chrome users on desktop and Android who share usage statistics and sync their history. Chrome on iOS, other Chromium browsers such as Edge, and WebViews in apps do not count. A page only appears with its own data if it is publicly discoverable, meaning status 200 and no noindex, and has enough visitors. Google does not publish the threshold. For less visited pages, there are then only values for the whole domain.
Measuring it yourself
For your own field data, Google provides the web-vitals library. It measures the three values in your visitors' browsers and passes them on to your analytics.
Typical causes and fixes
| Metric | Common cause | Fix |
|---|---|---|
| LCP | Slow server response, HTML is generated anew on every request | HTML caching, for example in the CDN, faster database queries |
| LCP | Main image is discovered late or lazy-loaded | Reference the main image in the HTML, no lazy loading, fetchpriority="high" |
| LCP | Render-blocking CSS and JavaScript | Inline critical CSS, scripts with defer |
| INP | Long JavaScript tasks, often from third-party scripts | Split up tasks, review scripts and load them later |
| INP | Large DOM, costly repainting after clicks | Reduce the DOM, only update visible parts |
| CLS | Images and videos without width and height | Set width and height or aspect-ratio |
| CLS | Ads, banners and widgets that expand afterwards | Reserve space in advance |
| CLS | Web fonts with different width or size from the fallback font | Match the fallback font, preload fonts |
A real-world example with HTML caching in a shop
A searchVIU case study from 2019 describes HTML caching via Cloudflare in an online shop. Before that, Cloudflare only served static files from the cache, and every HTML page came fresh from the server. The server response averaged about 1.5 seconds. With three page rules, now cache rules, the cart and checkout were excluded, information pages were cached for a day and all other pages for 30 minutes. Logged-in users and users with items in their cart always got the fresh page via a cookie.
Afterwards the server response was under one second, and the average load time fell from 4.49 to 3.25 seconds, around 28 percent. At the time, it was measured with the load time from Google Analytics, as LCP did not exist yet. Because the server response is part of LCP, the example still shows how much a fast server matters. Read the HTML caching with Cloudflare case study
Impact on rankings
In its page experience documentation, Google writes that its ranking systems use the Core Web Vitals. The same text says that there is no single signal and that Google always shows the most relevant content, even with a weak page experience. A good user experience can tip the balance when there are many helpful pages to choose from.
According to Google, good scores in the Core Web Vitals report do not guarantee a top position. Google assesses mostly per page. Some assessments apply to the whole website. According to Google, the other aspects of page experience, such as HTTPS, mobile display or intrusive interstitials, do not help directly in ranking but do improve the user experience.
Common mistakes
- Optimizing for the Lighthouse score and not looking at the field data.
- Only checking the homepage. Product and category pages have different templates and often different values.
- Looking at mobile and desktop together. Google assesses them separately.
- Expecting new field data immediately after a fix. CrUX and validation in Search Console run over 28 days.
- Lazy-loading the main image and making LCP worse as a result.
Frequently asked questions
What are Core Web Vitals?
Three metrics from Google for user experience. LCP measures loading, INP responsiveness to input and CLS the visual stability of a page.
Are Core Web Vitals a ranking factor?
Yes, according to its own documentation Google uses them in ranking. Relevance comes first, however, and good scores alone do not bring a top position.
What is a good LCP value?
2.5 seconds or less, measured at the 75th percentile of real page views. Over 4 seconds counts as poor.
What is a good CLS value?
0.1 or less. Over 0.25 counts as poor. Common causes are images without dimensions, ads loaded later and web fonts.
Why does Search Console show different values from Lighthouse?
Search Console uses field data from real Chrome users over recent weeks, Lighthouse a single simulated page load. The two therefore measure different things.
How can I measure my website's performance?
PageSpeed Insights shows field and lab data for individual URLs, and the Core Web Vitals report in Search Console shows groups of URLs. For your own field data, add the web-vitals library.
Sources
Retrieved on October 15, 2026. If something is out of date or missing, let us know.
- web.dev, Web Vitals: https://web.dev/articles/vitals · As of Oct 31, 2024
- web.dev, Largest Contentful Paint: https://web.dev/articles/lcp · As of Sep 4, 2025
- web.dev, Interaction to Next Paint: https://web.dev/articles/inp · As of Sep 2, 2025
- web.dev, Cumulative Layout Shift: https://web.dev/articles/cls · As of Apr 12, 2023
- web.dev Blog, Interaction to Next Paint becomes a Core Web Vital on March 12: https://web.dev/blog/inp-cwv-march-12 · As of Jan 31, 2024
- Google Search Central, Page experience: https://developers.google.com/search/docs/appearance/page-experience · As of Sep 22, 2026
- Chrome for Developers, CrUX methodology: https://developer.chrome.com/docs/crux/methodology · As of Jun 20, 2024
- PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about · As of Oct 21, 2024
- Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520 · Retrieved Oct 15, 2026
- GoogleChrome, web-vitals: https://github.com/GoogleChrome/web-vitals