Core Web Vitals: what actually moves the needle.

Core Web Vitals are real. They affect ranking, they affect conversion, and they catch teams off guard because the lab scores look fine and the field scores are catastrophic. The lab is on a beefy laptop on a fast connection. The field is on a mid-range Android on a flaky train. Treat the field data as the truth and the lab data as the hypothesis.

The thresholds Google uses

LCP — Largest Contentful Paint

The time from navigation start until the largest above-the-fold element appears. Almost always a hero image, a font-driven headline, or a video poster. This is the metric that correlates most strongly with the 'does this site feel fast?' perception users have.

• 01Find the LCP element with PageSpeed Insights — it tells you exactly which element it is.
• 02Preload it with <link rel="preload" as="image" href="...">.
• 03Compress it — WebP or AVIF over JPEG, with sizes hints for responsive variants.
• 04Serve it from a CDN that is actually fast in your market — Cloudflare, Fastly, or a regional equivalent.
• 05Stop blocking it behind a 200KB hydration bundle — defer your JS, render the LCP element in SSR.
• 06Use fetchpriority="high" on the LCP image to hint the browser.

CLS — Cumulative Layout Shift

The total of all unexpected layout shifts during page life. Caused by content jumping around as images load, fonts swap, ads inject. The single most-overlooked metric — easy to fix once you know what to look for.

• 01Set explicit width and height on every image. The aspect-ratio CSS property is a clean alternative when dimensions are dynamic.
• 02Reserve space for ads, embeds, and third-party widgets before they render — use min-height or aspect-ratio.
• 03Never inject content above the fold after first paint — banners that drop down 200ms after load are the worst offenders.
• 04Use font-display: swap or font-display: optional with a metric-compatible fallback to minimise font-swap shift.
• 05Be careful with skeleton loaders — they should match the dimensions of what they replace.

INP — Interaction to Next Paint

The time from a user interaction (click, tap, key press) to the next visual update. Replaced FID in March 2024 as the official responsiveness metric — and it's much more sensitive. INP failures are common on JS-heavy sites that felt fine in lab tests.

• 01Break up long tasks. If a handler blocks the main thread for 200ms, that's your problem.
• 02Move heavy work into web workers when you can.
• 03Throttle / debounce inputs — typeaheads are the worst offenders.
• 04Use requestIdleCallback for non-critical work.
• 05Audit third-party scripts. The chat widget you added in 2020 is probably your worst INP offender.
• 06Inspect long tasks in DevTools Performance panel — find the 200ms+ blocks and refactor them.

Measuring INP locally

import { onINP, onLCP, onCLS } from 'web-vitals'

// Report each metric to your analytics endpoint
onLCP(({ value }) => analytics.track('lcp', { value }))
onINP(({ value }) => analytics.track('inp', { value }))
onCLS(({ value }) => analytics.track('cls', { value }))

"

If the field data in Search Console disagrees with the lab data in Lighthouse, trust the field data. The lab is a hypothesis. The field is the truth.

The audit we run quarterly

• 01Pull 28-day field data from Search Console for every active client property.
• 02Triage URLs by impact — 'poor' on a high-traffic page is the priority.
• 03Run PageSpeed Insights on the worst offenders to surface specific fixes.
• 04Identify regressions vs the previous quarter. CWV scores drift over time as third-party scripts accumulate.
• 05Ship fixes in batches. Each major intervention earns a single before/after CrUX comparison.

Core Web Vitals are not optional. They affect ranking, they predict conversion, and the audit is cheap. Every production project we ship has a quarterly review where we look at the field data and pick the next intervention. Sites that don't do this drift downwards every quarter; sites that do, stay green.