Core Web Vitals Explained: LCP, INP and CLS

Core Web Vitals are three measurements of what a page feels like to use. Not how well built it is, not how much code it ships. How it feels.

Strip the acronyms away and each one is a complaint a real person might say out loud:

• LCP answers "how long did I stare at a half built page before the main thing appeared?"
• INP answers "I tapped that button, how long until anything happened?"
• CLS answers "why did the page move while I was reading and make me tap the wrong thing?"

Two facts about how the numbers are produced matter more than any single fix.

First, every Core Web Vital is reported at the 75th percentile, not the average. Sort every page load from fastest to slowest and read the value three quarters of the way along. This is why averages mislead: you can have a healthy median and still fail, because the failure lives in the tail. Improving the typical visit does not move the number that gets reported.

Second, the numbers that count come from real visits, collected from Chrome users who have opted into usage statistics reporting and aggregated over a rolling 28 day window in the Chrome User Experience Report (CrUX). They are not produced by running a test on your laptop. Section 6 is entirely about that distinction, because it causes more confusion than the metrics themselves.

Each metric is reported separately for mobile and desktop. Sites routinely pass on desktop and fail on mobile, because mobile field data reflects slower devices and worse networks than the machine you are reading this on.

These are Google's published thresholds. They have been stable for LCP and CLS since those metrics launched, and were set for INP when it became a Core Web Vital in March 2024. All three are evaluated at the 75th percentile of page loads, split by mobile and desktop.

A note on that middle column, because it trips people up. "Needs improvement" is not a soft pass. To be assessed as good overall, a URL group has to land in the good band on all three metrics. Two greens and one amber is a fail.

CLS is the odd one out because it has no unit. It is a score, not a time. A CLS of 0.1 roughly means visible content moved by an amount equal to a tenth of the screen, weighted by how much of the screen was affected. Do not try to convert it into pixels or seconds.

In human terms: you tapped a search result. LCP is the moment the page stops looking like it is still arriving and the main image or headline is actually there.

Technically, LCP records when the largest text block or image inside the visible area finishes rendering. On an article that is the hero image or the headline. On a product page it is usually the product photo. Google splits LCP into four consecutive parts, and knowing which part is fat tells you who has to fix it.

In human terms: you tapped "Add to cart" and nothing visibly happened for a beat. INP measures that beat.

INP watches every click, tap and key press across the whole time someone spends on the page, measures how long each one took to produce a visible update on screen, and reports close to the worst one. Not an average, and not the first interaction. That design is deliberate, because one stuck interaction is what a person actually remembers.

In human terms: you started reading, a banner loaded above what you were reading, the text shot downward, and your thumb landed on the wrong link. CLS scores how often and how badly that happens.

CLS multiplies how much of the screen moved by how far it moved, for every unexpected shift. Since June 2021 it does not simply add up every shift for the whole session. It groups shifts into windows (a new window starts after a one second gap, and no window runs longer than five seconds) and reports the worst single window. One catastrophic moment counts against you far more than a long tail of tiny nudges. Shifts within 500 milliseconds of a user interaction are exempt, so tapping "show more" and watching the page expand is not penalized.

This one distinction explains most Core Web Vitals arguments, so here it is plainly.

Lab data is a simulation. Lighthouse, which powers the bottom half of PageSpeed Insights and lives in Chrome DevTools, loads your page once, on one machine, over a deliberately throttled connection with a deliberately slowed CPU, with no extensions, no logged in session, no warm cache and nobody touching the screen.

Field data is what actually happened. CrUX aggregates measurements from real Chrome users on real devices and networks over a rolling 28 day window, reported at the 75th percentile. It is what appears at the top of PageSpeed Insights under the heading about what real users are experiencing, and it is what the Search Console Core Web Vitals report is built on.

Read that INP row again. Lighthouse cannot measure INP at all. There are no interactions in a lab run. Any tool showing an INP figure from a single automated page load is showing you an estimate, usually derived from Total Blocking Time. This is why a page with a 98 Lighthouse score can sit in the red for INP in Search Console, and neither number is lying to you.

