Performance
How do you read a PageSpeed Insights report?
PageSpeed Insights mixes real-user data and a lab test. What each part means, why the score moves between runs, and which numbers to act on first.
PageSpeed Insights shows two things: field data from real Chrome users over the last 28 days, and a Lighthouse lab test of one simulated load. The field data shows whether your Core Web Vitals pass. The lab score and its diagnostics help you find causes. Act on failing field metrics first, using the lab audits to explain them.
Published · Last updated
The two halves of the report
- Discover what your real users are experiencing. Field data from the Chrome UX Report: LCP, INP and CLS, plus FCP and TTFB, at the 75th percentile over 28 days. If the page lacks enough traffic, it shows origin-level data or none.
- Diagnose performance issues. A Lighthouse run on Google's servers, with a performance score from 0 to 100, the lab metrics behind it and a list of opportunities. They often disagree. That is expected: one is thousands of real visits, the other a single simulated one.
The Core Web Vitals assessment
At the top, PageSpeed Insights says whether the page passes or fails Core Web Vitals. To pass, all three, LCP, INP and CLS, must be good at the 75th percentile. Thresholds: LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1. This is the part tied to Google's page experience signals.
The lab score
The 0 to 100 score is calculated by Lighthouse from weighted lab metrics: Total Blocking Time and Largest Contentful Paint carry the most weight, followed by Cumulative Layout Shift, then First Contentful Paint and Speed Index. The mobile test simulates a mid-range phone on a throttled network, which is why mobile scores are usually lower.
- 90 to 100: good.
- 50 to 89: needs improvement.
- Below 50: poor.
The score varies between runs because of server load, network conditions and third-party scripts. Compare several runs, and do not chase single points.
What to act on first
- A failing field metric. Find the matching lab metric and its diagnostics: a poor field LCP points at the LCP element and server response time audits.
- Large opportunities, such as properly sized images, unused JavaScript and render-blocking resources, which estimate time saved.
- Third-party scripts in the diagnostics. Tag managers, chat widgets and analytics are frequent causes of high Total Blocking Time. Ignore audits with tiny estimated savings until the big ones are done.
Common confusions
- A score of 100 does not guarantee passing field data, and a score of 60 can still pass.
- No field data means not enough Chrome traffic yet, not a broken site.
- INP has no lab equivalent. Total Blocking Time is the closest lab hint.
- Testing the homepage tells you little about your product or article templates. Test each template.
What a scan can and cannot tell you
WebAuditOS measures LCP, a load-window layout-shift sum, Total Blocking Time and First Contentful Paint on sampled pages, plus server response time on fetched pages. Its CLS aggregation and TBT observation window differ from Lighthouse, so the values are not directly interchangeable.
It cannot show field data from real users, and like any lab test it measures one load from one location. Use PageSpeed Insights or Search Console's Core Web Vitals report for the real-user picture.
One slow template can affect hundreds of URLs. Testing pages one at a time in PageSpeed Insights rarely reveals that.
Short answers
Why does my score change every run? Network, server load and third-party scripts vary. Look at the range.
Does a low score hurt SEO? Google uses field Core Web Vitals, not the lab score. A low score is a symptom worth investigating.
What is a good PageSpeed score? 90 or above, but passing field data matters more.
Why is there no field data? The page or site has too little Chrome traffic for the report.
In the product
The checks this maps to
Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.
- perf.cwv.lcp - Largest Contentful Paint under 2.5 s
- perf.cwv.cls - Cumulative Layout Shift under 0.1
- perf.cwv.tbt - Total Blocking Time under 200 ms
- perf.cwv.fcp - First Contentful Paint under 1.8 s
- perf.ttfb - Server responds quickly (TTFB)
Read next
Performance
What is Largest Contentful Paint, and how do you improve it?
LCP measures when the main content of a page appears. What counts as good, what usually makes it slow, and the fixes that move the number in practice.
Performance
Core Web Vitals: what actually moves LCP, INP and CLS
The three metrics Google ranks on, what makes each one bad in practice, and why a lab tool can tell you about two of them but never about the third.