A production release worsened Core Web Vitals for part of your audience. How would you investigate and improve the page?

Diagnose a Core Web Vitals regression

Uses field data, lab evidence, and release correlation to diagnose LCP, INP, and CLS regressions without guessing.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first identify which metric regressed, when it changed, and which routes, devices, browsers, or regions are affected. LCP reflects how quickly the main visible content appears, INP reflects interaction responsiveness, and CLS reflects unexpected layout movement. I would compare real-user field data with a reproducible lab trace, then inspect the relevant network waterfall, main-thread work, and layout shifts. I would fix the measured bottleneck and verify the result in both controlled tests and production field data.

Full answer below

Practice focus

LCP, INP, CLS, field versus lab data, segmentation, browser tooling, causal diagnosis, and safe performance verification.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Frontend performance is experienced by real users on different devices and networks, so a single local score is not enough. This scenario checks whether the candidate can turn a broad complaint into a measured diagnosis and verify that a fix improves user experience rather than only a benchmark.
I would first identify which metric regressed, when it changed, and which routes, devices, browsers, or regions are affected. LCP reflects how quickly the main visible content appears, INP reflects interaction responsiveness, and CLS reflects unexpected layout movement. I would compare real-user field data with a reproducible lab trace, then inspect the relevant network waterfall, main-thread work, and layout shifts. I would fix the measured bottleneck and verify the result in both controlled tests and production field data.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would correlate the regression with releases and segment the data before changing code. For poor LCP, I would check server response time, the discovery and priority of the LCP resource, image sizing and compression, font loading, and render-blocking work. For poor INP, I would record a slow interaction and break down long JavaScript tasks, excessive rerenders, and synchronous work in the handler. For CLS, I would inspect shift sources such as media without dimensions, injected banners, and late font changes. I would validate at the field-data percentile we care about because an improvement on a fast developer machine may not help the users who are actually failing.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Optimizing before identifying which metric and cohort regressed.
Treating one Lighthouse run as production truth.
Applying memoization or code splitting broadly without tracing the bottleneck.
Reporting only averages and hiding the slow user tail.
Declaring success from a lab score without checking field data after release.

A production release worsened Core Web Vitals for part of your audience. How would you investigate and improve the page?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Prerequisite

Tech stacks

Skill areas

Suggest an improvement