How to debug a Core Web Vitals regression in 30 minutes

You opened Search Console. CrUX p75 LCP went from 2.1s to 3.4s last week. PageSpeed Insights agrees. You have 30 minutes before standup.

Here’s the order I work through.

Step 1: confirm it’s a regression, not a sampling artifact (2 min)

Open PageSpeed Insights, run it on your top 3 pages. Compare to the dates listed. If only one page regressed, the cause is page-specific. If all three regressed, the cause is global: a layout component, a third-party script, a font, an analytics tag. This narrows the search by 80%.

Step 2: figure out what changed (10 min)

Pull git log for the dates that match the regression window. CrUX is on a 28-day rolling window, so look at deploys 28 to 35 days back, not yesterday. The fresh deploy isn’t the suspect.

Specifically scan for:

• New <script> tags
• New webfont declarations
• Changes to above-the-fold layout (header, hero, banners)
• A new image that isn’t loading="lazy" below the fold, or worse, one that is when it shouldn’t be
• New A/B test or analytics injection

If you don’t see any obvious change, run a git diff against a known-good tag for package.json. Major version bumps in framework packages can quietly change rendering behavior.

Step 3: profile the offender (10 min)

Open Chrome DevTools, Performance panel, hard reload with throttling set to “Slow 4G” and CPU at 4x slowdown. Record. Look at the Web Vitals lane near the top.

You’re looking for:

• Long tasks (yellow blocks longer than 50ms) before LCP fires
• Render-blocking resources in the Network panel, the ones with a red bar
• The actual LCP element. It’s labeled in the Timings track.

If LCP is your hero image and it’s loading from a CDN that wasn’t preconnected, add <link rel="preconnect">. If it’s a webfont swapping in late, add font-display: swap or self-host. If it’s a JS-rendered hero, the fix is either SSR/SSG or a placeholder.

Step 4: fix and verify (8 min)

Make the change. Run PageSpeed Insights once, keeping in mind it’s simulated. The real validation comes from CrUX, which won’t update for at least a week.

Don’t stop monitoring. The whole point of CrUX is that field data is the truth. Schedule a follow-up check 14 days out.

What I do differently now

I don’t try to fix CWV reactively anymore. I run a perf scan on every deploy and on every Friday afternoon. If the synthetic LCP jumps by more than 200ms, I dig in immediately, while the change is still fresh in someone’s git history. By the time CrUX confirms the regression, you’ve already pushed three more deploys on top of it.

Catch it before it ships. That’s what the testing layer is for.