What are Core Web Vitals? LCP, INP, and CLS explained
Core Web Vitals are a set of Google metrics that measure the real-user experience of a web page: loading, interactivity, and visual stability. Learn what LCP, INP, and CLS measure, their target thresholds, and how to improve them.
On this page
- The three Core Web Vitals
- Largest Contentful Paint (LCP): measuring loading
- Interaction to Next Paint (INP): measuring interactivity
- Cumulative Layout Shift (CLS): measuring visual stability
- Field vs lab measurement
- How to improve Core Web Vitals
- FAQ
- What is the difference between field and lab Core Web Vitals?
- Which metric measures loading speed?
- Why did INP replace First Input Delay (FID)?
- What causes Cumulative Layout Shift (CLS)?
- Summary
If you have ever opened Chrome DevTools and seen a "performance" score, you have touched on the idea of Web Vitals. Core Web Vitals are a set of metrics, defined by Google, that quantify the real user experience of a web page in three dimensions: loading, interactivity, and visual stability. They are the subset of Web Vitals that apply to all web pages, are measured by all site owners, and are surfaced across Google's tools (PageSpeed Insights, Search Console, Chrome User Experience Report). Each of the three Core Web Vitals is measurable in the field, reflects a user-centric outcome, and has a clearly defined good/poor threshold. This guide explains what each metric measures, its target, and the practical changes that move the needle.
The three Core Web Vitals
The current set of Core Web Vitals focuses on three aspects of the user experience and includes the following metrics:
| Metric | What it measures | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading performance — when the page's main content is likely rendered | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Interactivity — how quickly the page responds to interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability — how much the layout unexpectedly moves | 0.1 or less |
To ensure you are hitting the targets for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.
Largest Contentful Paint (LCP): measuring loading
LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. It reflects perceived load speed: a fast LCP reassures users that the page is useful. Older metrics like load or DOMContentLoaded do not map to what the user actually sees, and First Contentful Paint (FCP) only captures the very beginning of the loading experience — which is why LCP tracks the largest element instead.
LCP considers a limited set of elements: <img> elements, <image> inside <svg>, <video> elements, elements with a background image loaded via url(), and block-level elements containing text. Chromium-based browsers use heuristics to exclude elements users see as "non-contentful", such as elements with opacity 0, elements that cover the full viewport, or placeholder images with low entropy.
A good LCP is 2.5 seconds or less; greater than 4.0 seconds is poor.
Interaction to Next Paint (INP): measuring interactivity
INP assesses a page's overall responsiveness to user interactions by observing the latency of every click, tap, and keyboard interaction that occurs throughout the visit. An interaction is a group of event handlers that fire during the same logical user gesture (for example, a tap triggers pointerdown, pointerup, and click together). The reported INP value is the longest interaction observed, ignoring outliers — for pages with many interactions, one highest interaction is ignored for every 50 interactions.
INP replaced First Input Delay (FID). FID only measured the input delay of the first interaction, whereas INP considers the full duration of all interactions across the whole visit. 90% of a user's time on a page is spent after it loads, so responsiveness throughout the page lifecycle matters.
An INP at or below 200 milliseconds means good responsiveness; above 500 milliseconds is poor.
Cumulative Layout Shift (CLS): measuring visual stability
Unexpected layout shifts can cause users to lose their place while reading or click the wrong button. A layout shift occurs whenever a visible element changes its position from one rendered frame to the next. CLS is the largest burst of layout-shift scores, where a burst (a "session window") is one or more shifts in rapid succession with less than one second between each and a maximum of five seconds total.
The layout shift score is the product of two measures: the impact fraction (how much the unstable elements affect the viewport area) multiplied by the distance fraction (how far the elements moved relative to the viewport's largest dimension).
A good CLS is 0.1 or less; greater than 0.25 is poor.
Field vs lab measurement
Core Web Vitals are, first and foremost, field metrics — measured from real users. Two kinds of tools read them:
- Field tools use the Chrome User Experience Report (CrUX), which collects anonymized, real user measurement data. PageSpeed Insights, Chrome DevTools, and Search Console's Core Web Vitals report all surface this data.
- Lab tools load a page in a controlled environment (like Lighthouse) to diagnose issues, using metrics such as Total Blocking Time (TBT) as a proxy for INP.
To measure the metrics in JavaScript, Google provides the web-vitals library, which wraps the underlying web APIs (onLCP(), onINP(), onCLS()) into simple calls.
How to improve Core Web Vitals
Because each metric measures a different facet, improving it takes different work:
- Improve LCP: eliminate render-blocking resources, optimize the server response time, preload and properly size the largest element, avoid slow third-party scripts.
- Improve INP: break up long tasks on the main thread, defer non-essential JavaScript, prefer simpler event handlers, and give immediate visual feedback on interaction.
- Improve CLS: reserve space (dimensions) for images and video, avoid injecting content above existing content, size custom fonts to avoid layout shift when they load, and avoid placing ads/widgets that dynamically resize.
On a real site, the highest-impact wins come from the low-hanging fruit — dimensions on media, self-hosted fonts with fallback sizing, and trimming render-blocking resources.
FAQ
What is the difference between field and lab Core Web Vitals?
Field metrics are measured from real users via the Chrome User Experience Report; lab metrics are measured in a controlled environment (for example with Lighthouse). Core Web Vitals prioritize field data because it reflects the real-world experience, while lab data helps diagnose specific issues.
Which metric measures loading speed?
Largest Contentful Paint (LCP) measures loading performance — the render time of the largest image, text block, or video visible in the viewport. A good LCP is 2.5 seconds or less.
Why did INP replace First Input Delay (FID)?
FID only measured the input delay of the first interaction, while INP measures the full duration of all interactions across the entire visit. Because 90% of a user's time is spent after a page loads, INP gives a more complete picture of responsiveness.
What causes Cumulative Layout Shift (CLS)?
Layout shifts usually happen when resources load asynchronously, images or videos load without reserved dimensions, fonts render differently from their fallback, or third-party ads/widgets resize themselves. CLS is the largest burst of these unexpected layout shifts, and a good score is 0.1 or less.
Summary
Core Web Vitals are the essential health metrics for any web page: LCP for loading, INP for interactivity, and CLS for visual stability, each with a concrete good threshold. They are measured from real users and surfaced across Google's tools, so optimizing them improves both user experience and search ranking. Start with the easy wins — dimensions on media, self-hosted fonts, and fewer render-blocking scripts — then use field data to find the next bottleneck.
Sources
- web.dev — Web Vitals (web.dev/articles/vitals
- CC BY 4.0)
- web.dev — Largest Contentful Paint (web.dev/articles/lcp
- CC BY 4.0)
- web.dev — Interaction to Next Paint (web.dev/articles/inp
- CC BY 4.0)
- web.dev — Cumulative Layout Shift (web.dev/articles/cls
- CC BY 4.0)
Share this guide
Related guides
- What is caching? Browser, CDN, server, and database caching explained
How caching works at every layer of the web — browser cache, CDN edge cache, server-side cache, and database cache — and when each one matters for speed and scalability.
- What is code splitting? How it works and when to use it
Code splitting divides a JavaScript bundle into smaller chunks that load on demand, speeding up initial page load. This guide explains the technique, the tools, and when it matters most.
- What is lazy loading? How deferring resources speeds up the web
Lazy loading is a performance strategy that defers non-critical resources (images, iframes, JavaScript, CSS) until they are needed. Learn what can be lazy-loaded, the native loading attribute, the Intersection Observer API, and when lazy loading helps or hurts.