# Core Web Vitals: measure and improve LCP, INP, and CLS
> Measure real-user Core Web Vitals with Databuddy, distinguish field data from lab tests, and diagnose loading, responsiveness, and layout stability.
Core Web Vitals measure loading, responsiveness, and visual stability. Start with field measurements from your visitors, then use lab tools to reproduce and diagnose problems.
## What are Core Web Vitals?
| Metric | Measures | Good | Needs improvement | Poor |
| --- | --- | --- | --- | --- |
| LCP | Loading of the largest visible content element | ≤ 2.5 seconds | > 2.5 to 4 seconds | > 4 seconds |
| INP | Responsiveness to interactions | ≤ 200 milliseconds | > 200 to 500 milliseconds | > 500 milliseconds |
| CLS | Unexpected layout shifts | ≤ 0.1 | > 0.1 to 0.25 | > 0.25 |
Assess the **75th percentile**, separately for mobile and desktop. A fast average can hide a poor experience for a substantial share of visitors. See [Google's Web Vitals guidance](https://web.dev/articles/vitals).
## Monitoring Core Web Vitals
Enable performance collection on the tracker:
```html
```
Or use the React SDK:
```tsx
import { Databuddy } from "@databuddy/sdk/react";
;
```
Databuddy's Vitals dashboard shows collected metrics with page and device breakdowns, percentiles from p50 to p99, and previous-period comparisons. Performance collection also includes FCP, TTFB, and FPS; those are useful diagnostics but are not the three Core Web Vitals.
### Single-page applications
Databuddy associates reported measurements with the current path. A client-side route change does not restart the underlying document-level Web Vitals measurements. Do not interpret each route's INP or CLS as an independent fresh page load.
### Field data and lab tests
Field data reflects actual devices, networks, content, and interactions. Lab tools give you repeatable conditions for debugging, but a page-load test alone does not reproduce a visitor's full interaction history.
Use [PageSpeed Insights](https://pagespeed.web.dev/) to inspect available Chrome field data and a Lighthouse run. Use browser performance traces to investigate a specific interaction or layout shift. Small sites may not have enough traffic for public field data. [Google's tool comparison](https://web.dev/articles/vitals-tools) explains these differences.
## 1. Largest Contentful Paint (LCP)
LCP measures when the largest eligible image or text block becomes visible in the viewport. Diagnose the contributing delays before choosing a fix: server response, resource discovery, transfer time, and rendering can each matter.
### LCP optimization strategies
- Make the main content and its resources discoverable in the initial HTML.
- Size and compress the image actually displayed at each viewport.
- Do not lazy-load an above-the-fold LCP image.
- Use high fetch priority for the important image when appropriate; avoid marking every image high priority.
- Investigate slow responses and render-blocking work in a performance trace.
```html
```
The dimensions reserve space; they do not replace responsive image sizing. See [Optimize LCP](https://web.dev/articles/optimize-lcp) for diagnosing the loading stages.
## 2. Interaction to Next Paint (INP)
INP summarizes a page's responsiveness to clicks, taps, and keyboard interactions over the visit. Slow handlers, main-thread contention, and rendering work can delay the next paint.
### INP optimization strategies
- Reproduce the slow interaction, rather than testing only page load.
- Reduce work in event handlers and break up long tasks.
- Load optional features when needed and remove unused JavaScript.
- Move suitable computation to a worker when measurement shows it helps.
Loading a script asynchronously does not eliminate its execution cost. See [Optimize INP](https://web.dev/articles/optimize-inp).
## 3. Cumulative Layout Shift (CLS)
CLS uses the largest burst of unexpected layout shifts during the page's lifetime. A burst has less than a one-second gap between shifts and lasts at most five seconds. It is not an unbounded sum of every shift. See [Google's CLS definition](https://web.dev/articles/cls).
### CLS optimization strategies
- Set dimensions or an aspect ratio on images, video, and embeds.
- Reserve space for content that loads later, including ads and loading placeholders.
- Avoid inserting content above what someone is reading.
- Check font loading and animate transforms or opacity where appropriate.
For diagnostic measurements, use the maintained `web-vitals` library instead of implementing metric aggregation with a raw observer:
```javascript
import { onCLS, onINP, onLCP } from "web-vitals";
const reportMetric = ({ name, value }) => console.log(name, value);
onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);
```
This logs diagnostics. Databuddy already collects these metrics when `trackWebVitals` is enabled; do not add duplicate reporting just to populate its dashboard.
## Core Web Vitals and SEO
Google uses Core Web Vitals in its ranking systems, but good scores do not guarantee high rankings. Relevance, content, and other signals also matter. Improve performance for the people using your site, then assess search results separately. See [Google's page-experience guidance](https://developers.google.com/search/docs/appearance/page-experience).
## Measuring success
Compare equivalent periods and device groups before and after a change. Account for changes in traffic, page content, and visitor mix. Databuddy's previous-period view helps inspect the result; a correlation alone does not prove that a release caused it.
Use repeatable lab checks to catch regressions between releases. For continuous testing, follow the [Lighthouse CI setup](https://web.dev/articles/lighthouse-ci) and configure the build, running site, and URLs for your application.
The Databuddy tracker loads asynchronously. Measure its impact alongside your other scripts; no analytics script has a universal zero-cost guarantee.