Core Web Vitals

What are Core Web Vitals?

Core Web Vitals are a small set of metrics that Google defines as part of its Web Vitals initiative to describe how users experience a web page. Each metric covers one dimension: how quickly the main content appears, how quickly the page responds to input and how stable the layout is while it loads. Google uses Core Web Vitals as part of its page experience signals in search, but their main value is operational: they turn "the site feels slow" into measurable numbers.

The set is reviewed over time. In March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric, because FID only measured the delay of the first interaction, while INP considers the latency of all interactions during a visit.

The three Core Web Vitals and their thresholds

Metric	Measures	Good	Needs improvement	Poor
LCP Largest Contentful Paint	Time until the largest image or text block in the viewport is rendered	≤ 2.5 s	2.5–4.0 s	> 4.0 s
INP Interaction to Next Paint	Latency from user input (click, tap, key) to the next frame painted	≤ 200 ms	200–500 ms	> 500 ms
CLS Cumulative Layout Shift	Unexpected layout movement, as a unitless score	≤ 0.1	0.1–0.25	> 0.25

These thresholds are assessed at the 75th percentile of page loads, segmented by mobile and desktop. A page passes only if at least 75 % of visits meet the good threshold for each metric. Using p75 rather than the average makes sure that most users, not just the ones on fast devices, get a good experience.

Field data vs. lab data

Core Web Vitals can be measured in two ways. Field data comes from real users and real devices, for example through real user monitoring or Google's Chrome User Experience Report (CrUX). Lab data comes from controlled test runs with tools such as Lighthouse or scripted synthetic checks. Lab tests are reproducible and good for catching regressions before release, but they cannot reproduce the full variety of devices, networks and behaviour. INP in particular depends on real interactions and is primarily a field metric; lab tools use proxies such as Total Blocking Time.

Example: measuring Core Web Vitals in the browser

Google's open-source web-vitals JavaScript library reports the metrics from real sessions. An illustrative setup that sends them to a collection endpoint:

import { onLCP, onINP, onCLS } from "web-vitals";

function send(metric) {
  navigator.sendBeacon("/rum", JSON.stringify({
    name: metric.name, value: metric.value,
    rating: metric.rating, page: location.pathname
  }));
}
onLCP(send); onINP(send); onCLS(send);

Aggregated per page template and device class, these values give the p75 numbers that matter. Pairing them with backend data shows whether a slow LCP is caused by the server, for instance a high Time to First Byte, or by the front end.

Two details matter when interpreting the values. LCP and CLS are finalised only when the page is hidden or the user interacts, so the library may report them late or update them; always send the final value. INP reports the slowest interaction of a visit, with outliers ignored on pages with very many interactions, so a single slow menu or filter can determine the score of a whole page.

How to improve Core Web Vitals

• LCP: reduce server response time, preload the LCP image, serve correctly sized and compressed images, avoid render-blocking CSS and JavaScript, and use a CDN.
• INP: break up long JavaScript tasks, defer non-critical scripts, reduce third-party code, and keep event handlers short so the browser can paint quickly.
• CLS: set explicit width and height for images and embeds, reserve space for ads and banners, and avoid inserting content above existing content after load.

Common mistakes

• Optimising only lab scores while real users on mid-range phones still see poor values.
• Looking at site-wide averages instead of p75 per page template and device type.
• Still tracking FID, which is no longer a Core Web Vital.
• Treating front-end metrics in isolation, without linking them to backend latency or releases.

How Obseria helps

Obseria's real user monitoring collects LCP, INP and CLS from real sessions and reports them at p75 by page, device and region. Sessions with poor values can be opened in session replay, and front-end spans are connected to backend traces, so you can see whether a slow page is caused by the browser, the network or a specific service.