A practical guide to Core Web Vitals
Core Web Vitals describe three parts of a real visit: when the main content appears, how quickly the page responds to interaction, and whether visible content moves unexpectedly. They are useful when each metric is diagnosed separately.
The three current metrics and thresholds
Google classifies a page using the 75th percentile of eligible page views. To be considered good, at least 75 percent of experiences should meet the good threshold for each metric. The current thresholds are:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less | Over 2.5 through 4.0 seconds | Over 4.0 seconds |
| Interaction to Next Paint (INP) | 200 milliseconds or less | Over 200 through 500 milliseconds | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | 0.1 or less | Over 0.1 through 0.25 | Over 0.25 |
These targets come from Google's current Core Web Vitals guidance. They describe user experience, not a promise of search position. Search systems consider many signals, and useful content remains essential.
Field data and lab data are not interchangeable
Field data is collected from eligible real Chrome visits and summarized in the Chrome User Experience Report. It includes different devices, networks, locations, cache states, and visitor behavior. PageSpeed Insights may show page-level data or broader origin-level data when the individual URL does not have enough eligible traffic.
Lab data is produced by a controlled Lighthouse run. It is valuable for reproducing a loading path and inspecting diagnostics, but it represents one synthetic visit. A single run can change because of server load, network conditions, third-party responses, or the selected test environment.
Use both sources
Use field data to decide whether real visitors have a persistent problem. Use lab data and browser traces to locate a cause, test a change, and prevent regression before enough new field data accumulates.
Largest Contentful Paint: when the main content appears
LCP records when the largest eligible image, text block, or video poster in the viewport is painted. On many business pages this is a hero image, a large heading block, or a prominent banner. The browser must discover the resource, receive it, and render it before LCP can complete.
Common LCP causes
- A slow initial HTML response delays discovery of everything else.
- The main image is too large for its rendered dimensions.
- JavaScript inserts the main content only after the initial page load.
- CSS or fonts block rendering for longer than necessary.
- The LCP image is lazy-loaded even though it begins in the first viewport.
- A preload exists but does not match the actual responsive image selected by the browser.
A useful repair sequence
- Identify the LCP element in Lighthouse or a browser performance trace.
- Check server response time and redirects before optimizing the element itself.
- Make the resource discoverable directly in the initial HTML where practical.
- Resize and compress the image, serve responsive variants, and avoid lazy loading it.
- Reduce render-blocking work that prevents the ready resource from painting.
Do not preload every large file. Competing high-priority downloads can make the important resource slower.
Interaction to Next Paint: responsiveness throughout the visit
INP observes user interactions such as clicks, taps, and keyboard input, then measures how long it takes until the browser can present the next visual frame. It considers the interaction latency across the page's lifetime rather than only the first input.
Common INP causes
- Long JavaScript tasks keep the main thread busy when the visitor interacts.
- An event handler performs expensive rendering, data processing, or synchronous storage work.
- A large component tree is updated when only a small region needs to change.
- Third-party scripts compete for the main thread.
- The page performs layout calculation repeatedly by mixing DOM reads and writes.
Improve the interaction path
Profile a real slow interaction instead of optimizing the total script size blindly. Break long work into smaller tasks so the browser can respond between them. Give immediate visual feedback when longer work must continue, and avoid running unrelated work inside the event handler. Reduce unnecessary third-party scripts and delay optional code until it is actually needed.
A fast click handler is not enough if the browser then performs a very expensive render. Trace the complete interval from input through processing and presentation.
Cumulative Layout Shift: visual stability
CLS adds unexpected layout shifts that occur while the page is open. A shift is harmful when visible content moves without being caused by the visitor's recent action. A button moving just before a tap is more than a cosmetic problem; it can make the visitor activate the wrong control.
Common CLS causes
- Images, videos, maps, and embeds load without reserved dimensions.
- A consent banner or advertisement inserts space above existing content.
- A web font changes line wrapping after text has already appeared.
- Personalized or asynchronous content is inserted into an unreserved area.
- Animations change layout properties instead of using stable transforms.
Reserve the final geometry
Add width and height attributes or an aspect ratio for media. Give dynamic components a stable minimum size based on realistic content. Place overlays over the interface only when they do not cover required controls, and avoid pushing the whole page down after it becomes interactive. Test error messages and translated text because both can increase component height.
Why a page may have no field data
Chrome field data requires enough eligible visits to protect privacy and create a useful distribution. A new, low-traffic, private, or uncommon URL may have no page-level data. PageSpeed can then show origin-level data, lab data only, or no field data at all. This is not automatically a failure.
When data is missing, use Lighthouse and browser traces to remove obvious problems, then monitor the Search Console Core Web Vitals report as eligible traffic accumulates. Do not invent a field result from one lab score.
How to verify an improvement
- Record the exact URL, metric, element or interaction, device profile, and test time.
- Reproduce the issue in a performance trace and identify the largest cause.
- Make one meaningful change and deploy it to the public URL.
- Repeat several lab runs under comparable conditions and inspect the trace, not only the score.
- Monitor real-user or Chrome field data over the following collection period.
- Check related pages that share the same template or component.
Field data changes slowly because it represents a rolling population of visits. A lab improvement can be real even when the field classification has not changed yet. Conversely, one green Lighthouse run does not erase a persistent field problem.
Official references and next steps
Thresholds and metric definitions should be checked against current official guidance as browser measurement evolves.