Core Web Vitals in Search Console: LCP, INP & CLS

Core Web Vitals are Google's attempt to reduce 'is this page unpleasant to use' to three numbers. The Search Console report is not a lab tool — it reports what real Chrome users actually experienced on your site, which is why it disagrees with Lighthouse so often, and why it is the one that counts.

The three metrics

How a URL passes

Two rules, and both surprise people:

1. 1All three metrics must be Good. Two out of three is a fail. There is no partial credit.
2. 2Measured at the 75th percentile. Your *median* user is irrelevant. Google takes the experience of your unluckiest quarter of visitors — the ones on older Androids and worse networks — and grades you on that.

The 75th-percentile rule is the reason a site that feels instant on your laptop can fail outright. You are not the sample.

Field data vs. lab data — why the numbers disagree

URL groups: why one URL 'has no data'

Google needs enough real traffic to report a metric without exposing individuals, so low-traffic URLs get no field data at all. To cover them, it buckets structurally similar pages into URL groups and reports on the group.

Two consequences worth internalizing:

• A URL you never optimized can be flagged because a *sibling* in its group is slow — the group's data is applied to all of it.
• Fixing one popular page in a group can lift the reported score for every page in it. Template-level fixes are worth far more than page-level ones.

The fixes that actually move each metric

LCP — usually an image problem

• Find the LCP element first. It is nearly always the hero image or the headline. Optimizing anything else is wasted effort.
• Never lazy-load it. Lazy-loading the LCP image is the single most common self-inflicted LCP failure. In Next.js, set priority on that image.
• Serve modern formats — AVIF or WebP, correctly sized. A 3 MB PNG hero cannot pass, however fast your server is.
• Preload the hero image and the fonts it needs, so discovery does not wait on CSS parsing.
• Check server response time. A slow TTFB puts a floor under LCP that no front-end work can lift.

INP — usually a JavaScript problem

• Break up long tasks. Any task over 50ms blocks the main thread and delays the next paint.
• Ship less JavaScript. Hydrating an entire page to make one button interactive is the standard modern mistake. Keep components server-rendered unless they genuinely need state.
• Defer non-critical third parties. Chat widgets, analytics, A/B testing tools, and consent managers are, in practice, the top INP offenders on most sites.
• Yield to the main thread during heavy work rather than blocking through it.

CLS — almost always missing dimensions

• Set width and height on every image, so the browser reserves the space before the file arrives.
• Reserve space for ads, embeds, and banners. Anything that appears late and pushes content down is a shift.
• Use `font-display: swap` with a size-matched fallback, so the text does not reflow when the webfont loads.
• Never inject content above existing content — cookie bars and promo banners are the classic culprits.

How much does this really affect ranking?

Honestly: less than the amount of attention it receives. Page experience is a real but weak signal, and it is a tiebreaker rather than a lever. A slow page with the best answer will still outrank a fast page with a worse one. Nobody has ever ranked first for being fast.

Which is not an argument to ignore it. The reason to fix Core Web Vitals is that they measure something genuinely worth caring about — a page that jumps around while loading and stalls when tapped loses users regardless of where it ranks. Fix them for conversion and for the people using your site; treat any ranking benefit as a bonus.