You ran your site through Google PageSpeed Insights. You scored a 95. You posted it in a Facebook group and people congratulated you.
Then a real user on a mid-range Android phone in rural Germany loaded your page and waited four seconds for anything to appear.
Both things are true at the same time. That is the problem.
PageSpeed scores are useful tools that get misused as the final word on performance. This guide explains what the score actually measures, why it often does not reflect what your real users experience, and what to track instead.
What PageSpeed Insights Actually Does
Google PageSpeed Insights measures two different things. Most people only look at one of them.
Lab data is a simulated test. Google runs your URL through a controlled environment with defined hardware, a throttled network connection, and a specific browser. It produces your score. This is the number between 0 and 100 that everyone pays attention to.
Field data is real user data collected from actual Chrome users who visited your site. It comes from the Chrome User Experience Report (CrUX) and reflects genuine visits on real devices over the past 28 days.
The field data section is the one that matters most. The score is the one everyone talks about.
If your site has enough traffic, PageSpeed Insights shows you both. If your site is smaller, only lab data is available. Many people optimise aggressively for the lab score without ever looking at whether their real users are having a different experience.
Why the Lab Score Can Be Misleading
The lab environment is controlled in ways the real world is not.
It uses a specific device profile The standard PageSpeed mobile test simulates a mid-tier Android device on a throttled connection. Your real users are on a range of devices, from old budget phones to the latest iPhone, on connections ranging from fast fibre to slow 4G in a building with poor signal.
It loads your page in isolation The lab test loads your page as a single isolated request. Real users have browser extensions, open tabs, background apps, and limited device memory that affect how your page loads.
It does not account for geography PageSpeed Insights runs from a specific server location. A 95 score measured from a US server means your page loads fast when the test runs from the US. A user in Singapore or South Africa may have a very different experience depending on where your server is and whether you have a CDN.
It tests a single page load Lab tests always start with an empty cache. Real users returning to your site load from a warm cache. First-time visitors load from cold. The lab tests cold cache consistently. Your real traffic is a mix of both.
The Metrics That Actually Reflect Real User Experience
Google uses Core Web Vitals to measure what real users experience. These are different from your PageSpeed score.
| Metric | What It Measures | Good Threshold | Why It Matters |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the main content appears | Under 2.5 seconds | Users perceive this as when the page is ready |
| INP (Interaction to Next Paint) | How fast the page responds to clicks and taps | Under 200ms | Slow responses feel broken to users |
| CLS (Cumulative Layout Shift) | How much content moves around while loading | Under 0.1 | Unexpected shifts cause users to click the wrong thing |
| TTFB (Time to First Byte) | How fast the server responds | Under 800ms | A hosting and server performance metric |
| FCP (First Contentful Paint) | When the first content appears | Under 1.8 seconds | The earliest signal to users that something is happening |
Your PageSpeed score is a weighted combination of several of these and other metrics, measured in lab conditions. Core Web Vitals are what Google uses in search ranking and what real users actually feel.
A site with a 95 PageSpeed score can still have poor Core Web Vitals in field data if real users are on slower devices or connections than the lab simulates.
Where Hosting Fits Into Real User Experience
Your hosting infrastructure affects real user experience in ways that are visible in field data but sometimes invisible in lab scores.
Time to First Byte is a hosting metric TTFB measures how long it takes your server to send the first byte of a response after receiving a request. This is almost entirely a hosting and server configuration issue. A slow server, a congested shared hosting environment, or an uncached WordPress page all increase TTFB.
A lab test run at off-peak hours from a specific location may show a fast TTFB. Real users hitting your server during peak load, from different geographic locations, may see a very different number.
Read our breakdown of why uptime and server performance affect your visitors for more on what happens at the server level.
CDN coverage affects LCP across geographies If your server is in the US and a user is in Australia, the physical distance adds latency to every request. A CDN solves this by delivering content from a server close to the user.
A lab test runs from one location. If that location is close to your server, LCP looks great. Real users in distant regions may have much higher LCP values. Field data will show this. Lab data may not.
Server load affects response times under traffic Lab tests load your page once in isolation. Real peak traffic means many users loading pages simultaneously. On oversold shared hosting, concurrent requests slow everyone down. This shows up in field data as poor performance during busy periods and may never appear in a lab test run at a quiet time.
Read how caching reduces server load and why it directly improves real user experience beyond just the lab score.
The 95 Score Problem: A Specific Example
Here is how a 95 score and a poor real user experience coexist.
Your site scores 95 in a PageSpeed lab test. This means the lab environment loaded your page efficiently under controlled conditions.
Meanwhile, in the CrUX field data:
- LCP is 3.8 seconds for real mobile users (Poor threshold is over 4 seconds, but anything over 2.5 seconds is not Good)
- INP is 450ms (Poor)
- Your real users are on devices slower than the lab simulation
- Your real users are in countries further from your server than the test location
- Your real users are loading your page while your server is under real traffic load
You would not know any of this from the score alone. You would only see it in the field data section, which many people scroll past.
My opinion: optimising for a PageSpeed score without looking at field data is like training for a race on a treadmill in perfect conditions and then being surprised the outdoor race felt harder.
What to Track Instead
If you want to understand real user experience, track these.
Core Web Vitals in Google Search Console Google Search Console shows your Core Web Vitals from real Chrome user data, grouped by page type and device category. This is the most direct view of how real users experience your site.
Check the Core Web Vitals report monthly. Look at both mobile and desktop. Mobile almost always has more room for improvement.
CrUX data in PageSpeed Insights When you run a URL through PageSpeed Insights, scroll down to the field data section before looking at the score. If your site has enough traffic, you will see real LCP, INP, and CLS values from actual users.
Real User Monitoring Tools like Cloudflare Web Analytics and Vercel Speed Insights collect performance data from real visits in real time. This gives you a continuous view of how performance changes under different traffic conditions.
TTFB from multiple locations Test your server response time from different geographic locations. Tools like WebPageTest let you run tests from specific cities and countries. Compare TTFB from a location near your server to one far away. The gap tells you whether you need a CDN.
Lab Score vs Field Data: The Key Differences
| Factor | Lab Score (PageSpeed) | Field Data (CrUX) |
|---|---|---|
| Device used | Simulated mid-tier mobile | Real user devices, varied |
| Network | Throttled to simulate slow 4G | Real network conditions |
| Location | Single test server location | Real user geographic distribution |
| Cache state | Always cold cache | Mix of cold and warm cache |
| Traffic load | Single isolated test | Real concurrent traffic |
| Useful for | Diagnosing technical issues | Understanding real user experience |
| Used by Google for ranking | No | Yes (Core Web Vitals) |
When the Score Actually Does Matter
I do not want to dismiss PageSpeed scores entirely. They are useful tools.
A lab score tells you whether specific technical issues exist on your page: render-blocking resources, unoptimised images, unused JavaScript, missing text compression. These are real problems that the lab score is good at finding.
Use the score diagnostics section to identify and fix specific technical issues. It is a good debugging tool. It is a poor measurement of what your real users experience.
The score is useful for:
- Identifying technical optimisation opportunities
- Comparing before and after a specific change
- Checking for obvious performance regressions after an update
- Getting a rough baseline when you have no field data yet
The score is not useful for:
- Claiming your site is fast for real users
- Comparing performance across sites with different audiences and geographies
- Making hosting decisions
- Predicting how your site performs during peak traffic
What Genuinely Improves Real User Experience
Focus on these. They affect field data, not just lab scores.
Server response time Improve TTFB by using faster hosting infrastructure, enabling server-level caching, and reducing the number of database queries your page generates. Cloud hosting and managed WordPress hosting typically deliver better TTFB than shared hosting under real load conditions.
CDN coverage Deliver static assets from servers close to each user. This directly reduces LCP for users in regions distant from your main server. Most quality hosts include CDN integration. Some include enterprise-grade CDN through Cloudflare.
Reduced server load A server under heavy load slows down for everyone. Good caching reduces server load significantly. Isolated resources on VPS or cloud hosting mean other users on the same infrastructure cannot affect your performance.
Image optimisation Large unoptimised images are the most common cause of poor LCP. Use modern image formats, serve correctly sized images for each device, and lazy-load images below the fold.
Reduced JavaScript Heavy JavaScript bundles delay INP. Removing unused JavaScript and deferring non-critical scripts improves how quickly your page responds to user interaction.
Final Thoughts
A PageSpeed score of 95 in a lab test tells you your page is technically well-structured under controlled conditions. It does not tell you that your real users are having a fast experience.
Real user experience is measured in field data. It reflects the full range of devices, connections, locations, and traffic conditions your actual visitors bring with them.
Track your Core Web Vitals in Google Search Console. Look at the field data in PageSpeed Insights before the score. Use real user monitoring to understand performance under real traffic conditions.
Optimise for your real users, not for a number in a controlled test environment.
Your hosting infrastructure is one of the biggest levers you have on real user experience. Browse our hosting reviews to compare providers on real-world server performance before making infrastructure decisions based on a lab score.
