Why Does PageSpeed Insights Say There Is Not Enough Real-User Data?
Learn what missing real-user data in PageSpeed Insights means and how to assess a small website without mistaking laboratory tests for visitor evidence.
Part of our guide: What Are Core Web Vitals? A Simple Guide for Business Owners
“Not enough real-user data” means PageSpeed Insights cannot show the relevant field measurement from its available dataset. It does not by itself mean your website is broken, slow or receiving no visitors.
Small and recently launched websites may have limited reporting data. The useful response is to check the scope and eligibility, then use proportionate testing while keeping the evidence gap explicit.
Why data may be unavailable
The Chrome User Experience Report, or CrUX, uses eligible visitor experiences and requires sufficient samples. Google’s CrUX methodology says its exact popularity threshold is not disclosed and that inclusion is automatic, not something you manually submit for.
This dataset is not a count of every person who visits your site. Your analytics can therefore show visits while a public performance tool still lacks a reportable sample.
Do not buy traffic or repeatedly reload your own page to try to manufacture a passing dataset.
Check page versus origin information
Sometimes a specific page has insufficient data while its wider origin has enough. PageSpeed Insights may show that broader scope instead.
Read the label above the results. Google’s PageSpeed Insights guide explains the fallback from URL to origin and the possibility that neither has enough data.
Record the scope in your notes. A healthy origin-wide result does not establish that every rarely visited service page is healthy.
A no-field-data decision checklist
Use the following sequence before approving a larger technical project.
| Question | Practical next step |
|---|---|
| Is this the intended public URL? | Check the final address after redirects |
| Is the page meant to be indexable? | Review access and indexing settings with the developer |
| Is origin data available instead? | Record it as broader evidence, not a page result |
| Can the customer journey be reproduced? | Test real tasks on representative devices |
| Do repeated lab tests reveal a problem? | Investigate the specific bottleneck |
| Would private monitoring be proportionate? | Assess effort, sample size and privacy implications |
Do not remove appropriate access protection from a private page merely to make a performance report appear.
Use laboratory testing honestly
Run a controlled test of the homepage, an important service page and the enquiry route. Keep device and network settings consistent, and record several runs.
Our free speed-testing guide explains a practical starting point. Label these results as laboratory measurements, not statements about the percentage of customers receiving a particular experience.
A score can still identify useful work. It cannot prove that an unavailable real-user metric has passed. See what a PageSpeed score means for the distinction.
Include interaction and accessibility checks
A page-load test does not replace using the website. Open the menu, follow a service link, complete a test form and check the confirmation.
Test with a keyboard and a modest phone where possible. Record unexplained pauses or moving controls in a way another person can reproduce.
The INP guide helps investigate slow interactions. Your observations remain useful even when the public field dataset cannot report that page.
Choose monitoring in proportion to the business
A small brochure website may need a simple review after meaningful changes and periodic checks of critical tasks. A busy booking platform may justify more detailed monitoring and alerting.
If adding real-user monitoring, agree what is collected, how it is protected and who reviews it. Avoid capturing form contents or other unnecessary personal information. More instrumentation is not automatically more useful evidence.
Use the website performance measurement guide to connect the checks with enquiries and task completion.
Keep uncertainty visible in reports
Write “field data unavailable for this URL” rather than “all users pass”. Record what was tested, when it was tested and what remains unknown.
The guide to differing speed reports explains other common mismatches. The wider Core Web Vitals guide gives the metric context.
A small site can still be carefully tested and maintained while there is too little data for a public field report. Keep using the available tests to check that customers can use it reliably.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
