A speed report is useful when I can tell what was measured. A big number without a source is much less helpful.
In June 2026 I changed my WordPress performance reporting to display field and lab measurements separately. I also removed simulated fallback results. When a real test could not be completed, the screen needed to say that clearly.
Two useful views of the same problem
A lab test loads a page under a defined set of conditions. It is good for investigating a problem and comparing a change under similar conditions. Field data reflects eligible real visits collected over time. Devices, connections and the pages people actually use all affect that picture.
Neither should quietly pretend to be the other. Google’s PageSpeed Insights explanation describes the distinction. When I share a result, I label its source, the tested URL and whether I was looking at mobile or desktop.
Check the scope as well as the colour
In my reporting code I made the source explicit when field data was available for an individual URL, for the wider origin, or not at all. A site-level measurement is useful context, but it is not evidence that this particular page behaves exactly the same way.
The fix also kept the lab result visible as its own result. That avoids a common conversation where a fresh lab test improves but the longer-running visitor measurement has not yet moved, and someone assumes one of them must be broken.
How I use this in a review
- Choose representative pages: a landing page, a content page and an important task or transaction.
- Record the source, date, device mode and scope beside each measurement.
- Use the lab report to investigate specific problems.
- Check the visitor data to understand whether the problem is showing up in ordinary use.
- Repeat a comparable test after the change, then allow time for the field picture to develop.
I also separate a server response measurement from a full browser load. A quicker response is worthwhile, but it does not tell me whether the page shifts around, blocks interaction or downloads an oversized image afterwards.
Missing data should stay missing
A failed request, an unconnected account and a URL without enough field data need different explanations. None should become a reassuring invented score. I use the same principle in hosting dashboards: monitoring needs to say when it does not know.
The aim is a report that helps me choose the next piece of work. A perfect-looking dashboard that hides uncertainty does the opposite.