---
title: Core Web Vitals Explained: LCP, CLS, INP (and how to keep them green)
description: Google grades your pages on three numbers — and they affect both how your site feels and how it ranks. Here's what LCP, CLS and INP actually measure, what 'good' looks like, and how to fix them.
canonical: https://watchfor.io/blog/core-web-vitals-explained
---

# Core Web Vitals Explained: LCP, CLS, INP (and how to keep them green)

2026-06-19 · WatchFor Team · Performance · performance, seo, core-web-vitals

Google grades your pages on three numbers — and they affect both how your site feels and how it ranks. Here's what LCP, CLS and INP actually measure, what 'good' looks like, and how to fix them.

A visitor taps your "Buy" button. Nothing happens. They tap again — and *now* the page jumps, a cookie banner shoves everything down, and their tap lands on the wrong thing. They sigh and leave.

You just lost a sale to bad **Core Web Vitals** — and Google noticed too. These three metrics measure exactly that kind of friction, and they influence both how your site *feels* and how it *ranks*. The good news: they're very fixable once you know what they mean.

## What Core Web Vitals are (and why you should care)

Core Web Vitals are Google's set of **user-centric performance metrics** — real measures of loading, stability and responsiveness, not abstract lab scores. They matter for two reasons:

| Reason | Why it counts |
| --- | --- |
| **User experience** | Slow, janky, unresponsive pages drive people away. |
| **SEO** | Core Web Vitals are a Google ranking signal — better scores can mean better visibility. |

There are three of them, and each answers a simple human question.

## The three metrics

### LCP — Largest Contentful Paint

*"How long until the main thing shows up?"* LCP measures when the largest visible element (usually a hero image or headline) finishes loading. It's your proxy for "the page feels loaded."

### CLS — Cumulative Layout Shift

*"Does the page jump around as it loads?"* CLS measures unexpected movement — the cookie banner that shoves content down, the image that loads late and bumps everything. High CLS is the "I tapped the wrong button" experience.

### INP — Interaction to Next Paint

*"When I tap or click, does it respond quickly?"* INP measures responsiveness across the whole visit. It replaced FID (First Input Delay) as a Core Web Vital in 2024 because it captures *every* interaction, not just the first.

### What "good" looks like

Google buckets each metric into Good / Needs improvement / Poor. Aim for green:

| Metric | Good | Needs improvement | Poor |
| --- | --- | --- | --- |
| **LCP** | ≤ 2.5s | 2.5s – 4.0s | over 4.0s |
| **CLS** | ≤ 0.1 | 0.1 – 0.25 | over 0.25 |
| **INP** | ≤ 200ms | 200ms – 500ms | over 500ms |

## Common causes — and fixes

The same handful of culprits cause most bad scores:

| Metric | Common cause | Fix |
| --- | --- | --- |
| **LCP** | Huge unoptimised hero image | Compress, resize, use modern formats, preload it |
| **LCP** | Slow server response (TTFB) | Faster backend, caching, a CDN |
| **CLS** | Images/embeds with no dimensions | Always set width/height (or aspect-ratio) |
| **CLS** | Banners/ads injected at the top | Reserve space for them up front |
| **INP** | Heavy JavaScript blocking the main thread | Split code, defer non-critical JS, do less work on interaction |

> **Rule of thumb:** most LCP problems are about *weight and the server*, most CLS problems are about *reserving space*, and most INP problems are about *too much JavaScript*. Knowing which bucket you're in tells you where to look.

## Lab vs. field: why your scores disagree

You'll see two kinds of measurement, and they often differ:

- **Lab data** (synthetic) — a tool loads your page in a controlled environment. Great for debugging and catching regressions before release, but it's one device on one connection.
- **Field data** (real users) — actual visits from real phones and networks. This is what Google uses for ranking, because it reflects reality — including that one user on a five-year-old phone on hotel Wi-Fi.

You need both: lab to catch problems early, field to know what your users actually experience.

## How to keep them green over time

Core Web Vitals aren't "fix once and forget." A new hero image, a third-party script, or an ad tag can quietly wreck a score months later. The fix is to **monitor them continuously** and get alerted when a score regresses — before it costs you traffic or rankings.

## The bottom line

| Metric | Question it answers | Good score |
| --- | --- | --- |
| **LCP** | When does the main content appear? | ≤ 2.5s |
| **CLS** | Does the layout stay stable? | ≤ 0.1 |
| **INP** | How fast does it respond to input? | ≤ 200ms |

Core Web Vitals reward the same thing your users do: pages that load fast, hold still, and respond instantly. Fix them and you win twice — happier visitors *and* a friendlier nod from Google.

You can check any page's Core Web Vitals right now with our free [Core Web Vitals checker](/core-web-vitals-checker), and set up continuous tracking with the [performance monitoring guide](/docs/monitors/performance) so a regression never sneaks past you.

---

Canonical page: https://watchfor.io/blog/core-web-vitals-explained · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt