PageSpeed Insights shows no field data when Google does not have enough real Chrome visits to your page to report on. It is a traffic threshold, not a speed fault. A brand new site and a genuinely fast site can both sit there with an empty box for months.
What an empty field data box actually means
PageSpeed Insights runs two separate reports on one screen, and only one of them can come up empty.
Google’s documentation, “About PageSpeed Insights” on developers.google.com, last updated 2024-10-21 UTC, says the tool “provides both lab and field data about a page.” That page says the real user data comes from the Chrome User Experience Report, and covers “the previous 28-day collection period.”
The same page is direct about the gap: “A page might not have sufficient data if it has been recently published or has too few samples from real users.” When that happens, the tool falls back to the whole domain. If the domain falls short too, you get nothing.
The Chrome for Developers guide “How to view Chrome UX Report data on PageSpeed Insights,” last updated 2024-04-09 UTC, spells out the end of that chain: “If the origin-level data is also not available in CrUX, then PSI is not able to display this section and you will see No Data. Lab data from Lighthouse is still available to give you an approximation of the page’s performance.”
When the data is there, the number on screen is the 75th percentile. That guide says a percentile is “a measure that indicates the value below which a given percentage of samples fall.” At the 75th, three quarters of visits were faster than the number you are looking at. The About PageSpeed Insights page sets the good bands: Largest Contentful Paint at 2500ms or under, Interaction to Next Paint at 200ms or under, Cumulative Layout Shift at 0.1 or under.
The two tests a page has to pass
The Chrome for Developers page “CrUX methodology,” last updated 2024-06-20 UTC, lists two things a page needs before Google will report on it.
- It has to be publicly discoverable. That page says this uses “the same indexability criteria as search engines.” It then names what fails: a page served with a status code other than 200 after redirects, which is common after a site move, a page served with a noindex header, or a page carrying a noindex robots tag.
- It has to be sufficiently popular, which the page defines as having “a minimum number of visitors.”
Here is the honest part. On that visitor minimum, the same page says: “An exact number is not disclosed”. Nobody outside Google can tell you how many visits a month your water heater page needs. Anyone who hands you a figure invented it. The page does say the minimum is the same for pages and for whole origins, so a busy home page can put the domain in the dataset while a quiet service page stays blank.
There is a third gate the same page describes on its own, further down, and it catches more contractors than either of the two above. It is about who is doing the visiting.
Who counts as a real user, and who does not
This is the part that gets missed.
The methodology page lists four things a visitor has to satisfy before their visit counts. Usage statistic reporting turned on. Browser history synced. No sync passphrase set. A supported platform.
Supported means desktop Chrome on Windows, macOS, ChromeOS or Linux, or Chrome on Android, including Custom Tabs and WebAPKs. Then the page names the exceptions flatly: “Chrome on iOS”, “Android apps using WebView”, and “Other Chromium browsers (for example Microsoft Edge)”.
Read that with your customer list in mind. A homeowner on an iPhone contributes nothing to this report, in Safari or in Chrome. Someone on Edge at a desk contributes nothing. On Android it depends on how the link opens: if the app hands off to a Chrome tab it counts, and if the app draws the page inside its own built in viewer it does not.
The same page adds: “Chrome does not publish data about the proportions of users that meet these criteria.” So even Google will not tell you what share of your traffic was ever eligible. If most of your work starts with a phone in a driveway, a large part of your real audience is invisible to this report by design.
Why a 100 in the lab and an empty field box can both be true
The other half of the screen still works. That is Lighthouse, and it is a lab test.
The web.dev article “Why lab and field data can be different (and what to do about it),” by Philip Walton, last updated 2022-07-18 UTC, gives the two definitions. Lab data “is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” Field data “is determined by monitoring all users who visit a page”.
The About PageSpeed Insights page describes that controlled environment. Lighthouse “simulates the page load conditions of a mid-tier device (Moto G4) device on a mobile network for mobile, and an emulated-desktop with a wired connection for desktop.” The test itself runs in a Google datacenter, reported as North America, Europe, or Asia.
One phone model. One network. One datacenter. That is a repeatable check, and it is not your customers.
Galloping’s own site scored 100 on Google’s PageSpeed test, desktop and mobile, when it launched in August 2026. That is a lab score, with the same limit as anyone else’s lab score. It is worth having. It is not proof of what a homeowner sees on a weak signal. If two tools hand you two different numbers for the same page, that is normal, and it has its own page here: why three speed tests give three different scores.
What you should not buy to fix this
No amount of speed work turns the field data on. Not a rebuild, not a faster host, not a plugin. The gate is a visitor count nobody publishes, and browser settings your customers control.
If someone tells you your missing field data is a problem they can fix for a monthly fee, that is the moment to stop. It is not a fault. Improving your site is worth doing on its own merits, and it will not switch this box on.
Two limits on everything above, said plainly:
- Those Chrome for Developers pages carry last updated dates in 2024. Google changes these tools. Open the pages and check the detail before you act on it.
- Search Console will not rescue you. Google’s Search Console Help page for the Core Web Vitals report names the CrUX report as its source, so it goes quiet the same way. That page carries no update date.
What to do next
- Run your page at pagespeed.web.dev and look at which half is blank. If the URL box is empty and the origin summary has numbers, your domain is in the dataset and this one page is not visited enough yet.
- Confirm Google can see the site at all. The methodology page says to run a Lighthouse audit and read the SEO results: your site is not discoverable if your root page, the one at the bare domain, fails the “Page is blocked from indexing” or “Page has unsuccessful HTTP status code” audits.
- Read the lab report anyway. It lists real problems, whether or not anyone has visited.
- Fix the things that move load time, in order, and skip the rest: what actually makes a website faster.
- Come back in a month. That same CrUX guide says PSI “aggregates new data every day encompassing the previous 28 days”, so a change today takes weeks to show in full once your page qualifies.
- If the same problems keep returning and patching costs more than replacing, that is a build question, not a measuring one: how the build works.
The empty box is not the thing to chase, and whether the phone rings is the count that pays. What fills it is more visitors, and those come from being found in the first place, which is separate work from speed.