Two kinds of evidence
A controlled test helps reproduce a page load under recorded conditions. Field data describes actual visits over a collection period. PageSpeed Insights distinguishes these sources and may lack enough CrUX data for a particular URL; origin-level data is not the same as page-specific data. [E02] Do not fill the gap with a made-up “real-user” number.
Record the environment before comparing results
A busy worker, a different viewport or changed network settings can affect a repeat test. Store the browser version, device profile and test location alongside the result. Use repeated runs when the decision justifies the cost, and compare a stable aggregation rather than selecting the best run. A score should help diagnose a problem, not reward choosing favorable test conditions.
Follow the slow user journey
The homepage may load acceptably while a product search or account page is slow. Choose a small representative public sample and explain what it covers. Private workflows need authorized testing. Investigate the page’s critical resources, render delay and layout shifts in context. Optimizing an unrelated asset to move a score may do little for the task customers are trying to complete.
Recheck after a focused change
Change one meaningful cause, preserve the test setup and record the new release. Confirm that the improvement did not break navigation or content. Keep field-data periods distinct from the time of a new lab run; they do not update as a single instant snapshot. Atlas can present the observations and a Forge proposal, while actual acceptance remains tied to the specific engineering change.
Compare like with like
A controlled test is useful for reproducing a problem under known conditions. Real-user data describes a population of visits over time. The two sources answer different questions, so one fast local run should not overwrite a slower field observation, and missing field data should not be represented as a perfect result.
Record device conditions, tested URL, cache state and observation time. After an improvement, rerun a comparable test and examine the underlying change: a smaller image, less blocking script or a more stable layout. Treat an unexplained score jump as a reason to inspect the setup, not automatically as success.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Lab test | Known conditions and repeatability. | Device, network and test configuration. |
| Field observation | Actual visitor distribution when available. | Source, period and sample limitations. |
| Improvement | A reproducible change in the relevant surface. | Comparable before/after evidence. |
Where this goes wrong
Do not promise a conversion increase from a technical performance score alone. A business effect requires its own measurement. Also keep one page’s result distinct from a claim about every route in a large application.
Different measurements can both be valid when their scope is clearly stated.
Turn it into a working checklist
- Label lab and field sources.
- Record device and test conditions.
- Avoid best-run cherry-picking.
- Recheck useful journeys after changes.
A concrete next step
Choose a representative public page, document the conditions, implement one focused change and repeat the observation. Use the result to prioritize the next improvement rather than chasing a number without understanding its cause.
Watch a related case
The video could not be loaded. Try again later.