CHASING GREEN: WEB VITALS IN THE REAL WORLD

Core Web Vitals are Google's attempt to quantify the user experience of a web page into three numbers: LCP (how fast the main content loads), CLS (how much the layout shifts unexpectedly), and INP (how quickly the page responds to interactions). Getting all three into the 'good' range on a real production site requires understanding what actually drives each metric — not just running Lighthouse and acting on whatever it flags.

LCP is dominated by the largest visible element, which is usually a hero image or a heading. The fastest wins here are almost always image-related: proper sizing, modern formats (WebP or AVIF), and — critically — adding fetchpriority='high' to the LCP image so the browser doesn't deprioritize it. Next.js's Image component handles most of this automatically, including the priority prop.

CLS is caused by content that shifts after it's rendered — images without dimensions, late-loading fonts, or dynamic content injected above existing content. The fix is almost always to reserve space: set explicit width and height on images (even if you override with CSS), use font-display: optional or swap with size-adjust to match fallback metrics, and avoid inserting content above the fold after load.

INP replaced FID in 2024 and is the hardest to optimize because it measures all interactions, not just the first. Long tasks on the main thread are the culprit — JavaScript that runs for more than 50ms blocks the browser from responding to clicks and key presses. The fix is breaking long tasks up with scheduler.yield() or queueMicrotask(), and deferring non-critical third-party scripts.

The gap between Lighthouse scores and real-user data (via Chrome UX Report or web-vitals.js) is often surprising. Lighthouse runs in a controlled lab environment; real users have slower devices, spotty connections, and unpredictable interaction patterns. Both matter, but if you have to pick one to optimize for, optimize for field data — that's what Google Search actually uses.