PageSpeed Insights explained: how to read your report
A walkthrough of the PageSpeed Insights report: the real-user result, the lab score, the insights and diagnostics, and what each tells you to do.
In this guide
What PageSpeed Insights is
PageSpeed Insights, at pagespeed.web.dev, is a free Google tool that does two things for any public web address. It shows real-visitor data for the page from the Chrome UX Report, and it runs Lighthouse, Google's open-source testing tool, on the page (see the Lighthouse guide). Both appear in one report, with a tab for mobile and one for desktop. Start on mobile: that is where most sites are weaker, and where most of your visitors are.
Layer 1: what your real users experience
The first section is titled "Discover what your real users are experiencing". It is field data: the experience of Chrome users over the last 28 days. Read it first, because it decides whether the page passes. See how a page passes the Core Web Vitals for the rules.
What you will see:
- An assessment. Passed or failed for the Core Web Vitals. To pass, LCP, INP and CLS must all be good at the 75th percentile.
- One bar per metric. Each bar shows the share of visits that were good, needing improvement and poor, with the 75th percentile value above it. The value is the number that is compared with the mark.
- A choice between "This URL" and "Origin". "This URL" is data for the exact page you entered. "Origin" combines every page of the site. If the page does not have enough visits for its own data, PageSpeed Insights shows the origin data and says so. Check which one you are reading before you act on it: a failing origin can hide pages that pass, and the other way around.
- Other metrics. Some reports also list First Contentful Paint and Time to First Byte for real visitors. They are not Core Web Vitals but they help explain a slow LCP.
If a message says there is not enough data, that is not a failure. It means the page, and sometimes the whole site, does not have the minimum number of visitors in Chrome's data. The lab section is still useful.
Layer 2: the lab test and its score
The next section, "Diagnose performance issues", is a Lighthouse test run for you. It starts with the performance score, a number from 0 to 100 in a colored circle: 90 and above is green, 50 to 89 is orange, below 50 is red. Under it are the five metrics that make up the score. The note under them says "Values are estimated and may vary", and a link opens the scoring calculator.
Treat the score as a summary of one test. It does not decide whether you pass the Core Web Vitals, and it changes from run to run (see why scores change). How the score is calculated explains the weights and why 90 is a good result, not a poor one.
At the bottom of the report, a line of settings shows what the test assumed. On the mobile tab you will see an emulated Moto G Power, "Slow 4G throttling" and "Single page session", and for the analysis window "Initial page load". "Single page session" has a tooltip that says it all: the data is from a single page session, as opposed to field data summarizing many sessions.
Layer 3: insights, diagnostics and passed audits
Below the score you can filter the list with "Show audits relevant to:" and one button per metric. Pick the metric that is weakest and the list narrows to what affects it. The list has three parts.
Insights. In Lighthouse 13 these are the main findings, the things worth fixing first. The description says they are also available in the Performance panel in Chrome DevTools, where a recorded trace shows them in more detail. Many have an estimated saving next to them.
Diagnostics. More information about the page. Lighthouse states clearly that these numbers do not directly affect the performance score. They are leads, not penalties.
Passed audits. The checks the page already satisfies. Open it once, because it shows what you do not need to touch.
The insights in Lighthouse 13.5
| Insight | What it tells you |
|---|---|
| LCP breakdown | How the time to the main content splits into four parts. Read the LCP guide |
| LCP request discovery | Whether the main image is found early, has high priority and is not lazy-loaded |
| Render-blocking requests | CSS and scripts that held back the first paint. Read critical CSS and render-blocking resources |
| Document request latency | Redirects, slow server response and missing compression on the page itself. Read the TTFB guide, server response time and text compression |
| Improve image delivery | Images that could be smaller. Read image optimization |
| Layout shift culprits | What moved, and the likely reason. Read the CLS guide |
| INP breakdown | The three parts of a slow interaction, when an interaction was recorded. Read the INP guide |
| Font display | Fonts that hold text back while they load |
| 3rd parties | Code from other companies, with the time each one used |
| Network dependency tree | Chains of requests where each file reveals the next |
| Use efficient cache lifetimes | Files that are re-downloaded because they are not cached long enough |
| Legacy JavaScript and Duplicated JavaScript | Code sent to browsers that do not need it, and modules bundled more than once |
| Optimize DOM size | A page with so many elements that every update is slow |
| Forced reflow | Scripts that make the browser recalculate layout in the middle of their work |
| Modern HTTP | Whether the server uses HTTP/2 or HTTP/3 |
| Optimize viewport for mobile | A missing or wrong viewport tag that delays taps on phones |
You will not see all of these on one page. A page that has none of a given problem simply does not list it.
A worked example
Here is how the layers fit together on an imaginary report for a small business site. The numbers are made up to show the method.
Layer 1. On the mobile tab, the assessment says the page failed. LCP is 3.4 seconds (needs improvement), INP is 150 milliseconds (good) and CLS is 0.02 (good). One metric fails, so that is where to work. Nothing else needs attention.
Layer 2. The lab score is 68, in orange, with LCP the weakest of the five metrics. The filter button for LCP narrows the list.
Layer 3. The LCP breakdown splits the time into four parts, and the second part, the resource load delay, is the longest. The LCP request discovery insight explains why: the main image is lazy-loaded and does not have high priority. That is a two-attribute fix: remove loading="lazy" from that one image and add fetchpriority="high".
After the change the lab LCP drops within minutes, and the assessment at the top follows over the next four weeks. The whole job took three steps: find the failing metric in layer 1, find its cause in layer 3, and confirm in layer 2.
How to use a report, step by step
- Choose the page. Test the pages that matter to your business, such as the home page, the main service page and a product page, not only the one that is easiest to remember.
- Read the real-user result on mobile. Does it pass? Which metric fails?
- Filter the lab list to that metric. Open the top one or two insights and read what they say.
- Fix one thing, then test again. Run the test at least three times, five if you can, and use the middle result. Never compare a single run with a single run.
- Come back in four weeks. The real-user result needs that long to reflect a fix.
Common misreadings
- "The score is green, so I pass." Passing is decided by the real-user assessment at the top, not by the circle.
- "I have to fix every item." The list is a menu, not a to-do list. Fix what affects the failing metric.
- "The savings add up." Each estimate is calculated on its own. Several insights can describe the same wasted time, so the total is usually smaller than the sum.
- "Desktop and mobile should match." They are tested with different settings and judged against different marks. A page can pass on one and fail on the other.
- "No data means it is broken." It means the page is not in Chrome's data. Use the lab section, and check the origin view.
- "Another tool shows a different number, so one of them is wrong." Different tools use different settings and different moments. Compare like with like.
Check your own page
Run the free audit: it reports the same two kinds of data in plain language and points at the first thing to fix. Use PageSpeed Insights when you want to look at the raw report yourself, and paste the report address into a note so you can compare after you make a change.
Sources
- PageSpeed Insights: the tool itself.
- Lighthouse performance scoring: what counts toward the score and why it varies.
- Chrome UX Report methodology: where the real-user section comes from.
- Optimize Cumulative Layout Shift: a worked example of reading both sections of the report.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Core Web Vitals · Book a call