Core Web Vitals: optimize for CrUX field data or the Lighthouse lab score?

Lab scores from PageSpeed Insights or Lighthouse are great for debugging, but they make a weak target. The lab test is one cold load on a simulated mid-range phone over a fixed connection, so you can hit a near-perfect score while real visitors on older Android devices wait four seconds for the hero image. The ranking signal comes from Chrome UX Report field data, a 28-day rolling average of actual users, so that's the number that counts.

The catch is that low-traffic pages often have no field data at all, which means you're guessing on exactly the pages that get the least attention. The approach I'd suggest is to use lab runs to find and fix the problem, then confirm the fix in field data before calling it done. How do you handle pages with no CrUX data: fall back to lab numbers, or use a template-level proxy?

On the fallback question, check origin-level CrUX before trusting lab numbers. When a URL doesn't have enough traffic, PageSpeed Insights shows site-wide field data, which reflects real devices and networks, so it's a better guess than a single lab run. The catch is that origin data is dominated by your busiest templates. A blog post template might look fine while a rarely visited filter page is slow. For those, group URLs by template, run lab tests on one representative page per template, and use that as the proxy.

Also, the Lighthouse score doesn't measure INP at all. The lab uses Total Blocking Time as a stand-in, so a page can score 95 and still fail INP in the field because of slow interactions after load. The lab score is good for finding problems, but it can't tell you whether you've passed.

Grouping by template is the right call on INP. One detail people miss is that CrUX only shows URL-level field data when enough Chrome users hit that page, so you often get the origin fallback instead. For INP that fallback can mislead, because interaction-heavy templates like filters and carts either drag the origin number up or get buried in it. So don't assume INP is clean until you've checked it at the template level in PageSpeed Insights.

Depends on how much people actually interact with the template. A blog post with no filters or forms gives INP very little to measure, so the origin number is a fair read there. A product listing with a size picker or add-to-cart is where the origin average can hide a real problem.