Guides · 2026-10-02 · By VSNARY | Emmanuel Orta · 0 views
Core Web Vitals field data for sites CrUX does not cover
PageSpeed Insights says "no data" for most small sites because the Chrome UX Report needs more real users than they have. Lab scores are not a substitute. How to collect your own field data, the thresholds to judge it against, and the sample size below which a percentile means nothing.
Core Web Vitals field data comes from the Chrome UX Report, which only includes origins and pages with enough real Chrome traffic, so most local and small-business sites show no field data in PageSpeed Insights. A Lighthouse run is lab data from one synthetic load and is not a substitute. The alternative is first-party real-user monitoring: load the web-vitals library, send LCP, INP and CLS from each page view to your own endpoint, and compute the 75th percentile over 28 days, judged against good thresholds of 2.5 seconds, 200 milliseconds and 0.1. Below about 100 samples, report the count, not a percentile.
Run a small business site through PageSpeed Insights and the top half of the report, the part labelled with what real users experience, usually says there is not enough data. That section comes from the Chrome UX Report, and the report only includes sites with enough real Chrome visitors. Most local sites never get there. What remains is the Lighthouse lab run underneath, which measures one simulated page load and is routinely mistaken for the real thing. This guide explains why field data is missing, why lab data cannot fill the gap, and how to collect field data of your own that is honest about its sample size.
Why CrUX has no data for your site #
The Chrome UX Report aggregates measurements from Chrome users who have opted into usage statistics, over a rolling 28-day window. Google includes an origin or a page only when it is publicly discoverable and has a sufficient number of samples; the threshold is not published. A site with a few hundred visitors a month falls below it, and the PageSpeed Insights fallback queries the same dataset, so it returns nothing too. This is not a defect of the site. It is the dataset's eligibility rule, and it excludes most of the businesses that would benefit from field data.
Why a lab score is not a substitute #
Lighthouse loads the page once, on a simulated mid-range phone over a throttled connection, from one location. That is a controlled experiment, useful for finding what to fix, but it is not what visitors experience. It cannot measure Interaction to Next Paint at all, because no one interacts with a lab load; it reports Total Blocking Time as a proxy. And repeated runs vary widely. We measured the spread of a single page's lab score across runs in one Lighthouse run cannot support a finding; the variance was large enough that one run should never be reported as a site's performance.
The thresholds #
| Metric | Good | Needs improvement | Poor | Measured at |
|---|---|---|---|---|
| Largest Contentful Paint | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s | 75th percentile of page loads |
| Interaction to Next Paint | ≤ 200 ms | 200–500 ms | > 500 ms | 75th percentile of page loads |
| Cumulative Layout Shift | ≤ 0.1 | 0.1–0.25 | > 0.25 | 75th percentile of page loads |
A page passes when all three are good at the 75th percentile. The percentile matters: it means three in four visits were at least that fast, which is a statement about the population, not about one load.
Collecting your own field data #
Google's open-source web-vitals library reports LCP, INP and CLS, plus TTFB and First Contentful Paint, from real page views in any modern browser. The minimal setup loads the library and sends each page view's values to an endpoint you control when the page is hidden, which is when CLS and INP are final. Send one beacon per page view rather than one per metric, strip the query string and fragment from the URL before sending, and set no cookies or identifiers. The attribution build also reports which element was the LCP and which sub-phase was slow, which tells you what to fix rather than only how slow it was.
We run this on crawlcheck.io and on every site we operate, self-hosted rather than loaded from a third-party CDN, and disclose it on our policy page: path only, timings and a coarse element name, nothing that identifies a visitor.
The sample-size floor #
A 75th percentile computed over twelve visits is noise. One slow load on a bad connection moves it by seconds. We report no percentile until a page or origin has 100 samples in the 28-day window, and show the sample count instead. Below the floor the honest statement is "not enough visits yet", the same thing CrUX says, but with a number attached and a floor you can see. When samples are stored in histogram buckets, interpolate within the bucket rather than reporting the bucket edge: in our tests the edge overstated the true p75 by up to 5.8 percent, always high, and interpolation brought the error within 1.8 percent.
Storing and reading the samples #
Each beacon is small, a few hundred bytes, but the storage design decides whether the numbers are trustworthy. Writing every sample to a log or an analytics table and computing percentiles at read time is the most accurate approach. Keeping a running histogram per page and day is cheaper but can lose samples when two writes collide on one record. Losing samples at random does not bias a percentile, it only slows the approach to the sample floor, so the error is in the safe direction, but it is worth knowing it exists before trusting a sample count.
Weight sampled data correctly. If the collector records only one page view in ten to save cost, each recorded sample stands for ten, and the sample count shown against the floor should reflect recorded samples, not the estimate. Separate mobile and desktop, because they are different populations and a site can pass on one and fail on the other. And keep the attribution: the LCP element and its slowest sub-phase, and the INP target and whether its delay was input delay, processing or presentation. The percentile tells you whether there is a problem; the attribution tells you where.
Reading the result #
Keep the three sources separate and label every number with where it came from. CrUX field, first-party field and lab are three different measurements; averaging them produces a number that describes nothing. Use first-party field data to decide whether there is a problem, and the lab run to diagnose it. If LCP is the problem on a page that is mostly code, the payload is usually where to start. Our analytics script once added 650 milliseconds to every request on our own site, written up in our analytics was adding 650 ms; a measurement tool can be the slowest thing on the page.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
The main product
Found this on your own site? We fix it for $749.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
Questions this post answers
Why does PageSpeed Insights show no field data for my site?
Field data comes from the Chrome UX Report, which only includes sites with enough real Chrome visitors over 28 days. Most small sites fall below the unpublished threshold.
Is a Lighthouse score the same as Core Web Vitals?
No. Lighthouse is lab data from one simulated load. Core Web Vitals assessments use field data at the 75th percentile of real page loads.
What are the Core Web Vitals thresholds?
Good is LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, each at the 75th percentile.
How can I measure Core Web Vitals without CrUX?
Load the open-source web-vitals library on your pages and send each page view's LCP, INP and CLS to your own endpoint, then compute the 75th percentile over 28 days.
How many samples do I need before trusting a p75?
We use a floor of 100 samples in the 28-day window. Below that, a single slow visit moves the percentile too much to mean anything.
Can Lighthouse measure INP?
No. INP needs real user interactions. Lighthouse reports Total Blocking Time as a lab proxy.
Related findings
Comments
Comments are read before they appear. Nothing is published automatically, and no account is needed.
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.