Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

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

By Michal Měřínský. Audit methodology.

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.