Core Web Vitals are Google's current set of field metrics for three parts of a page experience: loading, responsiveness, and visual stability. The metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
They are most useful as a shared language for finding real user-experience problems. They are not a complete quality score, and passing them does not guarantee rankings, conversions, accessibility, or a good product.
The three Core Web Vitals
Largest Contentful Paint
LCP measures when the largest eligible image, text block, or video poster visible in the viewport is rendered. It is intended to represent when the page's main visible content has likely appeared.
LCP includes more than the resource download. Redirects, connection setup, server response, late discovery, download time, fonts, JavaScript, and rendering can all contribute. A useful diagnosis separates those phases before choosing a fix.
Interaction to Next Paint
INP measures responsiveness across a page visit. It observes qualifying click, tap, and keyboard interactions, then reports a high-latency interaction while excluding some outliers. The timing covers input delay, event-handler processing, and the work required before the browser presents the next frame.
INP replaced First Input Delay as a Core Web Vital in 2024. It is broader because it considers interactions throughout the visit rather than only the first input.
Cumulative Layout Shift
CLS measures unexpected visual movement. It combines how much of the viewport is affected with how far elements move, grouped into session windows. CLS is unitless; it is not a duration in seconds.
Shifts that follow recent user input can be excluded from the metric, because some movement is expected after an intentional action. A shift can still be frustrating even when it does not count, so product review remains necessary.
Current thresholds
Google recommends evaluating the 75th percentile of visits separately for mobile and desktop.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 seconds or less | Over 2.5 through 4 seconds | Over 4 seconds |
| INP | 200 milliseconds or less | Over 200 through 500 milliseconds | Over 500 milliseconds |
| CLS | 0.1 or less | Over 0.1 through 0.25 | Over 0.25 |
These are the current thresholds documented by Google Search Central and the Web Vitals project. They are assessment boundaries, not promises that every experience just inside a boundary is ideal. Faster and more stable can still help users, provided the change does not weaken functionality or accessibility.
How the assessment is calculated
The 75th percentile means that at least 75% of measured visits are at or better than the reported value. A site should analyze mobile and desktop separately because their devices, networks, layouts, and interactions differ.
PageSpeed Insights can assess a specific URL or, when URL-level data is insufficient, show origin-level field data. Check the label before assuming the number belongs only to the page you tested.
When sufficient data exists for all three metrics, the Core Web Vitals assessment passes only when the 75th-percentile value of LCP, INP, and CLS is in the good range. Google documents limited handling when INP data is insufficient, but missing data is not the same as a passing measurement.
Field datasets also need enough eligible real-user samples. A new or low-traffic page may show no CrUX result. That does not mean the page is fast or slow; it means the public dataset cannot report it reliably.
Field data and lab data
Field data records actual visits across a distribution of devices, networks, locations, cache states, and user behavior. PageSpeed Insights obtains public field data from the Chrome UX Report and currently reports a trailing 28-day period.
Lab data runs a page under controlled conditions. Lighthouse is valuable for reproducing load problems, inspecting opportunities, and comparing a change. A standard page-load lab test cannot fully reproduce interactions and post-load layout shifts from a long real visit.
This explains common disagreements:
- A lab run may be slow while the 28-day field value is still good.
- A quick lab load may miss a consent banner or late shift that field users encounter.
- The field panel may show origin data while the lab panel tests one URL.
- A new fix appears immediately in lab data but takes time to affect a rolling field window.
Google's PageSpeed Insights documentation describes these two data sources. Use the lab trace to diagnose and field data to validate the experience at scale.
Where to measure Core Web Vitals
Use more than one view of the system:
- PageSpeed Insights for public CrUX context and a Lighthouse diagnostic run.
- Search Console for groups of indexed pages with similar field problems.
- Chrome DevTools Performance for LCP phases, layout-shift clusters, long tasks, and interaction traces.
- The
web-vitalslibrary or another RUM implementation for page-specific field attribution under your own traffic and privacy rules. - IndieTools Speed for published historical measurements and comparisons at /speed.
RUM should record enough context to act without collecting sensitive content. Useful dimensions may include route template, device class, app version, metric rating, and a bounded debug target. Avoid sending raw form values, full URLs with secrets, or user identifiers as performance metadata.
How Core Web Vitals relate to Search
Google says its core ranking systems seek to reward good page experience, and recommends good Core Web Vitals for Search success and user experience. It also makes clear that there is no single page-experience signal and that relevant content can still rank when some page-experience aspects are weaker.
That means Core Web Vitals are neither irrelevant nor a shortcut to first place. Improve them because visitors benefit and because page experience is part of a broader search system. Do not remove useful content, accessibility, security, or essential product behavior merely to raise a score.
Search performance also depends on crawlability, indexability, content quality, intent satisfaction, internal linking, structured data where appropriate, and many other signals. A fast empty page is not a useful result.
What Core Web Vitals do not measure
The three metrics do not directly prove:
- accessibility or keyboard support;
- security and privacy;
- task completion or conversion quality;
- correctness of content or commerce data;
- total page weight and data cost;
- every animation or scroll-performance issue;
- server availability;
- SEO relevance or authority;
- whether an interface is understandable.
FCP, TTFB, Total Blocking Time, and Speed Index can help diagnosis, but they are not current Core Web Vitals. What Is FCP and How to Fix It explains one of those supporting metrics without calling it a ranking metric.
A practical improvement workflow
- Identify important templates and segment field data by mobile and desktop.
- Prioritize a metric and route group with enough evidence and business relevance.
- Reproduce the problem in a lab trace or a real-user debug sample.
- Attribute it to a resource, server path, script, component, or layout event.
- Make one bounded change and test functionality, accessibility, and correctness.
- Compare equivalent lab runs before release.
- Deploy with monitoring and a rollback path.
- Watch RUM and public field trends through the full reporting window.
For metric-specific work, continue with the CLS guide or review the performance history for the relevant product on IndieTools Speed. Focus on the experience the metric reveals, not the color of a badge alone.
