Debugging scenarioHard~12 min

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would treat the regression as a production signal with an owner, a baseline, and a rollback decision, not as an invitation for broad optimization. Real-user monitoring should record route, metric attribution, application version, device class, and coarse network context without collecting sensitive data. I would compare affected and unaffected cohorts, use browser traces to prove the mechanism, and ship the smallest corrective change behind a measurable rollout when risk is meaningful. After recovery, I would add a budget or representative regression check where it can catch this class of failure, while recognizing that lab gates cannot replace field monitoring for long-tail devices and real network conditions.

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.

Red flagsCandidateSigns the answer is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot distinguish LCP, INP, and CLS.
Starts changing code without identifying the affected route, cohort, or release.
Treats one local score as sufficient evidence.
Lists generic optimizations but cannot explain how to verify causality or recovery.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you distinguish a server-side LCP problem from a client-side one?
What evidence would justify rolling back the release?
Why can INP be healthy in the lab but poor in the field?
What performance data would you avoid collecting for privacy reasons?

Interviewer notesInterviewerWhat to listen forWhat the interviewer is listening for.Open details

Details

Look for a measurement-first investigation, correct distinctions among LCP, INP, and CLS, and explicit use of both field and lab data. Strong answers segment affected users, correlate releases, prove a mechanism before optimizing, and define how recovery will be verified.

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Prerequisite

Review this first if the current drill feels shaky.

Frontend PerformanceRendering and bundle performance are useful foundations before diagnosing a measured production regression.

Debugging scenarioHard~12 min

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would treat the regression as a production signal with an owner, a baseline, and a rollback decision, not as an invitation for broad optimization. Real-user monitoring should record route, metric attribution, application version, device class, and coarse network context without collecting sensitive data. I would compare affected and unaffected cohorts, use browser traces to prove the mechanism, and ship the smallest corrective change behind a measurable rollout when risk is meaningful. After recovery, I would add a budget or representative regression check where it can catch this class of failure, while recognizing that lab gates cannot replace field monitoring for long-tail devices and real network conditions.

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.

Red flagsCandidateSigns the answer is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot distinguish LCP, INP, and CLS.
Starts changing code without identifying the affected route, cohort, or release.
Treats one local score as sufficient evidence.
Lists generic optimizations but cannot explain how to verify causality or recovery.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you distinguish a server-side LCP problem from a client-side one?
What evidence would justify rolling back the release?
Why can INP be healthy in the lab but poor in the field?
What performance data would you avoid collecting for privacy reasons?

Interviewer notesInterviewerWhat to listen forWhat the interviewer is listening for.Open details

Details

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Prerequisite

Review this first if the current drill feels shaky.

Frontend PerformanceRendering and bundle performance are useful foundations before diagnosing a measured production regression.

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

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