loke.dev
Header image for Fixing Core Web Vitals Regressions After Production Deploys
web-performance frontend-engineering debugging core-web-vitals

Fixing Core Web Vitals Regressions After Production Deploys

Stop guessing during post-deploy performance panics. Learn to isolate LCP, CLS, and INP regressions using field data versus synthetic Lighthouse metrics.

Published 5 min read

Our dashboard turned yellow three days after we shipped a new hero component. Synthetic tests in Lighthouse gave us a clean 98. Then the Chrome User Experience Report showed a Core Web Vitals regression that cratered our LCP. We went from a 1.8s LCP to 3.2s for mobile users on 4G networks. It’s the classic trap. Synthetic tools run on high-end hardware with perfect network conditions. Real users are fighting latency, CPU throttling, and cache misses.

We fixed it by moving the hero image out of a dynamic component wrapper and hardcoding the preload. The regression was simple. The diagnosis cost us two days of wasted effort.

Why Lighthouse stays green while field data reports a regression

Synthetic tools simulate a pristine environment. They run on a machine with a powerful CPU and zero competing tasks. When you see a green Lighthouse score alongside failing field data, it usually means your LCP optimization is brittle. It chokes on network congestion or main thread contention that never triggers in an idle, simulated window.

Lighthouse captures what happens in a vacuum. It ignores the noisy neighbor effect. Third-party scripts, analytics trackers, or chat widgets fire concurrently and starve your browser of the cycles needed to decode an image or execute a stylesheet. If your Lighthouse score is perfect but your users are reporting sluggishness, you aren't measuring performance. You’re measuring potential.

Diagnosing an INP javascript bottleneck in third-party scripts

Interaction to Next Paint is the primary victim of third-party bloat. We had a persistent INP spike above 350ms that only appeared on mid-range Android devices. Our local tests were useless because we were developing on M3 MacBook Pros.

The culprit was a third-party script meant to handle notifications. It was running long tasks on the main thread every time a user clicked a button. Stop looking at your own source code. Look at the Long Tasks in the Chrome DevTools Performance tab.

1. Open DevTools.
2. Navigate to the Performance tab.
3. Hit Record and perform the slow interaction.
4. Scan for red triangles in the main thread track.

Those triangles mark tasks longer than 50ms. If you see them, that is your INP bottleneck. We found our script was running a JSON.parse on a massive payload during the click event. We offloaded it to a Web Worker. Our INP dropped from 380ms to 110ms.

// Before: Blocking the main thread
button.addEventListener('click', () => {
  const data = JSON.parse(heavyPayload); 
  processData(data);
});

// After: Offloading to a worker
const worker = new Worker('processor.js');
button.addEventListener('click', () => {
  worker.postMessage(heavyPayload);
});

Eliminating layout flicker via font and image loading strategies

Cumulative Layout Shift is rarely a mystery. It is a math error. We had a recurring issue where a font swap caused a 0.15 shift. We were using font-display: swap. It is the standard recommendation, but it only solves visibility, not the shift.

The fix is matching. You must use a CSS fallback that mimics the dimensions of your primary font.

@font-face {
  font-family: 'PrimaryFont';
  src: url('/fonts/primary.woff2') format('woff2');
  font-display: swap;
}

body {
  /* Match the dimensions of the external font */
  font-family: 'PrimaryFont', Arial, sans-serif;
  font-size: 16px;
  line-height: 1.5;
}

If your fallback has a different x-height or character width, the browser shifts the text once the primary font loads. Use the Font Style Matcher to fine-tune your fallback dimensions so the browser does not need to reflow the paragraph.

How to distinguish between transient anomalies and real regressions

There is a gap between a bad deployment and a bad day for the internet. If you see a sudden dip in Core Web Vitals, check the global distribution. If every page on your site has a similar percentage drop, look for external factors. Maybe it is a CDN outage or a slow third-party vendor.

If only your product pages spiked in LCP but your landing pages stayed steady, you have a code-level regression. Don't revert everything immediately. Use User-Agent filtering in your RUM tool. If the spike is on Chrome 128 but not Safari, you found a browser-specific rendering bug.

Overcoming the 28-day lag in Search Console reporting

The biggest headache with Core Web Vitals is the 28-day aggregation window. You fix an LCP issue today, but you have to wait nearly a month to see that bar move in the Google Search Console report. This creates a phantom state where you think your fix didn't work.

Stop relying on Search Console for real-time feedback. You need your own field data collection. Use the Google Web Vitals library to send metrics to your own analytics provider.

import {onLCP, onINP} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  navigator.sendBeacon('/analytics', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);

By collecting this data yourself, you see the impact of a deploy in 24 hours. If your logs show a drop from 3s to 1.5s, the Search Console dashboard will eventually catch up.

The hero image request discovery trap

Over half of LCP issues stem from the browser not knowing it needs the hero image until it finishes parsing the CSS. If your hero image is defined in a CSS background-image property, it is a late-discovered resource. The browser finds the HTML, then the CSS, and only then triggers the image download.

We cut 600ms off our LCP by moving the hero image to an img tag and adding a priority hint.

<!-- Before: Late-discovered background image -->
<div class="hero" style="background-image: url('hero.jpg')"></div>

<!-- After: Early-discovered and prioritized -->
<img src="hero.jpg" fetchpriority="high" alt="Hero banner">

Never lazy-load your LCP element. It sounds like an optimization, but lazy-loading the primary hero image is a recipe for a massive LCP penalty. The browser should fetch that image at the exact same time it fetches critical CSS. If you lazy-load the hero image, you are fighting the browser's preload scanner.

Resources