In this article, I'd like to provide some insight into how Google's PageSpeed Insights works, since it works in a rather confusing and non-obvious way, making many wonder about whether it's actually accurate or not.
How PageSpeed Insights Measures Performance?
First of all, Google's PageSpeed Insights' report is divided into two sections: the first, displayed prominently, and the main source of confusion, are measurements from "real user data." This is user data collected by Google Chrome when you visit a webpage. It's also called the CrUX report.
The second section is an automated test run by headless browser in Google's server. Essentially what this means is that there is program that runs in Google's servers that works exactly like Chrome, but isn't actually a window that a human interacts with. It downloads the webpage from the URL, processes it like a real browser would, makes the measurements, and reports them.
Both sections report various metrics, such as LCP (Largest Contentful Paint), INP (interaction to Next Paint), CLS (Cumulative Layout Shift), FCP, TTFB (Time To First Byte).
The automated test isn't really that useful for measuring real world performance, which is why CrUX is displayed first. But as we'll soon understand, that is why everything looks wrong.
Why the Real User Data Looks Different from the Automated Test?
There are three reasons why the automated test displays some results, usually great results, while the real user data shows poor performance.
Access Differences
The first possible reason is that your users' access conditions are simply different from Google's. This, too, could have various reasons behind it.
Poor Hardware
Maybe their hardware is inferior to the hardware that Google emulates. Maybe their smartphones are just terrible, or they have a poor Internet connection.
Server Location
If you have a website with servers located in the Unites States or Europe, but your users mainly originate from Asia, Africa, or South America , it's possible that Google's servers just happen to be closer to your servers, while your real users are not.
CDN Issues
Similarly, if you use a CDN (Content Delivery Network), or cloud-based hosting, it's possible that the location of the servers doesn't match where most of your users are.
In a distributed network, there is also the possibility that your webpage's data is cached in one location but not in another for some reason, so in one location the data is served from the cache of the CDN, while in the other location it needs to be pulled from the origin server which adds latency due to this extra trip, increasing the TTFB metric.
Simply The Wrong Data
The is a very important thing to watch out for.
More specifically, if a URL has too few visitors, what's displayed in the first section of PageSpeed Insight won't be the CrUX report for that specific URL but, instead, the CrUX report for the whole origin, in other words, for the fully qualified domain name (FQDN).
For example, if a URL of this website that has too few clicks, Google will instead display the CrUX report for the whole domain name www.virtualcuriosities.com. Presumably, this is the average performance of the website. It's important to keep in mind that, since this is by origin, it doesn't affect other subdomains—e.g. br.virtualcuriosities.com has separate performance statistics.
If you arrive on PageSpeed Insight's from Google Search Console's Core Web Vitals page because some URL's "need improvement," but it says "User experience is evaluated for URL groups, not individual URLs" and "There are only URLs with not enough LCP usage data in this group," that means when you access the PageSpeed Insights, the first thing you'll see is the average data for the entire domain, it will not be for that specific webpage.
Even if you try to improve the performance of that specific webpage by making adjustments, the performance report isn't going to change, since what you're being shown is the average for the entire website.
You can tell which report you're seeing by keeping in mind the button on the top-right corner above the report. If "This URL" is selected, you're seeing data for the URL, otherwise you're seeing data for the entire "Origin."
How Many Visitors do You Need for the CrUX Report to Show Real User Data for a URL?
Although Google doesn't disclaim the exact number, which is probably subject to change over time, it seems that if you have at least 1000 visitors per 3 months (or around 10 visitors per day) on a webpage that should be enough to give Google enough data to display a report specific for the URL instead of for the whole domain.
I've arrived at this number by simply testing some URL's with various numbers of visitors. It seems that the number of visitors can be lower if the webpage has been published for multiple years, or perhaps it just varies from URL to URL.
Your Website is Extremely Fast but Has a Poor Automated Score
It's important to keep in mind that the automated test only measures how long a webpage loads for a user who hasn't visited the website before, and, therefore, its results and recommendations can be very misleading.
When a user accesses a webpage, the browser downloads all resources linked to the webpage, and, if the web server is configured properly, some of these resources will be cached. Caching is extremely powerful. It's so powerful it's literally the difference between accessing the Internet and not accessing the Internet at all.
If a webpage has 10 megabytes of resources, it can take a few seconds to load, but if ALL of it is cached, including the HTML, the second time a user tries to access it, it's going to load under 100 milliseconds. That's because if everything is cached, it's fetched from the disk or the RAM, nothing needs to be downloaded from the Internet.
Consequently, it's possible for a website to have a lot of Javascript, CSS, or images that needs to be loaded the first time the user accesses a webpage, so the automated test for a specific URL will look bad, but after that they aren't loaded again, so the CrUX report based on real world usage will be good, because this report will contain load times of users who had already accessed another webpage of the website, so they had cached resources, which makes their load times significantly faster than load times of the automated test or of users who only access one webpage.
With this in consideration, a simple trick to improve your performance scores is to simply have more users who visit more webpages of the same website, instead of users who only access one webpage and then go away. In other words, a lower "bounce rate" (the rate of users who visit one webpage and go away) leads to a better performance on the CrUX report.