Core Web Vitals: Measure and Improve LCP, INP, and CLS

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?

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.

Monitoring Core Web Vitals

Enable performance collection on the tracker:

<script
  async
  src="https://cdn.databuddy.cc/databuddy.js"
  data-client-id="YOUR_WEBSITE_ID"
  data-track-web-vitals="true"
></script>

Or use the React SDK:

import { Databuddy } from "@databuddy/sdk/react";

<Databuddy clientId="YOUR_WEBSITE_ID" trackWebVitals />;

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 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 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.

<img
  src="/product-preview.webp"
  alt="Product dashboard showing traffic and conversions"
  width="1200"
  height="800"
  fetchpriority="high"
/>

The dimensions reserve space; they do not replace responsive image sizing. See 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.

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.

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:

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.

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 and configure the build, running site, and URLs for your application.

The Databuddy tracker is about 12 KB gzipped and loads asynchronously. Measure its impact alongside your other scripts; no analytics script has a universal zero-cost guarantee.