PageSpeed Insights shows one summary score from 0 to 100 and dozens of individual diagnostic lines, but most administrators only read the number at the top. This article covers what stands behind that number, which figures in the report can be trusted, and which are just a rough estimate from a single measurement.
What makes up the 0-100 number
The final Lighthouse score (the one shown as a large number in PageSpeed Insights) is not a raw set of metrics but a weighted sum of six measurements, where some metrics carry noticeably more weight: Total Blocking Time weighs more than any other.
| Metric | Weight in the final score |
|---|---|
| First Contentful Paint (FCP) | 10% |
| Speed Index (SI) | 10% |
| Largest Contentful Paint (LCP) | 25% |
| Total Blocking Time (TBT) | 30% |
| Cumulative Layout Shift (CLS) | 25% |
The color boundaries are known in advance: from 0 to 49 points is the red zone, 50 to 89 is orange, and 90 to 100 is green. The table shows that chasing a single metric without improving TBT barely moves the final score — that metric's weight is larger than the weights of FCP and SI combined.
Why there are Lab Data and Field Data
The top block of the report is Lab Data, a single measurement under emulated conditions (a simulated mid-range mobile device and a throttled network); it reproduces consistently but does not reflect the spread of real visitors.
Below it, if the site has enough traffic captured in the Chrome User Experience Report, a block with real visitor data from the last 28 days appears — this is the block that decides whether the site passes the Core Web Vitals assessment in Google Search Console; sites with low traffic do not get this block at all and have to rely on Lab Data only.
How to read the list of recommendations
Below the score comes a list of diagnostics with an estimated potential time saving — it does not add up arithmetically, because some improvements overlap, but the order in the list roughly matches the significance of the finding.
Eliminate render-blocking resources — Est savings of 0.4 sThe saving figure comes from a single simulated run and shows the upper bound of that specific fix's effect under lab conditions — it does not guarantee the same drop in Field Data for real visitors, because their devices and networks differ from the emulation.
What to look at first
The list of diagnostics is worth reading not top to bottom in report order, but by a combination of factors:
- Start with the item that has the largest estimated saving — it gives the best chance of moving the final score with a single fix.
- Check the server response time (TTFB) before front-end fixes — a slow TTFB drags LCP down regardless of image and script optimization; response compression is covered in the article about Gzip and Brotli in Nginx.
- Set width and height attributes on images even if the files themselves are already optimized — this removes layout shift regardless of image weight.
- Do not chase the number 100 by hand-editing individual directives — most of the list is closed out by the combination of caching, compression, and modern image formats covered in the article about speeding up WordPress.
- Re-check the report after each fix separately, not after a batch of ten changes at once — otherwise it is unclear which fix actually had an effect and which did not matter at all.
Separate from this list, the report has a Passed audits section — things that are already done correctly; the point of it is not to fix anything, but to leave it alone during the next theme or plugin change.
What the report will not show
PageSpeed Insights checks one page at one moment in time — it will not show that the server consistently responds slowly at night because of backups, or that the site was unavailable for a few minutes outside the moment of the measurement.
That needs a separate, continuous check of availability and response time — for example, set up as described in the article about site monitoring: UptimeRobot, Zabbix, and system alerts; the PageSpeed report complements that kind of monitoring but does not replace it.
Frequently asked questions
Why does the score differ between phone and computer?
The mobile assessment uses a far stricter CPU and network throttle than the desktop one, so the very same site predictably gets different scores on the two report tabs — the difference by itself does not mean a hidden problem on just one platform.
Can this report be used to judge the site's search rankings?
No, the PageSpeed score reflects only the Core Web Vitals metrics and overall speed, not the whole set of ranking factors — a high score does not guarantee a high position, and a low one does not by itself explain a ranking drop if other factors (content, links, relevance) have not changed.
Is it worth rebuilding a site just to get a score of 100?
No, the final number is a reference point, not a goal in itself: real user experience is defined by the actual Core Web Vitals from Field Data, and a site with a score noticeably below 100 but with all three metrics passing their thresholds for real visitors wins more than a site pushed to 100 at the cost of cut functionality.