# What Are Core Web Vitals? LCP, INP and CLS Explained

> What Core Web Vitals are, the current LCP, INP and CLS thresholds, how much they weigh in Google and how to measure them on your store's product pages.

URL: https://clione.ai/glossary/core-web-vitals/
Lang: en

Core Web Vitals are not a speed grade or a score out of a hundred: they are three measures of how a page feels to the people who actually visit it. Google defines them within its Web Vitals initiative, which was started so a site owner does not have to be a performance expert to know what experience their site delivers.[^webdev-vitals] They matter to a store from two sides. From Google's side, which **recommends having good Core Web Vitals to be successful in Search** and uses them in its ranking systems.[^google-page-experience] And from the customer's side, who abandons a [product page](/glossary/product-page/) that is slow, that does not respond when they tap a size or that moves the buy button just as they go to press it.

## How it works

There are three metrics, each covering a part of the experience:[^webdev-vitals]

- **LCP (Largest Contentful Paint)** measures loading: the time it takes to paint the largest element visible on screen, whether an image, a block of text or a video.[^webdev-lcp] For a good experience, 2.5 seconds or less.
- **INP (Interaction to Next Paint)** measures responsiveness: it observes all the clicks, taps and key presses during the visit, and the final value is the slowest interaction, ignoring outliers.[^webdev-inp] For a good experience, 200 milliseconds or less.
- **CLS (Cumulative Layout Shift)** measures visual stability: how much content shifts unexpectedly while the page is open.[^webdev-cls] For a good experience, 0.1 or less.

**You pass with 75% of visits, not with the average.** Google recommends measuring at the 75th percentile of page loads, separately on mobile and on desktop, and considers a page good when it meets all three targets at that percentile.[^webdev-vitals] The data comes from the Chrome User Experience Report, which collects anonymous measurements from real users and feeds PageSpeed Insights and the Core Web Vitals report in [Search Console](/glossary/google-search-console/).[^webdev-vitals]

The Search Console report adds the middle tier, with these thresholds:[^gsc-cwv-report]

| Metric | Good           | Needs improvement | Poor                         |
| ------ | -------------- | ----------------- | ---------------------------- |
| LCP    | 2.5 s or less  | 4 s or less       | over 4 s                     |
| INP    | 200 ms or less | 500 ms or less    | over 500 ms[^gsc-cwv-report] |
| CLS    | 0.1 or less    | 0.25 or less      | over 0.25                    |

The report groups URLs that deliver a similar experience, calculates each value over 75% of the visits in the last 28 days and gives each group the status of its worst metric. A group without enough LCP and CLS data does not appear.[^gsc-cwv-report]

**The set changes, but slowly.** Metrics go through three phases, experimental, pending and stable, and a stable metric does not change more than once a year.[^webdev-vitals] The only change so far was the responsiveness one: on March 12, 2024, **INP replaced FID (First Input Delay)**, which only measured the delay of the first interaction, and Chrome gave until September 9, 2024 to stop using FID in its tools.[^webdev-inp-launch][^webdev-inp]

How much they weigh in Google has nuances that Google spells out. Core Web Vitals are used in its ranking systems, but getting good results in the report **does not guarantee your pages will rank high**, and chasing a perfect score only for SEO may not be the best use of your time. Relevance comes first: Google shows the most relevant content even if the experience is worse, and a good experience helps when there are many useful pages to choose from.[^google-page-experience] In its documentation, Google rounds the thresholds as "less than 200 milliseconds" and "less than 0.1";[^google-cwv-search] web.dev and Search Console say "or less."

## In a store

A [product page](/glossary/product-page/) has all three metrics in view. A **fictional example** of where each one usually sits:

| Metric | What sets it on a product page                                             | What makes it worse                                     |
| ------ | -------------------------------------------------------------------------- | ------------------------------------------------------- |
| LCP    | The main product photo, when it is the largest element on screen           | A heavy image, or one that is discovered late           |
| INP    | Choosing a size or a color, pressing "Add to cart," opening the size guide | Long scripts on the main thread that delay the response |
| CLS    | The price area, the review stars, the cookie notice                        | Images without dimensions and blocks inserted later     |

The causes in the last column are the ones web.dev gives. An image counts as an LCP candidate;[^webdev-lcp] an interaction's response is delayed by long tasks on the browser's main thread;[^webdev-inp] and content shifts usually come from resources that load asynchronously, from elements added to the DOM above what was already there and from images or videos with no known dimensions.[^webdev-cls] In a store, a lot of that is added by apps, which is why a product page's [JavaScript rendering](/glossary/javascript-rendering/) weighs on its INP too.

Google publishes business cases. Among those web.dev collected in 2021, **Vodafone Italy improved its LCP by 31% and sold 8% more**.[^webdev-business] It is one company's case on one date, not a forecast for your catalog.


That the Lighthouse score is Core Web Vitals. Lighthouse loads the page in a simulated environment, with no person involved, so it **cannot measure INP**: it gives Total Blocking Time as an approximation instead.[^webdev-vitals] And a lab measurement does not replace a field one, because the phone, the network and the way the page is used change every value.[^webdev-vitals] A 100 in Lighthouse does not mean passing with your customers, and a fail in Search Console is not fixed by looking only at the lab.


## How to check it

1. **Open the Core Web Vitals report in Search Console**, mobile first. Fix what is "Poor" first and, within each status, what affects the most URLs or the most important ones.[^gsc-cwv-report]
2. **Click an example URL and run it through PageSpeed Insights.** Keep in mind that the report gives values per URL group and PageSpeed Insights usually gives them per URL, so they may not match.[^gsc-cwv-report]
3. **If there is no data**, the site is new in Search Console or the Chrome User Experience Report does not have enough visits for that device type.[^gsc-cwv-report]
4. **Diagnose in the lab**, with Lighthouse or Chrome's tools, and use Total Blocking Time as a hint for INP: improving it in the lab can improve INP with real users.[^webdev-vitals]
5. **Measure on your own site.** The `web-vitals` JavaScript library measures the three metrics the way Google's tools calculate them, and web.dev recommends setting up your own real-user measurement to catch a regression in time.[^webdev-vitals]

## Related concept: page experience

Page experience is broader. Beyond Core Web Vitals, Google asks whether the page is served securely, whether it looks good on mobile, whether it avoids excessive ads and intrusive interstitials and whether the main content is easy to tell apart. It is not a single signal: its systems look at several, and **of all those aspects, only Core Web Vitals are used directly in ranking**; the rest does not directly help you climb, although it makes the site more satisfying.[^google-page-experience] Core Web Vitals are the part that is measured with numbers.

To go further, the term on [server-side rendering](/glossary/server-side-rendering/) explains how a product page's content reaches the browser, and the [reading path](/learn/crawling-and-indexing/) for this topic orders the rest of the terms.