What Are Core Web Vitals? LCP, INP and CLS Explained
Core Web Vitals are Google's three page experience metrics: LCP, INP and CLS. See the thresholds, how they are measured and how to improve them.
What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. A page passes when all three are "good" at the 75th percentile of real visits.
Each metric is judged separately for mobile and desktop, on what real visitors experienced rather than on one test run. That is why a page can look fast on your laptop and still fail.
The three metrics and their thresholds
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading speed of the main content | 2.5 s or less | 2.5 to 4.0 s | over 4.0 s |
| INP | Responsiveness to clicks, taps and key presses | 200 ms or less | 200 to 500 ms | over 500 ms |
| CLS | Unexpected layout movement | 0.1 or less | 0.1 to 0.25 | over 0.25 |
The thresholds are published on web.dev, where Google maintains the definitions.
Largest Contentful Paint (LCP)
LCP is the time until the largest image, text block or video in the viewport has rendered, counted from the moment the visitor started navigating. Because it starts at navigation, a slow server response, redirects and connection setup all add to it.
Interaction to Next Paint (INP)
INP looks at every click, tap and key press during a visit and reports the longest one, ignoring outliers. Each is timed from the input until the browser can paint the next frame. INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. FID only measured the delay before the first interaction was handled, so it missed slow interactions later in the visit.
Cumulative Layout Shift (CLS)
CLS adds up unexpected movement of visible elements. It reports the largest burst of shifts during the page's life, so one late-loading banner that pushes the article down can fail a page.
How Google uses Core Web Vitals
In its Search documentation Google says it highly recommends that site owners achieve good Core Web Vitals for success with Search, and ties them to page experience, which aligns with what its core ranking systems seek to reward. The documentation does not say how much weight they carry, so treat them as one input among many. Strong vitals do not make up for content that does not answer the query. They do protect you from losing visitors to a slow or jumpy page.
Field data vs lab data
Field data comes from real Chrome users and is collected in the Chrome UX Report (CrUX), over a trailing 28-day window. This is what the Core Web Vitals report in Google Search Console shows. Lab data comes from a tool such as Lighthouse that loads the page once on a simulated device and network.
The two often disagree. A lab score of 95 only says the page was fast under those conditions. Real visitors arrive on slower phones, weaker networks and from other countries. Use lab data to find what is slow and why, and field data to judge whether visitors actually have a good experience. Scheduled synthetic monitoring sits between the two: it is lab-style, but it runs on a timer so regressions show up before the 28-day window catches up.
Common causes of poor Core Web Vitals and fixes
Slow LCP. Check the time to first byte first: reduce redirects, cache responses and use a CDN. Make the LCP image discoverable in the initial HTML, and preload it if it is only referenced from CSS or JavaScript. Set fetchpriority="high" on the likely LCP image (on one or two images at most) and never lazy-load it. Shrink the file, and cut render-blocking CSS and synchronous scripts in the head.
Poor INP. Long tasks on the main thread are the usual cause, often from script loading and parsing. Do as little work as possible in event handlers, update the screen first and defer the rest, split big jobs with setTimeout, avoid reading layout right after changing styles, and keep the DOM small.
High CLS. The usual causes are images and videos without dimensions, fonts that render at a different size than their fallback, ads or widgets that resize themselves, and content inserted above what the visitor is reading. Set width and height (or an aspect ratio), reserve space for anything that loads late, and animate with transform instead of layout properties. A longer walkthrough is on our Core Web Vitals optimization page.
How to measure and monitor Core Web Vitals
- Check your real-user numbers. The free Core Web Vitals checker reads CrUX and shows the 75th-percentile LCP, INP and CLS for mobile and desktop, plus a pass or fail. Pages without enough Chrome traffic return no field data.
- Diagnose a page. Run the website speed test after a change to see what is slow in a lab run.
- Watch it over time. Page speed monitoring runs scheduled Lighthouse audits from 25 cloud regions and can alert you when a metric regresses past your thresholds. Our guide to monitoring Core Web Vitals with alerts and reports shows the setup, and the comparison of Core Web Vitals tools lists the alternatives.
Because field data is a 28-day window, a fix shows up gradually. Expect the report to catch up over about a month, and judge a deploy by the lab and synthetic numbers first.
FAQ: Core Web Vitals
What are good Core Web Vitals scores?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, each measured at the 75th percentile of real visits. A page passes only when all three are good.
Do Core Web Vitals matter for SEO?
Google highly recommends good Core Web Vitals for success with Search and links them to its page experience guidance. It does not publish how much they weigh, so improve them for visitors first and treat any ranking effect as a bonus. They never replace relevant content.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced FID as a Core Web Vital on March 12, 2024. INP considers all interactions during a visit, not just the first one.
How long until an improvement shows in Search Console?
The field data covers a trailing 28 days, so a fix appears gradually and is fully reflected after roughly four weeks. Scores can look unchanged for days after a deploy because most of the window is still old data.
Why is my Lighthouse score high but my Core Web Vitals fail?
Lighthouse is a lab test of one load on one simulated device. Core Web Vitals in Search use field data from real visitors, who have slower devices and networks. Check both, and use the lab run to find the cause.
How can I monitor Core Web Vitals continuously?
Combine the Search Console report for real-user trends with scheduled lab audits from several regions. Page speed monitoring runs Lighthouse on a schedule and alerts you when a metric crosses a budget.
Related terms
- What are Resource Hints?
- What Is a CDN (Content Delivery Network)? How It Works
- Performance Budget: Definition and Examples
- What is a Service Worker? Lifecycle, Caching and Limits
- Web Workers: Definition, Use Cases, Examples
- What is API Testing?
- What is Application Performance Monitoring (APM)?
- What is Benchmark Testing?
Related LoadFocus Tools
Put this concept into practice with LoadFocus, the same platform that powers everything you just read about.