Core Web Vitals from real users: LCP, INP and CLS explained

Core Web Vitals are Google's three user-experience metrics, and a ranking signal, but their real value is simpler: they quantify what your site feels like on hardware and networks you never test on.

The metrics in one breath each

• LCP (Largest Contentful Paint): when the main content becomes visible. Good ≤ 2.5s, poor > 4s.
• INP (Interaction to Next Paint): how fast the page responds to taps, clicks and keys across the whole visit. Good ≤ 200ms, poor > 500ms.
• CLS (Cumulative Layout Shift): how much the page jumps around. Good ≤ 0.1, poor > 0.25.
• FCP and TTFB: first paint and server response, the supporting diagnostics for a slow LCP.

Lab vs field: why Lighthouse disagrees with reality

Lighthouse runs once, on one simulated device, with a warm CDN and no third-party chaos. Your visitors run thousands of times on three-year-old Androids, hotel wifi and extension-stuffed browsers. Field data (real-user monitoring) routinely shows a page scoring 95 in Lighthouse delivering 4-second LCPs to a quarter of its actual audience. Lab data is for debugging; field data is for knowing.

Read percentiles, not averages

Performance data is heavily skewed, and averages bury the suffering. The standard is p75: "three quarters of visits were at least this fast", which is also what Google's ranking assessment uses. And always segment before concluding: a fine overall p75 regularly hides a mobile p75 twice as slow, or one country routed badly, or one page whose hero image ballooned in last week's deploy.

The usual fixes, in order of payoff

Slow LCP: shrink or preload the hero image, cut server response time, remove render-blocking scripts. Bad INP: break up long JavaScript tasks and defer non-critical work. Bad CLS: give images and embeds explicit dimensions and stop injecting banners above content. Then watch the field p75, not the lab score, to confirm real users got the improvement.