Core Web Vitals: LCP, INP and CLS without the myths

What Google's three metrics actually measure, why lab numbers disagree with field data, and which fixes move the needle.

Performance · Published: 18 August 2026 · Updated: 26 August 2026 · 3 min read · Анна Ковалёва

Core Web Vitals are three numbers Google collects from real users. They get confused with "the Lighthouse score", but they are not the same thing: Lighthouse is a lab run under sterile conditions, the Vitals come from the field — from people on slow 4G with three-year-old phones.

LCP — when the user sees the main thing

Largest Contentful Paint records the moment the largest element in the viewport renders: usually a banner, an article cover or the H1. The threshold is 2.5 seconds at the 75th percentile.

Typical causes of a slow LCP, in order of frequency:

1. The hero image loads late. fetchpriority="high" on the LCP image and a preload for the heading font both help.
2. Slow server response. Above 600 ms TTFB, optimising the frontend is pointless — fix caching and the database first.
3. Render-blocking CSS. A single @import inside an external file costs a full network round trip.
4. Client-side rendering. If the LCP element only appears after hydration, JS download and parse time are added on top.

INP — the price of interactivity

Interaction to Next Paint replaced FID in 2024 and is considerably stricter. It takes not the first interaction but effectively the worst one in the session: from the click to the next paint. The threshold is 200 ms.

The main culprit is long tasks on the main thread. A handler that synchronously recalculates the cart, filters a 5,000-item list or calls getBoundingClientRect in a loop can hold the thread for 400 ms. Three remedies: split the work with scheduler.yield(), take analytics and third-party scripts off the critical path, and move heavy computation into a Web Worker.

CLS — a layout that does not jump

Cumulative Layout Shift sums up unplanned content movement. The threshold is 0.1. The causes are almost always the same:

• images and iframes without width/height or aspect-ratio;
• banners and cookie bars injected into the flow after load;
• web fonts without font-display: optional or without matched fallback metrics.

Lab versus field

A lab run is deterministic and excellent for catching regressions in CI. Field data (CrUX, your own RUM) shows reality, but with a 28-day lag. The workable arrangement is to measure both and investigate only the lab regressions the field confirms.

The order of work that pays off

Measure the distribution first, not the average: p75 and p95 per page type. Then find the single template with the worst numbers — usually a product page or search — and fix it completely. Small corrections smeared across the whole site almost never move p75.

And check the result on a real device, not on your laptop: for INP the gap between a MacBook and a budget Android reaches a factor of five.