Core Web Vitals deep dive

Core Web Vitals are Google's three user-experience metrics that became ranking signals in 2021. The intro page covered what they are. This is the deep dive: exactly what each metric measures under the hood, what affects each one, and precisely how to fix them. By the end of this page, you should be able to look at a Core Web Vitals report and translate any failing metric into a specific fix.

The three thresholds

LCP: Largest Contentful Paint

What it measures

Time from navigation start until the largest visible element in the viewport finishes rendering. The largest element is usually a hero image, a large heading block, or a video poster frame. LCP is Google's proxy for "how long until the page looks done to the user."

What affects LCP

• Server response time (TTFB)
• Render-blocking CSS/JS
• Hero image size, format, and loading priority
• Web font blocking
• Client-side rendering delays

How to fix

• Reduce server response time via caching, CDN, and a faster backend
• Preload the hero image: <link rel="preload" as="image" href="hero.webp">
• Don't lazy-load the hero (counterintuitively, lazy-loading the LCP element hurts LCP)
• Inline critical CSS, defer the rest
• Use font-display: swap to avoid font-render blocking
• For dynamic sites, use SSR or SSG instead of pure CSR

INP: Interaction to Next Paint

What it measures

INP replaced FID in March 2024. It measures responsiveness across the entire user session, reporting the 75th percentile (or worst) interaction delay, the time from user input (click, tap, keypress) until the browser paints a visual response.

INP is harsher than FID because it looks at every interaction, not just the first.

What affects INP

• Heavy JavaScript execution on the main thread
• Long tasks (any JS task over 50ms)
• Third-party scripts that block interactions
• Large DOM updates
• Unoptimized React or Vue renders

How to fix

• Break long JS tasks into chunks (use scheduler.yield() or setTimeout)
• Move heavy work to Web Workers
• Lazy-load non-critical JS
• Debounce or throttle expensive event handlers (scroll, resize, input)
• Audit third-party scripts and remove the worst offenders
• Use content-visibility: auto to skip off-screen rendering
• Profile with Chrome DevTools, Performance tab, Interactions section

CLS: Cumulative Layout Shift

What it measures

The sum of all unexpected layout shifts during a page's lifetime. Penalizes pages where content jumps around while loading, causing misclicks and frustration. Each shift contributes to the score; good pages stay under 0.1.

What affects CLS

• Images without explicit dimensions
• Ads and embeds with no reserved space
• Web fonts causing late-swap shifts
• Content injected above existing content (late-loading banners)
• Dynamically resized elements after render

How to fix

• Set explicit width and height on every image, video, and iframe
• Reserve space for ads with fixed-size containers
• Use font-display: optional or preload fonts to avoid late-swap shifts
• Never inject content above the fold after initial render
• Use CSS aspect-ratio for responsive images that must scale
• Avoid transforms that change layout; prefer ones that use GPU (transform: translate)

Field vs lab data

Google uses field data for ranking. Optimize for what Chrome users actually experience, not for what your local Lighthouse reports.

Measurement tools

• PageSpeed Insights. Field + lab data combined.
• Search Console Core Web Vitals report. Field data on your site, bucketed Good/Needs Improvement/Poor.
• CrUX Dashboard. Historical field data.
• Web Vitals Chrome extension. Real-time CWV while browsing.
• RUM services. SpeedCurve, Datadog, New Relic for detailed field data at scale.

What to do with this

Open Search Console. Find your worst-performing Core Web Vital. Pick the highest-traffic page in that bucket. Apply the specific fix for that metric from this page. Wait 28 days for field data to update. Repeat.

Next: structured data (JSON-LD), the machine-readable layer that unlocks rich SERP results.