Core Web Vitals Measurement: Lab vs Field Data

How to measure, interpret, and debug Core Web Vitals using lab tools, field data (Real User Monitoring), and the web-vitals library. Covers metric-specific diagnostics for LCP, INP, and CLS with implementation patterns for production RUM pipelines.

Abstract

Core Web Vitals measurement splits into two fundamentally different contexts: lab data (synthetic, controlled) and field data (real users, variable conditions). Lab tools like Lighthouse provide reproducible diagnostics but cannot predict real-world performance—cache state, device diversity, and actual interaction patterns create systematic gaps. Field data from Chrome User Experience Report (CrUX) or custom Real User Monitoring (RUM) captures the 75th percentile experience that determines Google’s ranking signals.

The mental model:

• Lab data answers “what’s the best this page can do?” and “what changed in this deploy?”
• Field data answers “what are real users experiencing?” and “are we meeting Core Web Vitals thresholds?”
• Attribution data answers “why is this metric slow?” with element-level and timing-breakdown diagnostics

Each metric has distinct measurement nuances:

• LCP (Largest Contentful Paint): Four quantifiable subparts (Time to First Byte (TTFB), resource load delay, resource load time, element render delay)—median poor-LCP sites spend >50% of the 2.5s budget before the LCP resource even starts downloading
• INP (Interaction to Next Paint): Three-phase breakdown (input delay + processing time + presentation delay) with outlier filtering (ignores 1 per 50 interactions)
• CLS (Cumulative Layout Shift): Session windows with hadRecentInput exclusion—shifts within 500ms of user action are marked expected

The web-vitals library (v5.x) is the canonical implementation for RUM collection. Its attribution build adds ~1.5KB but provides root-cause data essential for debugging. For field data at scale, CrUX provides origin-level aggregates via BigQuery (monthly) and page-level data via the CrUX API (daily updates).

Lab vs Field: Fundamental Differences

Lab and field data measure the same metrics but produce systematically different results. Understanding these differences is essential for interpreting measurements and prioritizing optimization work.

Lab Data Characteristics

Lab tools (Lighthouse, WebPageTest, Chrome DevTools) run in controlled environments with predefined conditions:

Lab data provides reproducible baselines and regression detection but cannot capture the diversity of real-world conditions. A Lighthouse score of 95 does not guarantee good field metrics.

Field Data Characteristics

Field data from CrUX or custom RUM aggregates real user experiences:

• 28-day rolling average: CrUX smooths daily variation but lags behind deploys
• 75th percentile: The reported value means 75% of experiences were better—this is the threshold for “passing” Core Web Vitals
• Traffic-weighted: High-traffic pages dominate origin-level metrics
• Cache-aware: Returning visitors often have cached resources, improving LCP

Design rationale for 75th percentile: Google chose p75 as a balance between capturing “most users” (median would miss the long tail) and being achievable (p95 would fail most sites on edge cases). The 75th percentile roughly corresponds to “the experience of users on slower connections or devices.”

When Lab and Field Diverge

Common scenarios where lab and field metrics differ significantly:

Practical guidance: If you have both lab and field data for a page, prioritize field data for understanding user experience. Use lab data for debugging specific issues and validating fixes before deploy.

Measurement APIs and the web-vitals Library

PerformanceObserver Entry Types

The browser exposes Core Web Vitals through PerformanceObserver with specific entry types:

Critical configuration details:

2 collapsed lines
1
// Basic LCP observation
2
const lcpObserver = new PerformanceObserver((list) => {
3
  const entries = list.getEntries()
4
  const lastEntry = entries[entries.length - 1]
5
  console.log("LCP candidate:", lastEntry.startTime, lastEntry.element)
6
})
7

8
// IMPORTANT: Use `type` not `entryTypes` when using buffered or durationThreshold
9
lcpObserver.observe({
10
  type: "largest-contentful-paint",
11
  buffered: true, // Retrieve entries from before observer was created
12
})
13

14
// For event timing (INP), lower threshold captures more interactions
15
const eventObserver = new PerformanceObserver((list) => {
16
  /* ... */
4 collapsed lines
17
})
18
eventObserver.observe({
19
  type: "event",
20
  durationThreshold: 16, // Default is 104ms; minimum is 16ms (one frame at 60fps)
21
  buffered: true,
22
})

