Core Web Vitals explained simply: LCP, INP and CLS
Core Web Vitals explained simply: what LCP, INP and CLS are, Google's thresholds, how they're measured and how to improve them, with a real CLS fix.
In 30 seconds
- Core Web Vitals are three Google metrics for how a page feels: loading, responsiveness and visual stability.
- Good thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1.
- They're measured on real visits from the last 28 days (CrUX data), at the 75th percentile, separately for mobile and desktop.
- Since 12 March 2024 INP has replaced FID as the responsiveness metric.
Core Web Vitals are three metrics Google uses to assess a web page’s experience from the visitor’s point of view: LCP (how fast the main content appears), INP (how fast the page responds to clicks and taps) and CLS (how much the page “jumps” while loading). A page is good if it has LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, measured on real visits.
The three metrics and their thresholds
| Metric | What it checks | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | When the largest element appears | up to 2.5 s | 2.5-4 s | over 4 s |
| INP (Interaction to Next Paint) | How fast the page responds to a click or tap | up to 200 ms | 200-500 ms | over 500 ms |
| CLS (Cumulative Layout Shift) | How much the page shifts while loading | up to 0.1 | 0.1-0.25 | over 0.25 |
Google looks at data from real visits at the 75th percentile: a page “passes” if at least 3 visits out of 4 have good values for all three metrics.
LCP: Largest Contentful Paint
LCP measures the time from opening the page to the moment the largest element visible without scrolling appears: usually a cover image, a product photo or a big heading.
How to improve it:
- images resized for mobile and in modern formats (WebP, AVIF);
- don’t lazy-load the main image at the top, only the ones further down;
- a faster server and a CDN (a network that serves files from close to the visitor);
- fewer CSS and JavaScript files that block the page before it’s shown.
INP: Interaction to Next Paint
INP measures the time between a person’s action (a click, a tap, a key press) and the moment the page shows the response. It looks at all interactions during the visit and reports one of the slowest. It replaced FID on 12 March 2024.
How to improve it:
- fewer third-party scripts (chat widgets, ads, tracking tools);
- break long JavaScript tasks into smaller pieces;
- give immediate visual feedback after a click (for example a button that changes state).
CLS: Cumulative Layout Shift
CLS measures how much page elements move unexpectedly while it loads: text that drops because an image appeared above it, a button that moves just as you tap it. It’s a unitless number: 0 means no movement.
How to improve it:
- set width and height for images and videos;
- reserve space for banners, ads and content that arrives later;
- preload the fonts used at the top, so text doesn’t change width when the right typeface arrives.
What usually ruins them
- High LCP: images too heavy, not resized for mobile, in old formats.
- High INP: too many scripts (chat, ads, tracking tools) keeping the browser busy.
- High CLS: images without set dimensions, banners appearing at the top and pushing text down.
Field data and lab data
| Field data | Lab data | |
|---|---|---|
| Where it comes from | Real visits by Chrome users (Chrome UX Report, CrUX) | A simulated test with Lighthouse |
| Period | Last 28 days | The moment of the test |
| Where to see it | Search Console, PageSpeed Insights (top) | PageSpeed Insights (bottom), Chrome DevTools |
| Does Google use it? | Yes | No, it’s for finding causes |
Core Web Vitals and SEO
Google says Core Web Vitals are used by its ranking systems as part of page experience, but that a good score doesn’t guarantee high rankings: what matters first is that the content is useful and relevant. A slow page still loses people and sales, even without counting Google.
An example from the fictional shop
At the fictional shop Five Leaf the 29 product pages had an LCP of 4.1 seconds on mobile. The cause: the main photo, a JPG of about 2.4 MB, the same for desktop and mobile.
The fix, written up as a request for the developers:
- a lighter version of the photo for mobile (WebP format);
- width and height set in the code;
- target: LCP under 2.5 seconds.
A real case: Peacchy’s CLS
This site had a CLS problem too. In November 2026 the homepage had a CLS of 0.21 on mobile (poor). Lighthouse pointed to two causes:
- the fonts arrived after the text: when the right typeface loaded, lines changed width and wrapped differently;
- the animated numbers counting from 0 to 27 changed width as they counted.
The fix: preload the 4 font files used at the top and reserve the final space for the numbers straight away. Result: CLS 0.
Where to start
- Open the Core Web Vitals report in Search Console and look at the “poor” page groups on mobile.
- Test one page from that group with PageSpeed Insights: it tells you which element is slowest.
- Fix one cause at a time and check again after a few weeks: field data updates slowly.
- Check INP after adding new scripts: chat widgets and ad pixels are the most common causes.
If pages don’t appear on Google at all, the problem comes earlier: read how Google finds pages and how to get indexed.
Sources
Product pages have an LCP of 4.1 seconds on phones. What's the most likely cause?
Correct! LCP measures when the largest element appears, which on product pages is almost always the photo. A photo of a few MB slows everything down.
Not quite. Title and text weigh almost nothing: LCP nearly always depends on the image or the largest block at the top.
Frequently asked questions
Do Core Web Vitals help rankings?
They're one of many signals, not the most important. But a slow page loses visitors and sales, even without counting Google.
Where can I see them?
In Search Console, in the Core Web Vitals report, and with PageSpeed Insights, which is free.
What was FID?
First Input Delay, the old responsiveness metric: it only looked at the first click. Since 12 March 2024 it has been replaced by INP, which looks at all interactions during a visit.
Why does PageSpeed Insights show two different results?
Because it shows two kinds of data: at the top, real visits from the last 28 days (if the site has enough), below, a lab test run at that moment with Lighthouse. Google uses the real data.
Does a small site have Core Web Vitals data?
Only if it has enough visits from Chrome. Otherwise Search Console doesn't show the report and you use lab tests (Lighthouse) as a guide.
Topics:SEOTechnical SEO