Suggest an edit

Improve this article

Refine the answer for “Core Web Vitals”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

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

Markdown · drag & drop images · ⌘B / ⌘I shortcuts1087 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.