Core Web Vitals

JavaScriptJunior~5 min read

Core Web Vitals is a set of three Google metrics that measure the real user experience: how fast a page loads (LCP), how responsive it is to input (INP), and how stable it looks while loading (CLS). These metrics are part of Google Page Experience, so they directly affect SEO ranking and whether a user stays on the site.

Theory

TL;DR

LCP (Largest Contentful Paint): how fast the user sees the main content. Good: ≤ 2.5 s.
INP (Interaction to Next Paint): how fast the page reacts to a click, a keystroke or a tap. Good: ≤ 200 ms. This is the new metric that replaced FID in 2024.
CLS (Cumulative Layout Shift): how stable the layout is, whether elements jump around during loading. Good: ≤ 0.1.
The metrics are collected in two ways: in the lab (Lighthouse, DevTools) and from real users (Chrome UX Report, the web-vitals library).
A bad result almost always has a technical cause: heavy images, blocking JS, long tasks on the main thread, elements inserted without reserved space.

Quick example

javascript

// Measure the three Core Web Vitals on a live page and send them to your own analytics.
import { onLCP, onINP, onCLS } from 'web-vitals';

function report({ name, value, rating }) {
  // rating arrives as 'good', 'needs-improvement' or 'poor'
  navigator.sendBeacon('/api/vitals', JSON.stringify({ name, value, rating }));
}

onLCP(report); // good: ≤ 2500 ms
onINP(report); // good: ≤ 200 ms
onCLS(report); // good: ≤ 0.1

The three metrics of the set

Metric	What it measures	Ideal value
LCP (Largest Contentful Paint)	how fast the user sees the main content (the largest element on screen)	≤ 2.5 s
INP (Interaction to Next Paint) (new metric since 2024, replaces FID)	how fast the page reacts to user actions (click, typing, tap and so on)	≤ 200 ms
CLS (Cumulative Layout Shift)	how stable the layout is, whether elements move during loading	≤ 0.1

LCP: Largest Contentful Paint

What it measures: the time it takes for the largest element in the viewport (an image, a heading, a block) to become visible to the user.

In essence this shows when the page has visually "formed".

Good: ≤ 2.5 s Needs improvement: 2.5 to 4 s Poor: > 4 s

Typical causes of a bad LCP:

a slow server, a large TTFB;
blocking CSS and JS;
large unoptimised images;
no lazy loading;
rendering only after heavy JS computation.

How to improve it:

optimise images (next/image, WebP, correct dimensions);
set up a CDN and caching;
use preload for fonts and critical resources;
remove blocking JS from <head> or give it defer.

INP: Interaction to Next Paint

What it measures: how much time passes from a user action (click, typing, tap) to the moment the interface visually responds.

That is: the user pressed a button, and the question is when the reaction appeared (an animation, a text change and so on).

Good: ≤ 200 ms Needs improvement: 200 to 500 ms Poor: > 500 ms

Causes of a bad INP:

long JavaScript tasks (over 50 ms);
synchronous computation on the main thread;
heavy re-renders of React or Vue components;
delays inside event handlers.

How to improve it:

split heavy computation into chunks (setTimeout, requestIdleCallback);
move CPU load into Web Workers;
optimise React re-renders (memoisation, useCallback);
shrink the bundle (code-splitting, lazy loading).

CLS: Cumulative Layout Shift

What it measures: how strongly page elements shift while the page loads. For example: a banner finishes loading and everything below it moves down.

The more unexpected movement there is, the worse the UX.

Good: ≤ 0.1 Needs improvement: 0.1 to 0.25 Poor: > 0.25

Causes of a bad CLS:

images without fixed dimensions;
ad blocks and embedded videos without a container;
dynamic fonts without a fallback;
lazy elements inserted without reserved space.

How to improve it:

always set width and height on <img>;
use aspect-ratio for videos and banners;
reserve layout space in advance;
load fonts with font-display: swap.

Where to look at these metrics

Tool	What it shows
Lighthouse / PageSpeed Insights	a Core Web Vitals summary plus recommendations
Chrome DevTools, Performance tab	the Web Vitals track while recording a profile
Google Search Console	real per-page data from the Chrome UX Report
web-vitals.js	a library for measuring in real time on the site itself
Chrome UX Report (CrUX)	aggregated data from real users

An important distinction: Lighthouse is lab data (one synthetic session), while CrUX and web-vitals are field data from real users. Google ranks on the field data.

Why it matters

Core Web Vitals:

are part of Google Page Experience, which makes them a ranking factor;
directly affect user retention;
show how convenient and responsive the site really is.

A fast site means higher conversion, fewer bounces and better search positions.

Common mistakes

Confusing INP with FID. FID measured only the delay before the first interaction started being processed. INP looks at every interaction during the page's lifetime and includes the time to the next paint, so it is stricter.
Optimising only the lab report. A score of 100 in Lighthouse on a powerful laptop guarantees nothing: in the field users have weaker devices and worse networks.
Treating CLS as a design problem rather than a code problem. Almost every shift is a missing width/height, a font without a fallback, or a node inserted without reserved space.
Chasing the overall "performance score". That score is a weighted blend; ranking relies on LCP, INP and CLS themselves.
Assuming a shift after a click is a defect. Shifts within 500 ms of a user interaction are excluded from CLS because they are expected.

Summary

Metric	What it checks	Good when
LCP	when the main content loads	≤ 2.5 s
INP	how fast the site reacts to actions	≤ 200 ms
CLS	how stable everything on screen is	≤ 0.1

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.