Why type instead of entryTypes? The buffered and durationThreshold options only work with type (single entry type). Using entryTypes (array) silently ignores these options—a common source of bugs in RUM implementations.

durationThreshold design: The default 104ms threshold (first multiple of 8 above 100ms) filters out brief interactions that don’t indicate responsiveness problems. The 8ms granularity exists for security (mitigates timing attacks). For comprehensive measurement, set durationThreshold: 16 (minimum, one frame at 60fps).

The web-vitals Library

Google’s web-vitals library (v5.x, ~2KB brotli) provides the canonical implementation of metric collection:

2 collapsed lines
1
import { onLCP, onINP, onCLS, onTTFB, onFCP } from "web-vitals"
2

3
// Each callback receives a metric object with:
4
// - name: 'LCP' | 'INP' | 'CLS' | etc.
5
// - value: The metric value
6
// - delta: Change since last report (important for CLS)
7
// - id: Unique identifier for this page load
8
// - rating: 'good' | 'needs-improvement' | 'poor'
9
// - entries: Array of PerformanceEntry objects
10

11
onLCP((metric) => {
12
  sendToAnalytics({ name: metric.name, value: metric.value, rating: metric.rating })
13
})
14

6 collapsed lines
15
onINP((metric) => {
16
  /* ... */
17
})
18
onCLS((metric) => {
19
  /* ... */
20
})

The delta property is critical for analytics: CLS accumulates over the session. If you send metric.value on every callback, your aggregate CLS will be inflated. Always use metric.delta for analytics systems that sum values.

Attribution Build for Debugging

The attribution build (~3.5KB brotli) adds diagnostic data essential for root-cause analysis:

3 collapsed lines
1
import { onLCP, onINP, onCLS } from "web-vitals/attribution"
2

3
onLCP((metric) => {
4
  const { attribution } = metric
5
  console.log("LCP Element:", attribution.element)
6
  console.log("LCP URL:", attribution.url) // Image/video source if applicable
7

8
  // LCP subpart breakdown (see next section)
9
  console.log("TTFB:", attribution.timeToFirstByte)
10
  console.log("Resource Load Delay:", attribution.resourceLoadDelay)
11
  console.log("Resource Load Time:", attribution.resourceLoadTime)
12
  console.log("Element Render Delay:", attribution.elementRenderDelay)
13
})
14

15
onINP((metric) => {
16
  const { attribution } = metric
17
  console.log("Interaction target:", attribution.interactionTarget)
18
  console.log("Input delay:", attribution.inputDelay)
19
  console.log("Processing time:", attribution.processingDuration)
6 collapsed lines
20
  console.log("Presentation delay:", attribution.presentationDelay)
21
})
22

23
onCLS((metric) => {
24
  const { attribution } = metric
25
  console.log("Largest shift target:", attribution.largestShiftTarget)
26
  console.log("Largest shift value:", attribution.largestShiftValue)
27
  console.log("Largest shift time:", attribution.largestShiftTime)
28
})

LCP Measurement and Diagnostics

Qualifying Elements

The W3C Largest Contentful Paint specification defines which elements can be LCP candidates:

• <img> elements (including <img> inside <picture>)
• <image> elements inside SVG
• <video> elements (poster image)
• Elements with background-image via CSS
• Block-level elements containing text nodes

Exclusions (elements that cannot be LCP):

• Elements with opacity: 0
• Elements covering the full viewport (treated as background)
• Placeholder/low-quality images: images with file size < 0.004 bytes per pixel
• Elements that are scrolled out of the viewport before rendering completes

LCP Subparts Breakdown

LCP can be decomposed into four measurable subparts, each pointing to different optimization strategies:

1
|← TTFB →|← Resource Load Delay →|← Resource Load Time →|← Element Render Delay →|
2
0        Server responds         Browser starts         Resource fully           LCP element
3
         with first byte         fetching LCP           downloaded               rendered
4
                                 resource

Recommended distribution: 40% TTFB, 40% Resource Load Time, 20% combined delays.

Real-world finding: Median poor-LCP sites have 1.3 seconds of Resource Load Delay—consuming over 50% of the 2.5s “good” budget before the LCP resource even starts downloading. This happens when the browser discovers the LCP image late (e.g., via JavaScript, CSS background, or deep in the DOM).

