Does PageSpeed Insights really measure your site's performance?

What differentiates lab tests from real-world data?

Lab tests like PageSpeed Insights are based on a controlled and standardized environment. Lighthouse, the underlying tool, simulates a visit to your site from a virtual machine with predefined settings: throttled CPU, throttled connection, fixed viewport.

In contrast, field data comes from the Chrome User Experience Report (CrUX), which aggregates the real metrics of millions of Chrome users worldwide. It is this second source that Google uses for ranking — not lab scores.

Why does the location of the testing server matter so little?

The TCP/SSL connection time typically ranges from 100-300 ms over an intercontinental connection. This is negligible compared to the 2-5 seconds that an unoptimized image or blocking JavaScript can add.

Mueller emphasizes this point: it's not the physical distance between the testing server and your hosting that degrades your scores. It's the structural heaviness of your site. A well-architected site will achieve good scores even when tested from the other side of the world.

What does "prediction" actually mean in this context?

PageSpeed Insights tells you: "If an average user visits this site under standard conditions, here is what they should experience." This conditional aspect is crucial — it guarantees nothing about your actual visitors.

There are many variables that the test cannot capture: browser extensions, antivirus software, unstable mobile connections, low-end devices not represented in the simulation. A lab score of 95 may correspond to an LCP of 4 seconds for 30% of your real users if your audience predominantly uses lower-end smartphones.

• Lab tests (PSI, Lighthouse): controlled, reproducible environment, useful for diagnosing specific technical issues
• CrUX data: real aggregated metrics over a rolling 28 days, weighted in Google ranking
• Structural factors (images, JS, CSS, architecture) have an impact 10-20x higher than server connection time
• The geolocation of the test does not significantly affect scores if your site is technically optimized
• A good lab score does not guarantee good field performance — always check your CrUX data in Search Console

Is this statement consistent with what we observe in the field?

Yes, but with an important nuance. Tests indeed show that pure network latency (ping) accounts for less than 10% of total loading time on a modern site. However, Mueller oversimplifies a bit: on poorly configured sites without a CDN, the geographical distance can become significant.

I have audited e-commerce sites hosted only in Eastern Europe targeting North America. The TTFB regularly exceeded 800 ms for US visitors, which mechanically degraded the LCP. In this specific case, the server location was not trivial — it revealed an infrastructure problem.

When should you still worry about server location?

For high-traffic international sites without a CDN or with heavy server logic (customization, complex user sessions), TTFB remains a critical indicator. Google measures it via CrUX, and a poor TTFB systematically degrades LCP.

Mueller's statement primarily targets SEOs concerned about whether PageSpeed Insights tests from the right region. His answer: it doesn't matter, since lab scores are merely technical diagnostics. What matters are your actual CrUX data, and there, the geolocation of your servers versus that of your visitors can play a role — especially if your technical stack is outdated.

What are the limitations of this predictive approach?

PageSpeed Insights tests with a standardized user profile: throttled 4G connection, mid-range CPU, empty cache. If your actual audience predominantly uses 3G in Southeast Asia or iPhone 14 on 5G in Scandinavia, the gap between prediction and reality will be massive.

Mueller doesn't explicitly say it, but lab tests have another weakness: they do not capture temporal variations. Your server may be fast at 3 AM (when PSI tests it), but overloaded at 6 PM. CrUX data averages these variations — that's why they are more reliable for ranking. [To be verified]: Google has never published the hourly distribution of CrUX collection, so it's unclear whether certain time slots are overrepresented.

What should you prioritize to improve real performance?

Start by focusing on the structural levers that Mueller mentions: optimizing images (WebP/AVIF formats, smart lazy-loading, appropriate dimensions), reducing blocking JavaScript (defer, async, code-splitting), and optimizing CSS (critical CSS inline, removing unused CSS).

Then, check your CrUX data in Search Console. This is where you see what your real users experience — by device (mobile/desktop) and by metric (LCP, FID, CLS). If your lab scores are green but your CrUX is orange or red, the problem lies elsewhere: audience on low-end devices, heavy third-party scripts, or unoptimized dynamic content.

How to correctly interpret PageSpeed Insights results?

Use PSI as a technical diagnostic tool, not as a performance dashboard. A score of 60 with clearly identified optimization opportunities ("eliminate render-blocking resources", "defer offscreen images") is more actionable than a score of 95 obtained at the expense of user experience.

Never compare your lab scores between different times of the day or from different geographic locations — that's statistical noise. What counts is the trend in your CrUX data over 28 days, and the percentile distribution (75th percentile) that Google uses for ranking.

What common mistakes should you absolutely avoid?

Stop testing your site 10 times a day on PageSpeed Insights hoping for a better score. Variations of ±5-10 points are normal and meaningless. Stop optimizing for lab metrics that degrade the real user experience: lazy-loading above-the-fold content, 200 KB inline CSS, removing critical images.

And above all, don't panic if your hosting is geographically distant from your audience as long as you use a modern CDN. Mueller's advice is clear: physical distance is a false problem if your technical architecture is solid.

• Check your CrUX data in Search Console (real data over 28 rolling days)
• Prioritize optimization of images (format, dimensions, lazy-loading), blocking JS, and critical CSS
• Use PageSpeed Insights as a technical diagnostic, not as a performance KPI
• Deploy a CDN if your audience is geographically dispersed
• Measure the impact of each optimization on CrUX metrics, not lab scores
• Test on actual low-end devices if your target audience isn't premium