How Google PageSpeed Insights Works: Improve Your Score
In this article
Google PageSpeed Insights (PSI) tests a single URL and tells you how fast it is on mobile and desktop. Paste a URL into pagespeed.web.dev and you get two reports: field data from real Chrome users over the last 28 days, and lab data from a fresh Lighthouse test, which produces the 0 to 100 Performance score.
This article explains how each half works, how the score is calculated, and where to start improving it.
Google's ranking systems use Core Web Vitals, measured from real Chrome visits, as one signal among many. Read more about Core Web Vitals.
The PageSpeed score is a lab measurement, and Google does not rank on it. It is still worth understanding, because it is the number most teams are asked to improve.
How Google PageSpeed Insights works#
Early versions of PageSpeed ran a series of heuristics against a page. Large, uncompressed images? Compress them. Cache-Headers missing? Add them.
These guidelines would likely improve performance if followed, but didn't analyse the load and render experience real visitors face.
Today, PageSpeed Insights reports two separate things:
- Field data, at the top: what real Chrome users experienced on your page over the last 28 days, from the Chrome User Experience Report.
- Lab data, below it: a single page load in a real Chrome browser, controlled by Lighthouse.
Field data: what your real users are experiencing#
The top section, headed "Discover what your real users are experiencing", is CrUX data, refreshed daily and covering the previous 28 days. It shows the three Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift), then First Contentful Paint and Time to First Byte.
- The 75th percentile is what counts. Each metric is reported at the 75th percentile, alongside the share of visits rated good, needs improvement and poor. See the Core Web Vitals thresholds for exact values.
- The Core Web Vitals assessment passes only when all three are good. Without enough INP data, it uses LCP and CLS alone.
- This URL, or the whole origin. PSI shows page-level data when CrUX has enough for that URL. Otherwise it falls back to origin data, covering every page on the site. Small sites may have neither.
Mobile and desktop are reported separately, so check both tabs. Only opted-in Chrome users contribute, and Chrome on iOS is not included.
Lab data: a Lighthouse test#
Below the field data, PSI runs Lighthouse against your URL on Google's servers:
- Mobile tests emulate a mid-tier phone on a mobile network.
- Desktop tests emulate a desktop computer on a wired connection.
- Throttling is simulated. The page loads at full speed, then Lighthouse calculates how it would have performed on the slower connection.
The Performance Score comes from the lab half. It is the same number as the Lighthouse Performance Score. PageSpeed Insights runs Lighthouse 13, released in October 2025.
What is Google Lighthouse?#
Lighthouse is an open source project run by a dedicated team from Google Chrome. It has become a widely used, free performance analysis tool.
Lighthouse uses Chrome's Remote Debugging Protocol to read network requests, measure JavaScript performance, check accessibility and measure user-focused timing metrics like Largest Contentful Paint or Total Blocking Time.
For a high-level overview of Lighthouse architecture, read this guide from the official repository.
How the PageSpeed Insights Performance score is calculated#
Five Lighthouse metrics make up the performance score:
- Total Blocking Time (TBT)
- Largest Contentful Paint (LCP)
- Cumulative Layout Shift (CLS)
- First Contentful Paint (FCP)
- Speed Index
Lighthouse scores each metric from 0 to 100 on a log-normal curve with two control points taken from real website data in HTTP Archive: the 25th percentile maps to a score of 50, and the 8th percentile to 90. Scoring is not linear, so the same saving in milliseconds is worth more points at some values than others.
Each metric score is then weighted to produce the overall score:
| Metric | Weighting |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
Mobile and desktop use the same weights, with separate scoring curves. The weights have been stable since Lighthouse 10, the release that removed Time to Interactive.
Total Blocking Time is the most heavily weighted metric, so you'll need a low TBT to get a high score. The overall score is banded: 0 – 49 is poor, 50 – 89 needs improvement, and 90 – 100 is good.
Use the Lighthouse Score Calculator to explore how metrics relate to performance score in real time.
Moving the needle on Total Blocking Time#
Total Blocking Time adds up the blocking portion of every main thread task longer than 50ms after First Contentful Paint. Two factors influence it heavily:
- The amount of JavaScript delivered to the page
- The run time of JavaScript tasks on the main thread
Our Total Blocking Time guide explains the metric in detail. For quick wins, we suggest:
Reducing the amount of JavaScript#
Remove unused JavaScript, and deliver only what the current page runs.
The cost of JavaScript is not only download time. The browser must decompress, parse, compile and execute it, which takes non-trivial time, especially on mobile devices.
Effective ways to reduce script on your pages:
- Remove polyfills your audience no longer needs.
- Understand the cost of each third-party library. Use webpack-bundle-analyzer or source-map-explorer to visualise how large each one is.
- Break large applications into small bundles loaded as the user navigates. This is code splitting, and it is extremely effective in reducing blocking time.
- Service workers will cache the bytecode of a parsed and compiled script. Visitors then pay the parse and compile cost once, and the cache covers it after that.
Blocking time in the lab is a proxy for what real people feel when they tap something. To check whether the work landed, look at Interaction to Next Paint in your field data.
In-depth manual profiling#
For the best results when profiling JavaScript, test on intentionally slow mobile devices. An old phone in a desk drawer is ideal.
A good substitute for a real device is Chrome DevTools hardware emulation. Our performance profiling guide will help you get started with runtime performance.
What about the other metrics?#
Speed Index, First Contentful Paint and Largest Contentful Paint are all paint-based metrics. Similar factors influence them, so they often improve together.
They depend on how quickly a page renders, so following the Lighthouse recommendations will improve them.
Lighthouse 13 consolidated many of those audits into insights shared with the Chrome DevTools Performance panel. lcp-lazy-loaded became part of LCP request discovery, and offscreen-images was removed. The score did not change, only the advice.
If you aren't already preloading your fonts or optimising for critical requests, start there. The Critical Request explains how the browser fetches and renders critical resources.
Why your PageSpeed score changes between tests#
Run the same URL twice and the score can move a few points. Common causes:
- The page itself changes. A/B tests and rotating ads load different content.
- Network routing varies. Internet traffic takes different paths between runs.
- Test hardware differs. Results depend on the machine running the test.
- Test location varies. PSI runs from one of four Google locations, so network distance to your server changes.
These factors, plus throttling and device emulation, are why two tools rarely agree. Emulate PageSpeed in Calibre shows how to match them.
Field data and the Performance score rarely match either:
- The Performance score is one Lighthouse load on a throttled connection.
- Field data is 28 days of real visits on your audience's own devices and networks.
See why Synthetic, CrUX and RUM numbers differ.
Tracking your progress and making meaningful improvements#
PageSpeed Insights is excellent for checking a single URL right now. Lasting improvement needs the same measurement on a schedule, with history.
We built Calibre for that:
- Scheduled Lighthouse tests run from the locations and devices you choose, and every result is kept.
- Performance budgets notify you when a metric goes over its limit.
- CrUX for each important page is tracked as soon as you add a Site.
- Real User Monitoring covers the visitors CrUX doesn't.
Frequently asked questions#
Is Google PageSpeed Insights accurate?#
Yes, for what each half measures. Field data is real Chrome visits at the 75th percentile. The Performance score is one Lighthouse run, and varies a little between runs.
Does the PageSpeed score affect Google rankings?#
Not directly. Google ranks on Core Web Vitals from field data, not the lab score. The same work usually improves both.
What is a good PageSpeed Insights score?#
90 to 100 is good, 50 to 89 needs improvement, and below 50 is poor. For search, a passing Core Web Vitals assessment in the field data matters more.
Why does PageSpeed Insights say there is no real user data?#
The URL, and possibly the whole origin, doesn't have enough eligible traffic in CrUX. Lab data and the Performance score still appear.
Which version of Lighthouse does PageSpeed Insights use?#
Lighthouse 13. Google announced it in October 2025. It changed the advice PSI gives, not how the score is calculated.