Core Web Vitals: lab score or field data, which one do you fix first?

PageSpeed Insights lab scores come from a single synthetic test on a fixed device profile, so they're easy to chase and not always meaningful. The field data (CrUX, the last 28 days of real Chrome users) is what Google uses for the page experience signal. If a page scores 45 in the lab but its field LCP already passes, I'd leave the lab number alone and focus on the URLs where field data fails. That's usually a few templates with heavy hero images or a slow third-party script.

The counterargument is fair, though. Lab tests catch regressions before real users feel them, and low-traffic pages often have no field data at all, so CrUX can't help you there. It depends a lot on volume. What do you prioritize when a page has no field data?

I'd still keep the lab number in the picture. The score itself isn't the goal, you're right about that, but the lab waterfall is the only place you can see why LCP is slow. A page can pass at the 75th percentile today while the slowest quarter of users, often mobile on older phones, is already failing. So open the lab report, find the LCP element and the render-blocking requests, and fix what it shows. And on pages with no field data, that lab run is your whole signal, so treat it that way.

Agreed that the lab waterfall is where you find the cause, and field data mostly just tells you something is slow. Low-traffic pages are the catch, though. When a URL doesn't get enough Chrome users for its own CrUX record, Google falls back to origin-level data, which averages every page on the domain. A fast homepage and a fast checkout can make a slow product template look fine in the summary.

Search Console groups similar URLs, which helps a little, but a template with a few visits a day can still disappear into the average. For that template, the lab run is the only per-page view you have. And if the lab and field LCP elements don't match, look for a lazy-loaded image or a banner injected late by a script, since that's the usual reason they disagree.

Yeah, the origin fallback is the bit people miss. Also, in Search Console's Core Web Vitals report, a URL group only shows up when Google has enough field data for it. So a low-traffic template can be missing from the report entirely instead of showing as failing. Run a lab test on those pages before you assume they're fine.

For local businesses, I'd sort URLs by whether they produce calls or form fills and run the mobile lab test on those first, even when there's no field data. Take a plumber's service page: it might get a few dozen visits a week, mostly on phones, and the people landing there often need someone today. Each visit is worth a lot, but the traffic is too thin for CrUX to show a problem. If lab LCP on that page is over 2.5 seconds, fix it before the blog posts, which can wait.

Agreed on the order. With only a few dozen mobile visits a week on a service page, the lab run is the only signal you can really use, and 2.5 seconds is a sensible cutoff.

On those pages, look hard at call tracking. A lot of local sites use a dynamic number swap script that replaces the phone number in the header after the page has painted. That can slow LCP if the swapped number turns out to be the largest element, and it can cause layout shift when the new number is a different length. In the lab waterfall, check whether the tracking script blocks rendering or changes content after first paint. If it does, defer it and put the default number in the static HTML, so the first paint shows it without waiting on the script.