Why are there two kinds of result?

The diagnostic section runs Lighthouse on the address you submit. It simulates loading the page and gives you findings to investigate. The real-user section, when available, summarizes eligible Chrome visits from the previous 28 days.

Use the mobile or desktop result that fits the problem and check the test conditions in the report. A slow simulated run can suggest what to inspect. The visitor measurements reflect a mix of real devices, connections and visits over time, so the two results can differ.

Open the public report site and enter a public address you are allowed to test. The web check runs on Google's side and needs no code installed in your app. Use a local Lighthouse audit or a Chrome DevTools recording for a page that requires your sign-in or stays on your computer.

Does the real-user result describe this page?

Check whether the real-user section describes This URL or the Origin. The URL result is for the specific page. The origin result pools eligible visits across that site address, such as https://example.com, which can include other pages.

If a page has too few eligible visits, PageSpeed Insights can show the origin instead. If the origin lacks enough data too, you may still get a diagnostic report without a visitor summary. That absence leaves the question of visitor performance open.

The Chrome UX Report requires eligible visits and publicly discoverable pages or origins. Google does not publish the exact visitor threshold. Treat an origin result as context when the individual page has too little data.

What should you check on a newly published sample page?

Use a public test page you control and are allowed to submit to Google. Confirm before opening or submitting it that it contains only sample content and has no live customer data, accounts or connected services. If you cannot confirm that, keep the exercise local with Lighthouse.

Run a mobile check
Run Analyze on the new sample page and choose Mobile. Note the test conditions and one finding you can investigate, such as a file the report says is holding up the page.
Check what the visitor data covers
If the report offers both This URL and Origin, compare the labels and record their measurements separately. If it only shows the origin or has no data, note that there is no visitor summary for the individual page.
Choose a follow-up
Use the mobile diagnostic to pick the first issue to investigate on this page. Record when the page went live beside the visitor data window so a later comparison can account for when people actually saw the change.

What should you keep for the next check?

For a before-and-after check, record the date and the change you made. Repeat the test on the same address and device setting. Compare the finding you tried to fix, and repeat the test if the result varies.

The public web report gives you a point-in-time check. If you later need your own alerts or measurements inside a signed-in flow, define that job separately before choosing what to monitor.