Core Web Vitals explained: LCP, INP and CLS
What each Core Web Vital measures, the thresholds Google uses, where to find your real numbers, and what usually fixes them.
· 3 min read
Core Web Vitals are three measures Google uses to describe the experience of loading and using a page: how quickly the main content appears, how quickly the page responds, and how stable it is while loading.
The three metrics
Largest Contentful Paint (LCP): loading
How long it takes for the largest image or text block in the viewport to appear.
- Good: 2.5 seconds or less
- Poor: more than 4 seconds
Interaction to Next Paint (INP): responsiveness
How quickly the page responds to clicks, taps and key presses, across the visit. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
- Good: 200 milliseconds or less
- Poor: more than 500 milliseconds
Cumulative Layout Shift (CLS): visual stability
How much the content moves around unexpectedly while the page loads.
- Good: 0.1 or less
- Poor: more than 0.25
A page passes when it reaches "good" for all three at the 75th percentile of real visits, measured separately for mobile and desktop.
Field data and lab data
- Field data comes from real Chrome users (the Chrome User Experience Report). It is what the assessment is based on. You see it in PageSpeed Insights when enough data exists, and grouped by page type in the Core Web Vitals report in Google Search Console.
- Lab data comes from a test run, such as Lighthouse. It is useful for finding causes and testing fixes, but it is one device and one connection, not your visitors.
When field and lab results disagree, trust the field data for the assessment and use the lab to investigate.
How much do they matter for rankings?
Google says Core Web Vitals are used by its ranking systems as part of page experience, but that relevance and helpful content matter more: a fast page does not outrank a more relevant one. Treat good Core Web Vitals as a requirement for a good site, not a shortcut to rankings. They also matter for visitors, who leave slow, jumpy pages.
Common fixes
LCP
- Make the main image small and modern (WebP or AVIF), sized for the screen, and do not lazy-load it.
- Reduce server response time: caching, a CDN, fewer slow database queries.
- Avoid render-blocking CSS and JavaScript before the main content.
INP
- Break up long JavaScript tasks and load less JavaScript, especially third-party scripts.
- Do less work in event handlers; show feedback first, then do the heavy work.
CLS
- Give images, videos and embeds width and height attributes (or a reserved space).
- Reserve space for adverts, banners and cookie notices instead of pushing content down.
- Load web fonts in a way that does not cause large text reflow.
Checking a site
- Open the Core Web Vitals report in Search Console to see which groups of pages fail, and on which metric.
- Test an example URL from each group in PageSpeed Insights.
- Fix the cause in the template, not the single page, then use the report's validation to confirm.
For the wider technical checks, see A technical SEO checklist for new sites. Stuck on a particular metric? Ask in the Technical SEO community.