Google's Core Web Vitals are a set of three field-measured performance metrics that contribute to ranking through the Page Experience signal. Here's what each one actually measures, what good looks like, and the engineering moves that shift them in the field — not just in a Lighthouse simulation.
Largest Contentful Paint (LCP)
What it measures: the time until the largest visible element loads. Typically the hero image, hero video, or a large block of text. Good: under 2.5s in the 75th percentile of real user data. How to fix: identify the LCP candidate, preload it, eliminate render-blocking resources above it, optimise image format and dimensions, prioritise its position in the critical render path.
Interaction to Next Paint (INP)
What it measures: the responsiveness of the page when a user interacts — click, tap, key press. INP replaced FID in 2024 and is significantly harder to optimise. Good: under 200ms. How to fix: reduce JavaScript main-thread work, defer non-critical scripts, use requestIdleCallback for low-priority work, break long tasks into chunks, audit event listeners for unnecessary work.
Cumulative Layout Shift (CLS)
What it measures: how much the page layout jumps around during loading. Good: under 0.1. How to fix: reserve space for images with width/height attributes, reserve space for ad slots, avoid inserting content above existing content, use font-display: swap with size-adjust.
Lab vs Field Data
The trap most engineers fall into is optimising for Lighthouse scores (lab data) rather than CrUX (field data). CrUX is what Google uses for ranking. If your Lighthouse score is 95 but your field LCP is 4 seconds, you'll lose ranking signal. Optimise for real users — not synthetic tests.
The CI Discipline
Without CI guardrails, performance regresses every sprint. We deploy Lighthouse CI checks on every PR plus a synthetic-monitoring tier on production. Performance budgets break the build. This is the only way to keep CWV stable long-term.