PageSpeed Insights finishes the Lighthouse half of the report and then leaves the “real users” block empty. The client Slack thread fills with “is CrUX broken?” and someone refreshes the same URL three times. Lab scores are there, but field percentiles are not. That pattern is usually eligibility, not a failed API call.
What follows is the engineer’s short path: which kind of “no data” you are looking at, whether the origin string matches the live host, how PageSpeed Insights falls back from URL to origin, and what still makes sense to monitor until Chrome UX Report rows exist. For the fuller eligibility walkthrough and client wording on our monitoring blog, see Why CrUX Has No Data for Your Site. When field data does exist but a fix still looks invisible, that is a different clock: Why Your Core Web Vitals Fix Is Not in CrUX Yet.
What “no data” means in PageSpeed Insights and the CrUX API
Chrome UX Report (CrUX) only publishes anonymised field distributions when enough eligible Chrome sessions clear privacy and quality rules for that origin or URL. PageSpeed Insights and Search Console inherit those gaps. A blank field section is not the same as an amber or red Core Web Vitals category. There is simply no percentile to colour yet.
In the UI you usually see one of three shapes. Origin absent: tools cannot show field data for the site at all. URL thin, origin present: PageSpeed Insights may disable “This URL” and fall back to origin-level field rows, or show origin while the URL field block stays empty. Metric missing: some field metrics appear and others do not. The third case is a sampling gap on a URL that already has other field rows, so it is a metric problem rather than “CrUX is offline.”
The CrUX API often answers the same situations with a not-found style response for the origin or URL you requested. That is still eligibility (or a wrong identifier), not proof that Lighthouse lied. Google’s CrUX methodology is clear that you cannot manually submit a site for inclusion; origins and pages appear and disappear as eligibility changes.
Debug the origin string before you blame traffic
Most “CrUX no data” conversations waste the first hour on the wrong host. http versus https, www versus apex, and every subdomain are different origins. https://shop.example.com does not inherit field rows from https://www.example.com. The reliable check is the final navigable URL after redirects, with the path stripped and scheme plus host kept in lowercase the way CrUX expects.
When the string is wrong, PageSpeed Insights and the CrUX API look empty even if the real public origin already has field data. Matching the published origin once is usually enough before anyone argues about sample size. Chrome’s own connector errors have long suggested trying www or the opposite scheme when an origin is missing from the large CrUX origin set; that advice is about matching the published origin, not about inventing traffic.
When the URL is empty but the origin still has field data
PageSpeed Insights tries URL-level CrUX first. If the URL is not popular enough, it falls back to origin-level data and explains that the URL button is unavailable. Official guidance is in How to view Chrome UX Report data on PageSpeed Insights. That fallback is useful for orientation, and risky in a client deck if origin percentiles are labelled as “this landing page.”
Reports stay honest when they say which level the numbers come from. Synthetic history on the thin URL still matters while URL-level samples catch up. An origin bar that looks fine is not the same as a Core Web Vitals pass for that URL. Homepage and high-traffic templates often qualify first; locale paths, checkout steps, and campaign URLs lag for a long time.
Eligibility gates engineers actually check
Once the origin string is correct, the gates Google documents are user, origin, and page. User eligibility means only opted-in Chrome sessions on supported platforms (Chrome on iOS does not contribute). Origin eligibility needs a publicly discoverable root and enough eligible experiences across the origin. Page eligibility adds enough samples for that specific URL.
Discoverability failures are easy to miss. A root that returns a non-200 after redirects, ships noindex, or redirects in a way indexing systems treat as undiscoverable can drop the whole origin even when inner URLs get visits. Chromium discussion threads have repeatedly pointed at locale redirects on / as a reason origin-level CrUX vanishes while a deeper URL still shows field data after PageSpeed Insights follows the redirect. A Lighthouse SEO pass on the root often surfaces those indexing or status problems before anyone promises that “more traffic next month” will create rows.
Popularity thresholds are not published. Small sites, brand-new launches, and niches with little opted-in Chrome traffic can stay empty indefinitely. Refreshing PageSpeed Insights does not create field eligibility. Growing real Chrome visits and keeping the root public does; there is no submit button.
What to monitor until field rows appear
A blank CrUX panel is not a reason to skip performance work. Scheduled lab tests on the homepage and the other URLs the retainer cares about, with budgets and a named owner when LCP, CLS, or related lab metrics move, give you dated history to show week to week while field percentiles are missing. When origin or URL field data appears, it sits beside that lab history rather than replacing it.
If the client already has field data and only the fix looks late, the useful link is the 28-day collection window article above. “No data” and “stale data” are different problems. Mixing them produces the wrong promise in Slack.
FAQ
Does CrUX “no data” mean the site is slow?
No. It means Google does not have enough eligible samples (or the origin fails discoverability) to publish field percentiles. Lab diagnostics can still guide template fixes while eligible Chrome traffic builds.
Can we force the client site into the Chrome UX Report?
No. Inclusion is automatic when eligibility is met. A public root plus real Chrome traffic, checked on a fixed schedule, is the path; refreshing PageSpeed Insights every hour is not.
Why do I still see Lighthouse scores?
Lighthouse runs on demand in the lab. CrUX needs eligible real-user samples. Both can sit on one PageSpeed Insights page, and either side can be empty on its own without proving the other is wrong.
Are subdomains covered by the apex origin?
No. Each scheme and host is its own origin. The useful query is the origin the product actually uses, including https and whether the live site sits on www or the apex.
CTA
When the field block is empty, the useful client note is eligibility rather than “CrUX is broken.” Naming the origin and confirming the root is public usually clears the first half of the conversation. Synthetic budgets on the priority URLs cover the weeks until field rows show up. The Watcher eligibility guide holds the longer agency script; the 28-day window guide fits lag after a fix, not an empty panel.
References
- CrUX methodology (Chrome for Developers)
- How to view Chrome UX Report data on PageSpeed Insights (Chrome for Developers)
- About PageSpeed Insights (Google for Developers)
- Overview of CrUX (Chrome for Developers)
- Why CrUX Has No Data for Your Site (Apogee Watcher)
- Why Your Core Web Vitals Fix Is Not in CrUX Yet (Apogee Watcher)
Top comments (0)