Core Web Vitals, explained for people who just want a faster site

By Xenith Editorial25 July 2026

Someone sends you a screenshot of a red score and asks why the website is slow. Before you buy a caching plugin, understand what is being measured. Core Web Vitals are three specific numbers, each describing a different complaint a real visitor might have.

The thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. All three are judged at the 75th percentile of real visits, so you need three quarters of your traffic to pass, not your own laptop. Google documents how these cut-offs were chosen in Defining the Core Web Vitals thresholds.

The three metrics in plain language

Metric	The visitor's complaint	Good
LCP — Largest Contentful Paint	“The page took forever to show me anything useful.”	≤ 2.5s
INP — Interaction to Next Paint	“I tapped the button and nothing happened.”	≤ 200ms
CLS — Cumulative Layout Shift	“The page jumped and I clicked the wrong thing.”	≤ 0.1

LCP is not when the page finishes loading. It is when the biggest visible element in the viewport appears, usually a hero image, a heading, or a block of text. INP replaced the older First Input Delay metric because measuring only the first interaction flattered sites that got slow later.

Lab data and field data are not the same thing

Run Lighthouse in your browser and you get lab data: one simulated load, on your machine, on your connection. Search Console shows field data collected from real Chrome users over a rolling 28-day window. They disagree constantly, and when they do, field data is the one that counts.

Two consequences. First, a fix does not show up in Search Console the day you ship it; the 28-day window has to roll forward. Second, a page with very little traffic may have no field data at all, in which case Google groups it with similar pages on your site.

Fix in this order

Effort spent on the wrong metric is wasted. Open Search Console, find which metric fails and on which group of pages, then work down this list.

CLS first

It is usually the cheapest to fix and the most annoying to visitors. The causes are predictable:

Images and videos without width and height attributes, so the browser cannot reserve space.
Ads, embeds, and iframes injected into a container with no reserved height. This is the one that bites publishers hardest, and it gets worse the moment you add an ad network.
Web fonts that swap in at a different size, pushing text around.
Banners, cookie notices, and promo bars inserted above existing content instead of overlaid on top of it.

The fix is nearly always the same idea: reserve the space before the thing arrives.

LCP second

Identify the LCP element. Chrome DevTools names it for you in the Performance panel.
If it is an image, serve it in a modern format, size it for the actual display size, and give it fetchpriority="high". Do not lazy-load it; lazy-loading the hero image is a common own-goal.
Preload the font the headline uses, and use font-display:swap so text is never invisible while waiting.
Cut render-blocking CSS and JavaScript in the <head>. Every blocking request in there delays the first paint.
Check the server's time to first byte. A CDN in front of static files makes this mostly a solved problem.

INP last

INP is a JavaScript problem almost by definition. A static page with little script tends to pass without effort. If yours fails, the cause is long tasks blocking the main thread: heavy third-party tags, analytics stacks, chat widgets, carousels, or an event handler doing too much work in one go. Audit what you have added over the years and remove what nobody uses.

The awkward part: ads and performance pull against each other

Every ad network you add ships script, opens connections, and injects content into your layout. That pushes INP up and CLS up at the same time. You do not have to choose between revenue and speed, but you do have to be deliberate:

Reserve a fixed height for every ad container, so a late-arriving ad shifts nothing.
Cap the number of units per page. More units past a point cannibalise each other anyway.
Load ad script asynchronously and never in a way that blocks the first paint.
Re-measure field data a month after switching networks. Treat a metric regression as a cost of that network.

How much does this matter for ranking?

Less than the people selling optimisation services imply. Core Web Vitals are a real ranking input, but content relevance dominates. A fast page about nothing still ranks for nothing. The honest reason to fix these metrics is that layout shift and dead buttons cost you readers, signups, and sales directly, and that happens whether or not Google ever notices.

A sane routine: check Search Console once a month, fix whatever is red on the highest-traffic page group, and re-check after the 28-day window rolls. Ignore vanity scores from tools you ran once.

Where to look

Search Console → Core web vitals for field data grouped by page type. Start here.
PageSpeed Insights for a single URL, showing field and lab data side by side.
Chrome DevTools → Performance to find which element is your LCP and which task is blocking interaction.

Three numbers, three causes, one order of operations. That is the whole discipline.

No company paid for placement in this article. Verify current prices and terms with each provider before buying.