# Core Web Vitals for site owners — LCP, INP and CLS without jargon
> Google measures three things about how a page feels: how fast the main content shows up, how quickly it reacts to taps, and whether it jumps around. This guide explains each in plain terms, what "good" means, where the numbers come from, and the usual cause behind each failing one.
Updated 2026-09-25 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/core-web-vitals-for-site-owners
Core Web Vitals are Google's answer to a question that used to be argued about: what does "fast" mean to a visitor? The answer is three measurements, taken from real Chrome users, each with a threshold. They are part of how Google ranks pages, they appear in Search Console, and every speed tool reports them. This guide explains what each one measures in visitor terms, where the numbers come from, and what usually causes a bad one. The fixes have their own guides.
## Quick answer
| Vital | Question it answers | Good | Poor |
| --- | --- | --- | --- |
| **LCP** Largest Contentful Paint | How long until the main content is on screen? | ≤ 2.5 s | > 4.0 s |
| **INP** Interaction to Next Paint | How long between a tap and the screen reacting? | ≤ 200 ms | > 500 ms |
| **CLS** Cumulative Layout Shift | How much did things jump around while loading? | ≤ 0.1 | > 0.25 |
A page passes when 75 % of visits are "good" on all three. The [Core Web Vitals checker](https://getreport.app/tools/core-web-vitals) shows the field numbers for your page and origin next to a lab run.
## Where the numbers come from
Chrome sends anonymous timing data from real visits to Google (users can opt out; the dataset is called CrUX). Google aggregates it per URL and per origin over a rolling 28 days and reports the 75th percentile: the value that three quarters of visits stayed under. That is the "field data" in Search Console and in speed tools. It is the only data Google uses for the ranking signal.
A lab tool (Lighthouse) loads the page once in a simulated phone and measures LCP and CLS directly; it cannot measure INP because it does not interact, so it reports Total Blocking Time as a stand-in. Lab data is for diagnosis: it is reproducible and it explains the field numbers.
Pages with little traffic have no field data. Google then uses the origin's aggregate; a brand-new site has nothing and is simply not judged on this until it does.
## LCP: is the main thing visible yet?
The browser watches the largest image or text block in the viewport as the page loads and records when it was painted. On a product page that is the product photo; on an article, the headline or the hero image; on a home page, the banner. Everything the browser must do before that paint counts: the server thinking, the HTML arriving, CSS blocking the render, a web font that the headline waits for, and the image file itself.
Typical causes of a poor LCP, most common first:
1. The LCP image is large (a camera original) or served in an old format.
2. The LCP image is lazy-loaded, so it only starts downloading after the layout is done.
3. Render-blocking CSS or JavaScript in the `` delays the first paint.
4. A slow server: TTFB over a second on shared hosting or an uncached CMS page.
5. A web font the headline waits for, with no `font-display` fallback.
Each is in [How to fix Largest Contentful Paint](https://getreport.app/guides/fix-largest-contentful-paint).
> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with or add fetchpriority="high" on the .
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.
## INP: does it react when I tap?
Every time a visitor taps, clicks or types, the browser measures the time until the next frame is drawn. INP is close to the worst of those over the whole visit (the slowest interaction, ignoring a few outliers on pages with many interactions). Under 200 ms feels instant; over 500 ms feels broken, like a menu that opens a moment after you tapped it.
The cause is almost always JavaScript running on the main thread when the tap arrives: a tag manager firing tags, a heavy framework hydrating, an event handler that does too much (recalculating the whole page on every keystroke), or third-party scripts (chat, A/B testing, ads) competing for the same thread.
> **Check: Interaction to Next Paint.** INP measures how quickly the page reacts when someone taps or clicks. Lab tools cannot simulate it, so this comes from real Chrome users; slow responses feel like a frozen page.
>
> 1. Break up long JavaScript tasks and defer third-party scripts so the main thread is free when people interact.
> 2. Respond to input visually first (a pressed state, a spinner), then do the heavy work.
> 3. Reduce DOM size and avoid layout-heavy work inside click handlers.
INP replaced First Input Delay in 2024. FID only measured the first interaction and only the delay before the handler ran; INP measures all interactions until the screen updates, which is why sites that passed FID can fail INP. See [How to fix Interaction to Next Paint](https://getreport.app/guides/fix-interaction-to-next-paint).
## CLS: did the page jump?
Layout shift is when something visible moves without the visitor doing anything: the text jumps down when an image above it loads, a cookie banner pushes the page, a font swap makes a paragraph longer. Each shift is scored by how much of the viewport moved and how far; CLS adds up the shifts in the worst burst. 0.1 means roughly "a tenth of the screen moved a bit"; 0.25 is the page visibly rearranging itself.
The four usual causes:
1. Images and embeds without `width` and `height` (the browser cannot reserve space).
2. Web fonts loading after the text was drawn in a fallback font.
3. Content injected above existing content: banners, notices, ads.
4. Animations that change layout properties (height, top) instead of transforms.
> **Check: Cumulative Layout Shift.** CLS measures how much the page jumps around while loading — the button that moves just as someone taps it. It is one of Google's three Core Web Vitals.
>
> 1. Give every ,