LCP Measurement Code with Subparts

4 collapsed lines
1
import { onLCP } from "web-vitals/attribution"
2

3
interface LCPDiagnostics {
4
  totalLCP: number
5
  ttfb: number
6
  resourceLoadDelay: number
7
  resourceLoadTime: number
8
  elementRenderDelay: number
9
  element: string
10
  url: string | null
11
}
12

13
onLCP((metric) => {
14
  const { attribution } = metric
15

16
  const diagnostics: LCPDiagnostics = {
17
    totalLCP: metric.value,
18
    ttfb: attribution.timeToFirstByte,
19
    resourceLoadDelay: attribution.resourceLoadDelay,
20
    resourceLoadTime: attribution.resourceLoadTime,
21
    elementRenderDelay: attribution.elementRenderDelay,
22
    element: attribution.element || "unknown",
23
    url: attribution.url || null,
24
  }
6 collapsed lines
25

26
  // Identify which subpart is the bottleneck
27
  const subparts = [
28
    { name: "TTFB", value: diagnostics.ttfb },
29
    { name: "Resource Load Delay", value: diagnostics.resourceLoadDelay },
30
    { name: "Resource Load Time", value: diagnostics.resourceLoadTime },
31
    { name: "Element Render Delay", value: diagnostics.elementRenderDelay },
32
  ]
33

34
  const bottleneck = subparts.reduce((max, curr) => (curr.value > max.value ? curr : max))
35

36
  sendToAnalytics({
37
    ...diagnostics,
38
    bottleneck: bottleneck.name,
39
  })
40
})

INP Measurement and Diagnostics

The INP Processing Model

INP measures the latency of user interactions across the entire page session. Each interaction has three phases:

1
|← Input Delay →|← Processing Time →|← Presentation Delay →|
2
User action     Event handlers      Handlers complete,      Next frame
3
(click/key/     start running       browser computes        painted
4
 tap)                               layout/paint

Interaction Grouping

Multiple events from a single user action (e.g., keydown, keypress, keyup for a keystroke, or pointerdown, pointerup, click for a tap) are grouped into a single “interaction.” The interaction’s latency is the maximum duration among its events.

Measured event types: click, keydown, keyup, pointerdown, pointerup, mousedown, mouseup

Excluded (continuous events): mousemove, pointermove, touchmove, scroll, wheel

Worst Interaction Selection with Outlier Handling

INP doesn’t report the absolute worst interaction—it uses outlier filtering to prevent random hiccups from inflating the score:

• <50 interactions: INP = worst interaction latency
• ≥50 interactions: INP ≈ 98th percentile (one outlier ignored per 50 interactions)

Design rationale: A generally responsive page with one 2-second interaction caused by a network glitch shouldn’t fail INP. The outlier filtering approximates “typical worst-case” rather than “absolute worst-case.”

Implementation efficiency: Browsers don’t store all interactions. They maintain a small list (typically 10) of the worst-N interactions, sufficient for the p98 approximation without memory concerns on long sessions.

INP Diagnostics Code

4 collapsed lines
1
import { onINP } from "web-vitals/attribution"
2

3
interface INPDiagnostics {
4
  totalINP: number
5
  inputDelay: number
6
  processingTime: number
7
  presentationDelay: number
8
  interactionTarget: string
9
  interactionType: string
10
}
11

12
onINP((metric) => {
13
  const { attribution } = metric
14

15
  const diagnostics: INPDiagnostics = {
16
    totalINP: metric.value,
17
    inputDelay: attribution.inputDelay,
18
    processingTime: attribution.processingDuration,
19
    presentationDelay: attribution.presentationDelay,
20
    interactionTarget: attribution.interactionTarget || "unknown",
21
    interactionType: attribution.interactionType || "unknown",
22
  }
23

24
  // Identify the dominant phase
25
  const phases = [
26
    { name: "inputDelay", value: diagnostics.inputDelay },
27
    { name: "processingTime", value: diagnostics.processingTime },
28
    { name: "presentationDelay", value: diagnostics.presentationDelay },
29
  ]
6 collapsed lines
30

31
  const dominant = phases.reduce((max, curr) => (curr.value > max.value ? curr : max))
32

33
  // High input delay → main thread was blocked (long task)
34
  // High processing time → slow event handler
35
  // High presentation delay → expensive layout/paint after handler
36

37
  sendToAnalytics({
38
    ...diagnostics,
39
    dominantPhase: dominant.name,
40
    recommendation: getRecommendation(dominant.name),
41
  })
42
})
43