The CLS row matters almost as much. Lighthouse stops watching after load, so lab CLS understates the real thing. The ad that refreshes 30 seconds in, the lazy loaded footer, the sticky bar that appears on scroll: field CLS sees all of them and lab CLS sees none.

Here is the walkthrough. Search Console's navigation labels move between releases, so match on the words rather than the position in the menu.

1. Open Google Search Console and select the property. Use a domain property if you have one, so subdomains are included.
2. In the left navigation, find the Experience group and open Core Web Vitals.
3. You get two cards, Mobile and Desktop. Click Open report on Mobile first. Mobile is where the failures are.
4. The chart at the top plots URL counts in Poor, Needs improvement and Good over roughly the last 90 days. The step changes in that chart are your deployment history, whether or not anyone labeled them.
5. Below it sits a table of issues phrased like "CLS issue: more than 0.25 (mobile)", with a URL count beside each row.
6. Click an issue row. You now see URL groups, not individual URLs, each with one example URL. Click the example, then use Inspect URL or the PageSpeed Insights link for detail.
7. Once a fix is deployed, click Validate fix. Validation runs against incoming field data, so it takes weeks, not hours.

Print this one. It is the fastest way to stop a Core Web Vitals conversation turning into a standoff.

Here is the honest version, because overselling this is how SEO budgets get wasted.

Core Web Vitals are a real input to search ranking systems and they are a small one. Google's page experience guidance is explicit that a good page experience does not override having genuinely relevant, useful content. A fast page that fails to answer the query loses to a slower page that answers it. If your pages are not ranking, Core Web Vitals are rarely the reason, and fixing them will not create rankings on their own.

Where the work does pay off:

• When you are already competitive. Between pages of comparable relevance and authority, experience signals can be part of what separates them.
• On conversion, which is not a ranking argument at all. A page that loads in 2 seconds instead of 5, and does not move under the reader's thumb, converts better. That effect is yours regardless of what any ranking system does with the data.
• As a symptom. A page failing LCP badly usually fails because of something else worth fixing: a bloated template, an over-plugged CMS, a hosting tier that stopped being adequate two years ago.

Treat Core Web Vitals as part of the broader technical SEO baseline: things that should be in order rather than things that generate growth by themselves. Be as skeptical of "fix Core Web Vitals to rank" as you should be of any single-lever ranking claim, in the same way that bounce rate is not a ranking factor despite how often it gets presented as one. The neighboring work that actually compounds is making sure the page delivers on the promise that earned the click, covered in satisfying search intent above the fold.

Field data moves slowly and looks noisy. Without a design you will either declare victory too early or conclude your fix did nothing.

Baseline. Before changing anything, record the field values for the failing URL group: LCP, INP and CLS from PageSpeed Insights for the example URL, plus the URL counts in each band from Search Console. Note the date. CrUX will not show you what the number was last month.

Control set. Pick a second template failing in a similar way and deliberately leave it alone. Almost everybody skips this, and it is the step that separates your fix from a seasonal traffic shift, a change in device mix or a Chrome release. If both groups improve, your fix was not the cause.

Change window. Deploy to the treatment template only, and log the exact date and time somewhere you will find it again.

Wait properly. CrUX aggregates over 28 rolling days, so the day after deployment the reported number still contains 27 days of the old behavior. Expect partial movement around day 10 and the full effect at day 28. Reading the number on day 3 and concluding nothing changed is the most common self-inflicted wound in this work.

What counts as signal. Judge on the band, not the decimal. LCP moving from 4.6 to 4.4 seconds is noise. LCP moving from 4.6 to 2.3 seconds, crossing Poor to Good, is a result. In Search Console, watch the count of URLs in the Good band for that group, not the example URL's individual figure.

Real user monitoring, if a developer can add it, gives you your own field data daily instead of on a 28 day lag, segmented by template, device and country in ways CrUX will not offer.