Q022: Core Web Vitals Collection and Field Debugging

What Interviewers Want To Evaluate

This question tests whether you can move beyond naming LCP, INP, and CLS. Interviewers want to know how these metrics are collected, how field data differs from lab data, how to debug regressions, and how to connect metrics to concrete browser behavior.

For senior roles, the strongest answer explains attribution: what element caused LCP, what interaction caused INP, and what shifted for CLS.

Short Interview Answer

Core Web Vitals are user-centric performance metrics. LCP measures loading speed for the largest visible content, INP measures interaction responsiveness across the page lifecycle, and CLS measures unexpected layout shift. Field debugging means collecting these metrics from real users with route, device, connection, release, and attribution context, then using traces and browser APIs to find the actual cause.

Detailed Interview Answer

Core Web Vitals matter because they are closer to user experience than raw technical timings. A page can have a fast server response but poor LCP because the hero image is late, CSS blocks rendering, or JavaScript delays hydration.

Field data is collected from real users. It includes their actual devices, networks, caches, browser state, extensions, and data sizes. Lab data is controlled and repeatable. Senior engineers use both: field data to find real impact, lab data to reproduce and inspect.

Deep Technical Explanation

The three current core metrics are:

LCP -> loading experience
INP -> interaction responsiveness
CLS -> visual stability

Debugging starts by segmenting. A global average is often too blurry.

LCP Debugging

LCP is often affected by slow server response, render-blocking CSS, late image discovery, unoptimized image delivery, client-only rendering, or long JavaScript tasks before rendering.

Useful attribution includes the LCP element, URL, load delay, resource load time, render delay, and route. If the LCP element is an image, look at priority, dimensions, format, CDN behavior, and cache headers.

INP Debugging

INP looks at interaction latency. Bad INP often comes from long tasks, expensive event handlers, heavy React renders, synchronous layout, large data processing, or third-party scripts.

Useful attribution includes interaction type, target element, route, event delay, processing time, and presentation delay. A senior answer should connect INP to main-thread work.

CLS Debugging

CLS comes from unexpected layout shifts. Common causes include images without dimensions, ads or embeds that reserve no space, late fonts, injected banners, and skeletons that do not match final layout.

Useful attribution includes shifted elements and the source that caused movement.

Code Example

import { onCLS, onINP, onLCP } from "web-vitals";

onLCP((metric) => {
  console.log("LCP", metric.value, metric.attribution);
});

onINP((metric) => {
  console.log("INP", metric.value, metric.attribution);
});

onCLS((metric) => {
  console.log("CLS", metric.value, metric.attribution);
});

Production telemetry should add route, release, device, connection, and sampling rules.

Architecture Discussion

The collection layer should be small and stable. It should report metrics once per page lifecycle, attach app context, avoid sensitive data, and work across route transitions.

Dashboards should be organized around percentiles, not only averages. P75 by route and device class is usually more useful than one global mean.

Common Mistakes

A common mistake is treating Lighthouse scores as the whole performance story. Lighthouse is useful, but field data shows what real users experience.

Another mistake is optimizing the wrong route because the global metric hides the affected segment.

Real Production Story

A homepage LCP regression may affect only mobile users after a hero image change. The fix could be image sizing, priority, format, preload, or reducing render delay from JavaScript.

Enterprise Example

In a SaaS app, the dashboard route may have acceptable LCP but poor INP because large chart interactions block the main thread. The right fix might be virtualization, worker offloading, memoization, or reducing synchronous layout.

Performance Discussion

Core Web Vitals are outcome metrics. They tell you the user-facing symptom. DevTools traces, resource waterfalls, source maps, and custom app spans help find the cause.

Security and Privacy Considerations

Do not send element text, full private URLs, user-entered content, tokens, or payloads. Use route templates and safe element descriptors.

Senior Engineer Perspective

A senior engineer should answer with a debugging workflow: collect field data, segment, inspect attribution, reproduce, fix, ship, and verify.

Lead Engineer Perspective

A lead should set budgets, release checks, dashboards, ownership, and escalation rules for performance regressions.

Revision Notes

LCP is loading, INP is responsiveness, and CLS is visual stability. Field data plus attribution turns metrics into debugging work.

Key Takeaways

Do not stop at the metric name. Explain what caused it, who is affected, and how you would prove the fix.

Follow-Up Questions

1. What does LCP measure?
2. What replaced FID as a core responsiveness metric?
3. How do you debug poor INP?
4. What causes CLS?
5. Why is field data different from lab data?
6. Why use percentiles?
7. What context should be sent with Web Vitals?
8. What should be redacted?
9. How do long tasks affect INP?
10. How would you verify a performance fix?

How I Would Answer This In A Real Interview

I would define LCP, INP, and CLS, then immediately move into attribution and field debugging. I would say I collect metrics by route, device, connection, and release, then use attribution to find the LCP element, slow interaction, or shifted element.

Then I would explain that field data finds real impact, while lab traces help reproduce and fix the issue.