44
function getRecommendation(phase: string): string {
45
  switch (phase) {
46
    case "inputDelay":
47
      return "Break up long tasks with scheduler.yield()"
48
    case "processingTime":
49
      return "Optimize event handler or defer work"
50
    case "presentationDelay":
51
      return "Reduce DOM mutations, avoid forced reflows"
52
    default:
53
      return ""
54
  }
55
}

CLS Measurement and Diagnostics

Session Windows

CLS doesn’t sum all layout shifts—it uses session windows to group related shifts:

• A session window starts with a layout shift and includes all shifts within 1 second of the previous shift
• Each window has a maximum duration of 5 seconds
• CLS = maximum session window score (not the sum of all windows)

Design rationale: Long-lived single-page applications (SPAs) would accumulate infinite CLS if all shifts were summed. Session windows capture “bursts” of instability while ignoring isolated, minor shifts spread across a long session.

Expected vs Unexpected Shifts

The Layout Instability API marks shifts as “expected” (via hadRecentInput: true) when they occur within 500ms of discrete user input:

1
new PerformanceObserver((list) => {
2
  for (const entry of list.getEntries()) {
3
    // Skip shifts caused by user interaction
4
    if (entry.hadRecentInput) continue
5

6
    // Only count unexpected shifts
7
    reportCLSShift(entry.value, entry.sources)
8
  }
9
}).observe({ type: "layout-shift", buffered: true })

Qualifying inputs for hadRecentInput: mousedown, keydown, pointerdown (within 500ms before the shift)

Why 500ms? This window covers the typical delay between user action and resulting layout change (e.g., clicking an accordion). Shifts outside this window are considered “unexpected” and degrade user experience.

Layout Shift Sources

Each layout-shift entry includes sources[] identifying which elements moved:

2 collapsed lines
1
interface LayoutShiftSource {
2
  node: Node | null // The element that shifted (may be null if removed)
3
  previousRect: DOMRectReadOnly // Position before shift
4
  currentRect: DOMRectReadOnly // Position after shift
5
}
6

7
// The shift value is calculated from the impact region:
8
// (intersection of viewport with union of previous and current rects)
9
// divided by viewport area, weighted by distance fraction

CLS Diagnostics Code

4 collapsed lines
1
import { onCLS } from "web-vitals/attribution"
2

3
interface CLSDiagnostics {
4
  totalCLS: number
5
  largestShiftTarget: string
6
  largestShiftValue: number
7
  largestShiftTime: number
8
  shiftCount: number
9
}
10

11
onCLS((metric) => {
12
  const { attribution } = metric
13

14
  const diagnostics: CLSDiagnostics = {
15
    totalCLS: metric.value,
16
    largestShiftTarget: attribution.largestShiftTarget || "unknown",
17
    largestShiftValue: attribution.largestShiftValue,
18
    largestShiftTime: attribution.largestShiftTime,
19
    shiftCount: metric.entries.length,
20
  }
21

22
  // Common CLS culprits by element type
23
  const target = diagnostics.largestShiftTarget
24
  let cause = "unknown"
6 collapsed lines
25

26
  if (target.includes("img")) cause = "Image without dimensions"
27
  else if (target.includes("iframe")) cause = "Embedded content resize"
28
  else if (target.includes("ad") || target.includes("banner")) cause = "Ad injection"
29
  else if (target.includes("font") || /^(p|h[1-6]|span)$/i.test(target)) cause = "Font swap"
30

31
  sendToAnalytics({ ...diagnostics, likelyCause: cause })
32
})

Field Data: CrUX and RUM Pipelines

Chrome User Experience Report (CrUX)

CrUX aggregates real Chrome user data and is the source of field metrics for Google Search ranking:

CrUX API Usage

5 collapsed lines
1
interface CrUXResponse {
2
  record: {
3
    key: { url?: string; origin?: string }
4
    metrics: {
5
      largest_contentful_paint: MetricData
6
      interaction_to_next_paint: MetricData
7
      cumulative_layout_shift: MetricData
8
    }
9
  }
10
}
11

