Core Web Vitals: chase the PageSpeed lab score or fix the field failures first?

Most people screenshot the PageSpeed Insights lab score and argue about it, but what Google assesses for Core Web Vitals is field data: a rolling 28-day CrUX average of real Chrome users. So a page can score 95 in the lab and still fail LCP in the field, because your actual visitors are on mid-range Android phones over patchy 4G. I'd fix the field failures first and treat the lab score as a debugging tool.

The usual counterargument is that lab tests are reproducible while field data is too slow to confirm a change worked. Fair, but on a low-traffic site a lot of URLs have no CrUX data at all, so you end up looking at origin-level numbers. What do you do when a page has no field data?

Depends on whether paid or organic visitors actually land on the page. If it's a service page your ads send people to, I'd fix it even with no CrUX data. Those are the visitors you're paying for, and a slow page hurts conversions whether Google has numbers for it or not. For a local business with a dozen pages, that's usually three or four URLs. Test those in the lab with mobile throttling, fix the obvious problem (often an oversized hero image), then watch whether form fills or calls move. Origin-level field data is a reasonable fallback for the rest.

Agreed on the triage. I'd start with how the hero image loads, because shrinking the file is only half the job. If the hero is marked loading="lazy" while it sits above the fold, the browser deprioritises the very element LCP is measuring. Take lazy loading off that image and add fetchpriority="high". If the hero is a CSS background image, switch it to a real img tag so the browser finds it in the HTML instead of waiting on the stylesheet. In the lab waterfall, the telltale sign is the image request starting late.

Before changing anything, check which element the lab report actually names as LCP. On service pages it's often not the hero at all. It can be the H1 stuck behind a web font that blocks rendering, and in that case no amount of image compression will move the number.

The H1 case is usually about font-display, not file size. Chrome can hide text for up to three seconds while a webfont loads, so font-display: swap, or preloading the font file, lets the heading paint right away.