A PageSpeed score is the 0-100 performance score Google PageSpeed Insights shows at the top of a result: a weighted summary of five lab metrics from one simulated visit on a mid-range phone. A score of 90 or more is good, 50-89 needs improvement and under 50 is poor. The score is a diagnosis, not a ranking signal: Google ranks with the real-visitor Core Web Vitals shown above it. This guide explains how to read the whole result in the order that matters, and how to turn it into three fixes. For the wider topic, what page speed is and how to improve it across a site, start with the page speed guide.
Quick answer
- Good PageSpeed score: 90-100 (green). Needs improvement: 50-89 (orange). Poor: 0-49 (red). Mobile scores are almost always lower than desktop.
- The score comes from Lighthouse: Total Blocking Time 30 %, Largest Contentful Paint 25 %, Cumulative Layout Shift 25 %, First Contentful Paint 10 %, Speed Index 10 %.
- The field data (real Chrome visitors, 28 days) decides Google's Core Web Vitals assessment. Three metrics matter: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1.
- A score that moves 5-10 points between runs is normal; compare the metrics, not the score.
- Fix in this order: the LCP element (usually the hero image or a web font), render-blocking CSS and JavaScript, layout shifts from images and fonts, then JavaScript weight.
- Check your pages with the website speed test on mobile first; that is the version Google indexes.
What the PageSpeed score is made of
PageSpeed Insights runs Lighthouse (version 13 since October 2025) on Google's servers, on an emulated Moto G Power with a 412 × 823 px screen, a CPU slowed four times and a simulated slow 4G connection (150 ms round trip, about 1.6 Mbit/s). Each of five metrics is turned into a 0-100 sub-score on a curve built from real-world sites, then weighted:
| Metric | Weight | Good |
|---|---|---|
| Total Blocking Time (TBT) | 30 % | ≤ 200 ms |
| Largest Contentful Paint (LCP) | 25 % | ≤ 2.5 s |
| Cumulative Layout Shift (CLS) | 25 % | ≤ 0.1 |
| First Contentful Paint (FCP) | 10 % | ≤ 1.8 s |
| Speed Index (SI) | 10 % | ≤ 3.4 s |
Two consequences follow. A page with a fast LCP but a lot of JavaScript can still score in the 60s, because TBT carries the biggest weight. And past about 90 the curves flatten: going from 1.8 s to 1.2 s LCP earns few points. Lighthouse score vs Core Web Vitals explains the weighting and why a 100 does not mean a page is fast for real visitors.
Why the numbers disagree
There are two kinds of data. Lab data comes from one run on the simulated phone at the moment you tested. Field data is what real Chrome users experienced on your pages over the last 28 days, from the Chrome UX Report (CrUX). They disagree for good reasons: your visitors have different phones and connections, they hit cached pages, they scroll before the ads load. Google's ranking systems use field data when there is enough of it; the lab data tells you why the field numbers look the way they do. Field data vs lab data goes deeper.
The lab score also moves between runs. The server's response time, a CDN cache miss, a third-party script that took longer this time and the load on the test machine all change the result. A 6-point swing is normal; a 20-point swing usually means the server or a third party is inconsistent, which is itself a finding.
How to check your website speed
The speed test asks PageSpeed Insights for a Lighthouse run of the page on mobile and desktop, plus the CrUX field data for the URL and the whole site. When Google's API is unavailable, a local Lighthouse run in our own Chromium stands in and the result is labelled "lab estimate". Each Lighthouse finding is rewritten in plain language with a fix, and the module panel shows the Core Web Vitals bars, the filmstrip and the waterfall. To test many pages at once use the bulk PageSpeed checker; to put your page next to a competitor's, compare speed.
Test three pages, not one: the home page, your busiest template (a product or article page) and a page with a form or search. Each has a different LCP element.
The metrics, in visitor terms
| Metric | What the visitor feels | Good | Used for ranking |
|---|---|---|---|
| TTFB (Time to First Byte) | How long the page "thinks" before anything arrives | ≤ 0.8 s | Indirectly (it delays everything) |
| FCP (First Contentful Paint) | The first text or image appears | ≤ 1.8 s | No |
| LCP (Largest Contentful Paint) | The main thing on screen is visible | ≤ 2.5 s | Yes |
| Speed Index | How quickly the visible area fills in | ≤ 3.4 s | No |
| TBT (Total Blocking Time) | How long the page ignores taps while scripts run (lab stand-in for INP) | ≤ 200 ms | No (INP is) |
| INP (Interaction to Next Paint) | The delay between a tap and the screen reacting, over the whole visit | ≤ 200 ms | Yes (field only) |
| CLS (Cumulative Layout Shift) | Things jumping while the page loads | ≤ 0.1 | Yes |
INP only exists in field data: the lab test cannot click around like a visitor, so it reports TBT as a proxy. And the "good" thresholds apply at the 75th percentile: three quarters of visits must be under the threshold for the page to pass. FCP and Speed Index are explained in First Contentful Paint and Speed Index.
Step by step
1. Look at the field bars first
If the page has enough traffic, the panel shows the CrUX bars for LCP, INP and CLS with the share of visits in good, needs-improvement and poor. PageSpeed Insights shows the same data under "Core Web Vitals Assessment: Passed / Failed". A page can score 95 in the lab and fail the field assessment because real visitors on old phones see a 3.2 s LCP; the reverse also happens.
No field bars means the page did not have enough Chrome visitors in the last 28 days. getReport then shows the whole site's data if there is any; small sites often have none, and the lab is the best evidence you have.
2. Find the LCP element
The LCP finding names the element: an image, a heading, a video poster. Everything before it on the timeline is what delays it. Typical causes in order of frequency: the image is large, the image is lazy-loaded, a web font blocks the headline, render-blocking CSS delays everything, or the server itself is slow (TTFB). Largest Contentful Paint walks through each.
3. Read the insights as causes, not a to-do list
Lighthouse 13 groups its suggestions as Insights ("Render-blocking requests", "Improve image delivery", "LCP breakdown", "Document request latency") with an estimated saving each. The estimates are rough and overlap: removing a blocking stylesheet also changes what "unused CSS" would save. Use the list to understand what the page is doing, then pick the fix that addresses the LCP element directly.
4. Check TBT and the long tasks
A high TBT with a low LCP means the page appears quickly and then freezes: a tag manager loading twelve tags, a slider initialising, an analytics script parsing. The main-thread work finding lists the scripts by time. This is what visitors feel as "the menu did not open when I tapped it", and it is what INP measures in the field.
5. Look for layout shifts
The CLS finding lists the elements that moved. Images without dimensions, web fonts swapping, cookie banners inserted at the top and ads are the usual four. Each has a mechanical fix; see Cumulative Layout Shift.
6. Compare mobile and desktop
Desktop scores are almost always higher: no CPU slowdown, a faster simulated network and a wider viewport. If desktop is 95 and mobile is 60, the difference is usually image bytes and JavaScript execution, both of which cost more on a phone. Mobile vs desktop scores covers what to do about the gap.
Page size and load events
Above the filmstrip, five tiles give the numbers GTmetrix and Pingdom lead with: the page size, the number of requests, and when the page was ready (DOMContentLoaded), loaded (onload) and fully loaded (the last request finished). The tables under them split the weight by type of file and by domain, with the company behind each domain, so a 3 MB page shows at once whether it is images, scripts or other companies' tags. The three times come from Google's test browser before it simulates a slower phone, so they run faster than the scored timings above them.
Reading the waterfall and the filmstrip
The waterfall lists every file in the order it was requested, with a bar for the time spent waiting and downloading. Look for a long first bar (slow server), a chain of files each waiting for the previous one, and a large file that starts late (a lazy-loaded hero). The filmstrip shows what the visitor saw at each moment; the frame where the main content appears should match the LCP value. Reading a waterfall chart covers both views, bar by bar and frame by frame.
What a good result looks like
Mobile: LCP under 2.5 s with the hero as the LCP element, CLS under 0.05, TBT under 200 ms, score 90 or more, and field bars mostly green. Desktop follows. Small sites on decent hosting with optimised images get there without a CDN; sites with page builders and many plugins usually need to remove things rather than add them.
Verify
- Run the test three times; the metrics should agree within a few hundred milliseconds. Large swings point at the server or a third party.
- After a fix, let the page cache and CDN warm up, then re-test with the report's "Check again" button (reports are cached for 12 hours per URL). The old report link keeps the "before".
- Field data covers a rolling 28 days, so expect about four weeks before the field bars and Search Console's Core Web Vitals report fully reflect a fix.
Common mistakes
- Optimising for the score. A score is a weighted sum of the metrics; a 90 with a 2.4 s LCP is fine, a 92 from inlining everything and breaking caching is not.
- Testing the home page only. Product and article pages carry the traffic and have different LCP elements.
- Testing from the office. Fast Wi-Fi and a laptop are not the visitor's phone; the test's throttling is closer to reality than your browser.
- Comparing scores across Lighthouse versions. A new version can move the score with no change to the site; the version is printed next to the lab table.
- Ignoring field data because the lab score is green. Google does the opposite.
Questions people ask
Which part of a speed test result does Google use for rankings?
Only the field data: the Core Web Vitals of real Chrome visitors, shown at the top of the result where Google has enough traffic for the page or site. The 0-100 performance score and the lab metrics come from one simulated visit and are not used for ranking. Read them to find the cause, and judge the page by whether LCP, INP and CLS pass in the field. How important page speed is for SEO covers the rest.
Why does my speed test score change every time I run it?
Because the lab test is one page load at one moment, and several things change between runs: the server's response time, whether a CDN or page cache was warm, how long third-party scripts took, and the load on the test machine. A swing of 5-10 points is normal. Compare the metrics rather than the score, run the test three times, and treat swings over 20 points as a sign of an inconsistent server or third party.
What is a good website speed test score?
A Lighthouse performance score of 90 or more on mobile is good, 50-89 needs improvement and under 50 is poor. The score matters less than the three Core Web Vitals behind it: LCP at 2.5 s or less, INP at 200 ms or less and CLS at 0.1 or less, measured at the 75th percentile of real visits. A page scoring 85 that passes all three in the field is in better shape than a lab 95 that fails them.
Why does PageSpeed Insights show a score but no Core Web Vitals assessment?
Because the assessment needs field data, and Google publishes it only for pages and sites with enough Chrome visitors over the last 28 days. The score comes from a lab run, which works for any public page. Without field data, use the lab metrics as your estimate: fix what the LCP, CLS and TBT findings name, and the assessment appears once the site has enough traffic to be in the Chrome UX Report.