12
interface MetricData {
13
  histogram: Array<{ start: number; end?: number; density: number }>
14
  percentiles: { p75: number }
15
}
16

17
async function queryCrUX(urlOrOrigin: string): Promise<CrUXResponse> {
18
  const isOrigin = !urlOrOrigin.includes("/", urlOrOrigin.indexOf("//") + 2)
19

20
  const response = await fetch(`https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=${API_KEY}`, {
21
    method: "POST",
22
    headers: { "Content-Type": "application/json" },
23
    body: JSON.stringify({
24
      [isOrigin ? "origin" : "url"]: urlOrOrigin,
25
      formFactor: "PHONE", // Or 'DESKTOP', 'TABLET', or omit for all
26
    }),
27
  })
28

29
  return response.json()
4 collapsed lines
30
}
31

32
// Rate limit: 150 queries/minute per Google Cloud project
33
// Data coverage: Requires sufficient traffic (anonymity threshold)

Building a RUM Pipeline

Production RUM requires handling edge cases the web-vitals library doesn’t solve:

8 collapsed lines
1
import { onLCP, onINP, onCLS, onFCP, onTTFB } from "web-vitals/attribution"
2

3
interface RUMPayload {
4
  sessionId: string
5
  pageUrl: string
6
  timestamp: number
7
  metrics: Record<string, number>
8
  attribution: Record<string, unknown>
9
  metadata: {
10
    deviceType: string
11
    connectionType: string
12
    viewport: { width: number; height: number }
13
  }
14
}
15

16
// Generate stable session ID
17
const sessionId = crypto.randomUUID()
18

19
// Collect device/connection context
20
function getMetadata() {
21
  return {
22
    deviceType: /Mobi|Android/i.test(navigator.userAgent) ? "mobile" : "desktop",
23
    connectionType:
24
      (navigator as Navigator & { connection?: { effectiveType: string } }).connection?.effectiveType || "unknown",
25
    viewport: { width: window.innerWidth, height: window.innerHeight },
26
  }
27
}
28

29
// Batch and send metrics
30
const metricQueue: RUMPayload[] = []
31

32
function queueMetric(metric: { name: string; value: number; delta: number; attribution?: unknown }) {
33
  metricQueue.push({
34
    sessionId,
35
    pageUrl: window.location.href,
36
    timestamp: Date.now(),
37
    metrics: { [metric.name]: metric.delta }, // Use delta for CLS
38
    attribution: (metric.attribution as Record<string, unknown>) || {},
39
    metadata: getMetadata(),
40
  })
41
}
42

43
// Send on visibilitychange (page hide) for reliable delivery
44
document.addEventListener("visibilitychange", () => {
11 collapsed lines
45
  if (document.visibilityState === "hidden" && metricQueue.length > 0) {
46
    navigator.sendBeacon("/analytics/rum", JSON.stringify(metricQueue))
47
    metricQueue.length = 0
48
  }
49
})
50

51
// Register metric callbacks
52
onLCP(queueMetric)
53
onINP(queueMetric)
54
onCLS(queueMetric)
55
onFCP(queueMetric)
56
onTTFB(queueMetric)

Critical implementation details:

1. Use delta for CLS: The value accumulates; sending full value inflates aggregates
2. Send on visibilitychange: Metrics finalize when the page is hidden; beforeunload is unreliable on mobile
3. Use sendBeacon: Survives page navigation, unlike fetch
4. Include session/page context: Enables segmentation by device, connection, page
5. Batch requests: Reduces beacon overhead, especially on mobile

Aggregation and Alerting

For Core Web Vitals pass/fail determination, aggregate to the 75th percentile:

3 collapsed lines
1
interface MetricSample {
2
  value: number
3
  timestamp: number
4
}
5

6
function calculateP75(samples: MetricSample[]): number {
7
  if (samples.length === 0) return 0
8

9
  const sorted = [...samples].map((s) => s.value).sort((a, b) => a - b)
10
  const index = Math.ceil(sorted.length * 0.75) - 1
11
  return sorted[index]
12
}
13

