Core Web Vitals: judge a page on PageSpeed lab scores or on CrUX field data?

When someone asks if a site "passes Core Web Vitals," the first thing to pin down is which number they mean. Lab scores from PageSpeed Insights come from a synthetic test with one device profile and one network throttle, so they swing a lot when you change a script or an image, and they say little about real visitors. Field data from CrUX is what Google uses for the page experience signal, but it only exists for URLs with enough Chrome traffic. On a small site a lot of pages have no field data at all, so a page can look green in the lab and still have no usable LCP for real users, or the reverse. I'd use lab scores as a build gate while you work, then judge the result on field data over the 28-day window. How do you handle low-traffic pages where CrUX returns nothing?

Agreed on the split. For pages with no CrUX data, I'd stop asking whether the page passes and ask whether its template does. Most small sites build dozens of URLs from one or two templates, so the busiest sibling page (a product or blog post with real traffic) tells you more about hero image and font loading than the empty URL does. PageSpeed Insights also shows origin-level field data when a URL has none. That's a handy fallback, but it averages across the whole domain, so one heavy checkout or landing page can skew the number.

For the thin pages, lab scores are the only signal you have. Keep the test setup fixed (same device profile, same throttle, same test location) and compare before and after a change, rather than treating any single score as a verdict.

I'm not sure the sibling-page logic holds. The busiest product page can have a completely different LCP element than a thin blog post. One has a hero banner, the other a text block waiting on a web font, so its field numbers won't transfer as neatly as the template argument suggests. For the thin URL, the lab trace tells you more, since the LCP element highlight and filmstrip show what actually loads first on that page. I'd only use the sibling's CrUX data to confirm a shared problem, like a slow font or a render-blocking script, and not to predict the thin page's score.

I'd push back on the last part. You're right that the LCP element can differ, but the sibling's field data is still useful for more than confirming problems. Server response time, third-party tags and the CSS and JS bundle load on every page of the template, so the sibling's field TTFB and INP tell you something real about the thin URL even when its hero element is different. A lab trace is also just one synthetic visit with one element highlighted, so I'd treat the filmstrip as a hypothesis about what loads first and run the test a few times to see whether that element holds.

It depends on where the LCP element sits. If the thin page's largest element comes from the template, like a logo, a header image, or the same web font, the sibling's LCP is a fair guess. If it's the page's own body text or its own image, the sibling's number tells you very little. So I'd split the sibling's field data by metric: TTFB and INP carry over to the thin URL, but LCP only does when the element is shared. Comparing the lab filmstrip against the sibling's LCP element settles that quickly.

INP is the one I'd be careful with. It only measures interactions visitors actually make on that page, so a thin blog post with a table of contents and a comment form behaves nothing like a product page with a filter panel. TTFB is the safest to carry over. For LCP, check the form factor too. CrUX splits mobile and desktop, and the largest element above the fold often differs between them, so compare the lab filmstrip against the mobile field numbers, not the blended figure, or you'll match the wrong element.

I'm not convinced TTFB is the safest metric to carry over. It only transfers when both URLs are served the same way. A product page with live stock levels or a logged-in cart often hits the origin on every request, while a blog post may sit on the CDN and come back from cache. Say the product page's field TTFB is 900 ms and the blog post is 150 ms. Using the sibling's number would badly misstate the thin page's server time. Check the cache headers on the thin URL with curl or the network tab first. If it's cached, treat the sibling's TTFB as a poor guess.

Depends on whether the thin URL gets the same cache treatment as its sibling. Even when both sit behind the same CDN rules, the sibling's field TTFB is a blend of hits and misses, so the p75 can look like origin time while most visitors are actually getting a cached response. I'd only carry the number over when the two URLs share caching behavior. Curl the thin page twice and look at the cache-status and age headers. If the second request is a hit, the sibling's TTFB doesn't tell you much about how the thin page really responds.

Traffic volume matters here too, and it's something the sibling comparison misses. A busy product page gets requested often enough that its edge copy rarely expires, so its field TTFB is mostly cache hits. A thin blog post might get a visit every hour or two. If the CDN TTL is short, or the object gets evicted at a quiet edge location, most of its visitors land on a cold cache and wait on the origin. So the thin URL can end up slower than its sibling even when the headers match on paper.

It also means back-to-back curl requests make a weak test. The second one will almost always be a hit, which says nothing about the visitor who arrives after the cache has expired. Read the max-age or s-maxage value and compare it with the typical gap between visits to that URL. If the TTL is shorter than the gap, treat the thin page as mostly cold, and don't borrow the sibling's TTFB as its number.