Explain a speed report when lab and real-user numbers disagree

Write the labels before the numbers

For each value, record metric, device, tool, date, and whether it is a controlled test or real-user observation. Do not compare a desktop loading score with mobile interaction data as if they were the same measurement. Keep the page version and deployment time beside the report so timing differences are visible.

Source checks: web.dev: Lab and field data differences · Google Developers: PageSpeed Insights data

Check whether field data describes this URL

PageSpeed Insights can fall back to origin-level data when there is not enough eligible data for the exact page. Origin data combines experiences across the site rather than proving this one service page's performance. Look for the scope label. If neither page nor origin has sufficient data, say field data is unavailable rather than inventing a passing result.

Account for the reporting window

CrUX-based field data uses a rolling collection period and reported percentile rather than a single immediate visit. A repair published yesterday shares that window with earlier experiences. Lab tests can reflect the new page now under their particular conditions. The difference does not automatically mean the repair failed or the field report is wrong.

Use each evidence type for the right question

Create a small matched report.

• Use repeated comparable lab traces to locate and verify a specific bottleneck.
• Record field metric, device, scope, window, and availability.
• Compare the same metric rather than an overall score with a Core Web Vital.
• Keep pre-change experiences in mind while the window updates.
• Check the actual visitor task separately from performance metrics.
• Name unresolved differences instead of averaging unrelated numbers.

Avoid declaring conversion or ranking causation

A better lab result does not establish that inquiries increased, and stable field data does not explain every customer's experience. Changes in device mix, network conditions, geography, and page visits can contribute to differences. Use the result to choose a technical follow-up, not to attribute business outcomes without independent lead evidence.

Publish a report someone else can interpret

State the repair, release time, controlled test result, field scope, and next review date. A concise note explaining why the observations differ is more useful than a green badge without context. Revisit the field window after sufficient new experience accumulates, while confirming that the public task still works.

Keep a comparison page or unchanged template when practical. It can help show whether a wider device or traffic shift affects both pages, although it is not a randomized experiment. Preserve the original tool settings and raw observations so a later reviewer can repeat the lab test and understand what the field summary actually covered.

Illustrative repair inside a mixed field window

An illustrative service page is repaired on October 13. Its new controlled mobile trace improves, but PageSpeed Insights still shows origin-level field data covering the previous 28 days. The owner reports those scope and timing differences and schedules a later review. The example does not claim that the origin summary measures only the repaired page.

The report labels the controlled run as the repaired URL and the field summary as the origin. This prevents a later reader from copying the origin's value into a page-specific success claim while the mixed collection window still includes older visits.

Questions about this task