Why Do PageSpeed Insights and Search Console Show Different Results?
Understand why PageSpeed Insights and Search Console disagree by comparing field and lab data, URL groups, devices and measurement periods.
Part of our guide: What Are Core Web Vitals? A Simple Guide for Business Owners
PageSpeed Insights and Search Console can show different performance results without either report being broken. They may describe different visitors, different collections of pages or different periods.
Before choosing which result to trust, identify what each number represents. A recent laboratory test and a historical real-user assessment answer different questions.
Separate the two parts of PageSpeed Insights
PageSpeed Insights can show real-user information and a Lighthouse laboratory test. The lab test examines the page under simulated conditions; the real-user section summarises eligible Chrome visitor experiences.
Google’s PageSpeed Insights documentation explains that field results cover a trailing 28-day period and may use origin-level data when the individual URL lacks enough samples.
An origin is the combination of protocol, hostname and port, such as an HTTPS website on one hostname. Do not mistake an origin-wide result for a measurement of only the page you entered.
Search Console groups related pages
Search Console’s Core Web Vitals report organises results by device and groups of pages with similar experiences. An example URL represents a group; it is not necessarily the sole source of the result.
Google’s Core Web Vitals report documentation explains this grouping and the use of real-world data. A page that performs differently from its group can therefore produce a different impression when tested alone.
This is why copying the first example URL into another tool is the start of an investigation, not a complete like-for-like comparison.
An illustrative report comparison
Imagine a business has just reduced the size of its service-page hero images. The following is a fictional interpretation exercise, not a client result.
| Report | What it shows | Sensible interpretation |
|---|---|---|
| New laboratory test | Improved loading on the tested page | The change may have helped under those conditions |
| Historical field section | Earlier slower experiences still included | The reporting window has not instantly reset |
| Search Console group | Several service pages remain affected | Other pages or shared behaviour need checking |
| Desktop result | Better than mobile | Device conditions differ; compare like with like |
The correct response is not to repeat tests until every badge turns green. Keep the evidence and investigate the remaining mismatch.
Compare scope before comparing colours
For each result, record the exact URL, device category, metric, collection period and whether the scope is a page, group or origin.
Then ask whether you are comparing the same metric. A Lighthouse performance score is not the same thing as an LCP value or a Core Web Vitals pass. Our PageSpeed score guide explains the role of the score.
Check redirects too. The address typed into a tool may lead to another URL, especially after a redesign.
Use laboratory data for diagnosis
A controlled test is useful for seeing whether a targeted change affects loading. Repeat representative pages and retain the settings so the comparison can be reproduced.
For slow main content, follow the LCP diagnosis guide. For the broader workflow, see free website speed testing.
A promising lab result supports a hypothesis. It does not establish that every real visitor now has the same experience, particularly across different devices, connections and interactions.
Use field data to assess visitor experience
Review the trend after enough post-change visits have accumulated. Record the release date beside the results rather than expecting the reporting window to forget earlier visits immediately.
If there is not enough real-user data, keep that limitation visible. Missing field information does not turn a lab result into field evidence.
Connect performance work to the business’s measurement plan. Check that customers can complete important tasks and that improvements do not break enquiry delivery.
Ask for a reconciled explanation
A useful supplier report should say which evidence changed, which has not yet changed and what remains uncertain. It should not select whichever screenshot looks most flattering.
Return to the Core Web Vitals guide for the metric definitions. Once scope and timing are clear, apparently conflicting reports often become complementary evidence about the same website.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
