Core Web Vitals Reference

Complete technical reference for Core Web Vitals (LCP, INP, CLS): thresholds, common causes, fixes, measurement tools, CrUX BigQuery queries, web-vitals library setup, and SEO ranking impact.

Full docs: https://cogny.com/docs/core-web-vitals

Usage

/cwv-audit                       # Full CWV overview and audit guidance
/cwv-audit LCP                   # Deep-dive into LCP causes and fixes
/cwv-audit INP                   # Deep-dive into INP causes and fixes
/cwv-audit CLS                   # Deep-dive into CLS causes and fixes
/cwv-audit CrUX competitor       # CrUX competitor comparison queries
/cwv-audit monitoring            # GA4 + BigQuery monitoring setup
/cwv-audit web-vitals            # web-vitals library integration guide

Instructions

You are a Core Web Vitals performance expert. Use this reference to help users understand CWV metrics, diagnose performance issues, write CrUX BigQuery queries, set up monitoring, and optimize their sites for better user experience and SEO rankings.

When the user asks a question, find the relevant section below and provide precise, actionable answers. If Search Console or GA4 MCP tools are available, use them to pull real data for the user's site.

If the user provides a specific metric or topic as an argument, focus on that area. Otherwise, provide an overview of all three vitals and their current thresholds.

Overview

Core Web Vitals (CWV) are three user-centric performance metrics that Google uses as ranking signals in Search. They measure loading performance, interactivity, and visual stability. Every page is assessed at the 75th percentile of real-user field data.

A page "passes" Core Web Vitals when all three metrics meet the "Good" threshold at the 75th percentile.

LCP — Largest Contentful Paint

What It Measures

LCP reports the render time of the largest image, video, or text block visible within the viewport, relative to when the page first started loading.

Thresholds

• Good: ≤ 2.5 seconds
• Needs Improvement: > 2.5 s and ≤ 4.0 s
• Poor: > 4.0 seconds

LCP Candidate Elements

• <img> elements (including inside <picture>)
• <image> elements inside <svg>
• <video> elements (poster image or first displayed frame)
• Elements with background-image loaded via url() (not CSS gradients)
• Block-level elements containing text nodes or inline-level text children

The largest element may change as the page loads. The final entry before user interaction is the LCP value.

Common Causes and Fixes

1. Slow server response time (TTFB)

• Use a CDN to serve content from edge locations
• Cache HTML at the edge (stale-while-revalidate)
• Pre-connect to required origins: <link rel="preconnect" href="https://cdn.example.com">
• Use 103 Early Hints

2. Render-blocking resources

• Inline critical CSS, defer non-critical stylesheets
• Defer or async non-critical JavaScript: <script defer src="app.js">
• Minimize CSS size, avoid @import in CSS

3. Slow resource load times

• Preload the LCP image: <link rel="preload" as="image" href="hero.webp">
• Use modern formats (WebP, AVIF) with <picture> fallbacks
• Set fetchpriority="high" on the LCP <img>
• Use responsive images with srcset and sizes

4. Client-side rendering delay

• SSR or SSG the LCP content
• Pre-render critical routes
• Reduce JavaScript bundle size

5. Web font blocking LCP text

• Use font-display: swap or font-display: optional
• Preload the primary font file
• Subset fonts to required characters

INP — Interaction to Next Paint

What It Measures

INP measures the latency of all click, tap, and keyboard interactions throughout the page lifecycle, and reports a single value representing the worst-case interaction. It replaced FID as a Core Web Vital in March 2024.

Thresholds

• Good: ≤ 200 milliseconds
• Needs Improvement: > 200 ms and ≤ 500 ms
• Poor: > 500 milliseconds

How It Differs from FID

Three Phases of Interaction Latency

1. Input delay — time from user action to event handler start
2. Processing time — time spent running event handlers
3. Presentation delay — time from handler completion to next paint

Common Causes and Fixes

1. Long tasks blocking the main thread

• Break up long tasks using scheduler.yield() or setTimeout(0)
• Use requestIdleCallback for non-urgent work
• Move heavy computation to Web Workers

2. Heavy JavaScript execution

• Code-split with dynamic import()
• Tree-shake unused exports at build time
• Defer non-critical scripts and third-party tags

3. Expensive event handlers

• Debounce or throttle rapid-fire handlers
• Avoid forced synchronous layouts in handlers
• Use content-visibility: auto for off-screen content

4. Large DOM and expensive rendering

• Virtualize long lists (react-window, @tanstack/virtual)
• Use CSS contain: layout style paint
• Reduce DOM depth and element count

5. Excessive re-renders in SPA frameworks

• Memoize components (React.memo, useMemo)
• Use startTransition for non-urgent state updates

CLS — Cumulative Layout Shift

What It Measures

CLS measures the sum of unexpected layout shift scores during the page lifespan. A layout shift occurs when a visible element changes position without being triggered by user interaction.

Thresholds

• Good: ≤ 0.1
• Needs Improvement: > 0.1 and ≤ 0.25
• Poor: > 0.25

Session Window Calculation

1. Shifts are grouped into session windows (max 5 seconds, 1-second gap ends a window)
2. CLS = the maximum session window score
3. Each shift score = impact fraction x distance fraction

What Counts as a Layout Shift

• Position changes NOT triggered by user input
• CSS transform animations do NOT count
• Shifts within 500ms of user interaction are excluded

Common Causes and Fixes

1. Images/videos without dimensions

<!-- GOOD -->
<img src="hero.jpg" alt="Hero" width="800" height="400">
<!-- Or use CSS aspect-ratio -->
<style>.hero-img { aspect-ratio: 16 / 9; width: 100%; }</style>

2. Dynamically injected content

.ad-slot { min-height: 250px; min-width: 300px; contain: layout style paint; }

3. Web fonts causing FOIT/FOUT

@font-face {
  font-family: 'Custom Font';
  src: url('custom.woff2') format('woff2');
  font-display: optional; /* eliminates layout shift entirely */
}

4. Ads/embeds without reserved space

.embed-container {
  position: relative;
  padding-bottom: 56.25%; /* 16:9 */
  height: 0; overflow: hidden;
}
.embed-container iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

5. Late-loading banners/cookie bars

• Use position: fixed or sticky so they overlay without shifting content

Measurement Tools

Field Data (Real Users)

Lab Data (Synthetic)

|