# Core Web Vitals in 2026 — every threshold, one table.

> LCP, INP, CLS: the official thresholds, the 75th-percentile rule, lab vs. field data, and the most common causes per metric — the reference sheet to link to, as of June 2026.

**Author:** M. A. Mokhtar (Founder · SEO216) · **Published:** 2026-06-04 · **Category:** Engineering

The [Core Web Vitals](/en/resources/glossary/core-web-vitals) are three user-experience metrics defined by Google: **LCP** (main-content load time, good ≤ 2.5 s), **INP** (responsiveness to input, good ≤ 200 ms) and **CLS** (visual stability, good ≤ 0.1). A page passes when at least 75% of real visits reach the "good" range — assessed per metric, mobile and desktop separately. As of June 2026, these thresholds are unchanged.

This post is built as a reference sheet: all the numbers, the measurement rules, the most common causes per metric. To link, to forward, to look up.

## The thresholds (as of June 2026)

| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| **[LCP](/en/resources/glossary/lcp)** — Largest Contentful Paint | until the largest content element is visible | **≤ 2.5 s** | 2.5 – 4.0 s | > 4.0 s |
| **[INP](/en/resources/glossary/inp)** — Interaction to Next Paint | response to clicks, taps, keyboard (whole page lifetime) | **≤ 200 ms** | 200 – 500 ms | > 500 ms |
| **[CLS](/en/resources/glossary/cls)** — Cumulative Layout Shift | unexpected layout jumps (unitless score) | **≤ 0.1** | 0.1 – 0.25 | > 0.25 |

Plus two supporting metrics that are not Core Web Vitals but carry the diagnosis: **TTFB** (server response time, good orientation ≤ 0.8 s) and **FCP** (first visible content, good ≤ 1.8 s). A poor LCP almost always starts with a poor TTFB.

One watershed for reading older sources: **since 12 March 2024, INP is the official third metric**, replacing FID (First Input Delay). Any text still recommending FID values has been outdated since then — INP is considerably stricter, because it measures *every* interaction across the whole session, not just the delay of the first one.

## The three measurement rules audits trip over

**1. The 75th-percentile rule.** Google assesses the 75th percentile of real visits: a page passes a metric when at least three quarters of views land in the green range. The average is irrelevant — a good mean can hide a quarter of catastrophic visits.

**2. Field data beats lab data.** What counts are measurements from real Chrome users (the CrUX dataset, visible in PageSpeed Insights and Search Console's Core Web Vitals report). Lighthouse is a *lab test* on a simulated mid-range mobile device — indispensable for diagnosis, but not the report card. Which also means: your own desktop browser with a warm cache is worthless as a measuring instrument.

**3. Mobile and desktop are assessed separately.** Passing on desktop says nothing about mobile — and mobile is the bottleneck: simulated throttling in the lab, real radio connections in the field, weaker devices. If you check only one number, check the mobile one.

## Why the thresholds matter — the honest framing

Core Web Vitals are part of Google's page-experience assessment and feed into ranking — but they are one signal among many, not a sole decider. The honest formula: **good values don't win a ranking; bad values lose one.** With comparable content relevance, experience decides the tiebreak — and below the thresholds, every additional second measurably costs conversions: the [SXO](/en/resources/glossary/sxo) part of the equation, which holds even without Google. For AI crawlers with limited reading budgets the same argument applies once more: fast, static pages get read preferentially — [the GEO part of the equation](/en/blog/geo-vs-seo-difference).

## Diagnosis: the most common causes per metric

| Metric | Most common causes | The structural fix |
|---|---|---|
| **LCP** | slow server (TTFB), render-blocking CSS/JS, unoptimised hero images, external font CDNs | pre-rendered HTML from the edge, modern images (WebP/AVIF) with dimensions, [self-hosted fonts](/en/blog/google-fonts-gdpr-alternative) |
| **INP** | JavaScript main-thread blocking: plugin layers, whole-page hydration, third-party tags | ship less JS: static HTML, interactivity only where needed, prune the tags |
| **CLS** | images without dimensions, late-loading banners/embeds, font reflow (FOUT without a `swap` strategy) | fixed dimensions for everything late-loading, `font-display: swap` with tuned fallbacks, no layout injections |

The pattern behind all three columns: poor values are rarely an "optimisation problem" and usually an **architecture problem**. A stack that renders pages at runtime from a database through plugin layers fights its own construction — which is why [our new builds and migrations on Astro + Vercel](/en/services/build) clear the thresholds not by tuning but by design: pre-rendered HTML, mobile load under one second, Lighthouse scores of 95–100 as the normal state. Our internal budget deliberately sits *below* the official thresholds: LCP < 1.0 s, INP < 200 ms, CLS < 0.05.

## How to measure properly — in this order

1. **[Our free performance audit](/en/tools/audit)** — real PageSpeed Insights data for any URL, in seconds, no signup.
2. **Search Console → Core Web Vitals** — the field report across all pages of your domain, grouped by problem type. This is the view Google grades.
3. **Lighthouse / PageSpeed Insights** — the lab diagnosis per page, when you need to know *why* a value is poor.

That's why SEO216 builds on Astro and Vercel from the start — [static HTML from the edge, sub-second LCP from day one](/en/services/build), rather than clawing back slow scores later.

And once the diagnosis is in and the question "repair or rebuild?" is on the table: [the full audit answers it with measurements, a competitor comparison and a prioritised plan — within 24 hours, free.](/en/contact#audit)

---

**Canonical URL:** https://seo216.com/en/blog/core-web-vitals-thresholds-2026
**Source:** SEO216 — SEO agency, Darmstadt, Germany · https://seo216.com · hello@seo216.com