14
// Thresholds for alerting
15
const CWV_THRESHOLDS = {
16
  LCP: { good: 2500, poor: 4000 },
17
  INP: { good: 200, poor: 500 },
18
  CLS: { good: 0.1, poor: 0.25 },
19
}
20

21
function getRating(metric: string, p75: number): "good" | "needs-improvement" | "poor" {
22
  const threshold = CWV_THRESHOLDS[metric as keyof typeof CWV_THRESHOLDS]
23
  if (p75 <= threshold.good) return "good"
24
  if (p75 <= threshold.poor) return "needs-improvement"
2 collapsed lines
25
  return "poor"
26
}

Debugging Workflow

Step 1: Identify the Failing Metric

Start with PageSpeed Insights or CrUX API to identify which metric fails at p75:

# Quick check via PSI API
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&category=performance&key=YOUR_KEY"

Step 2: Check Lab vs Field Gap

If lab passes but field fails, investigate:

Step 3: Use Attribution Data

For the failing metric, deploy the attribution build to RUM and identify:

• LCP: Which subpart dominates? (TTFB, load delay, load time, render delay)
• INP: Which phase dominates? (input delay, processing, presentation)
• CLS: Which element causes the largest shift? When in the page lifecycle?

Step 4: Target Optimizations

Conclusion

Core Web Vitals measurement requires understanding the fundamental difference between lab data (reproducible, diagnostic) and field data (real users, ranking signals). Lab tools cannot predict field performance due to cache state, device diversity, and actual user interaction patterns—but they’re essential for debugging and regression testing.

The web-vitals library with attribution build provides the diagnostic detail needed to identify root causes. LCP breaks down into four subparts (TTFB, resource load delay, resource load time, element render delay), INP into three phases (input delay, processing time, presentation delay), and CLS into individual shifts with source elements.

For production monitoring, combine CrUX data (authoritative 75th percentile) with custom RUM (granular attribution data). Use CrUX for pass/fail status and trend analysis; use RUM attribution for debugging specific bottlenecks. The workflow is: identify failing metric → check lab/field gap → analyze attribution data → apply targeted optimization.

Appendix

Prerequisites

• Understanding of browser rendering pipeline (critical rendering path, paint, composite)
• Familiarity with PerformanceObserver API
• Basic knowledge of analytics data pipelines

Terminology

• CrUX: Chrome User Experience Report—Google’s public dataset of real user metrics from Chrome
• RUM: Real User Monitoring—collecting performance data from actual users in production
• p75: 75th percentile—the value below which 75% of samples fall
• Attribution: Diagnostic data identifying the root cause of a metric value

Summary

• Lab vs field: Lab data answers “what’s possible?”; field data answers “what are users experiencing?”—prioritize field data for Core Web Vitals assessment
• web-vitals library v5.x: Canonical implementation; use attribution build for debugging (~3.5KB)
• LCP subparts: TTFB, resource load delay, resource load time, element render delay—median poor-LCP sites have >50% of budget consumed before resource fetch starts
• INP phases: Input delay (main thread blocked), processing time (handler execution), presentation delay (layout/paint)—uses outlier filtering (1 per 50 interactions ignored)
• CLS session windows: Maximum 5 seconds, groups shifts within 1 second—hadRecentInput excludes user-initiated shifts within 500ms
• CrUX data sources: API (daily, page-level), History API (weekly, 25+ weeks), BigQuery (monthly, origin-only)

References

Specifications

• W3C Largest Contentful Paint - LCP definition, qualifying elements, timing
• WICG Layout Instability - CLS calculation, session windows, hadRecentInput
• W3C Event Timing - Event duration measurement, INP basis
• W3C Performance Timeline - PerformanceObserver API

Official Documentation

• web.dev Core Web Vitals - Thresholds and measurement guidance
• web.dev INP - INP definition, interaction model, thresholds
• web.dev Lab vs Field Data - When and why measurements differ
• Chrome Developers CrUX API - API usage, rate limits, data structure
• Chrome Developers CrUX BigQuery - Dataset structure, query patterns
• Chrome Developers CrUX History API - Trend data access

Implementation References

• GoogleChrome/web-vitals - Official library, v5.x documentation
• DebugBear LCP Subparts - LCP timing breakdown methodology
• web.dev Optimize INP - Phase-specific optimization strategies