PageSpeed Insights: how to read the report and what to fix first

PageSpeed Insights is Google's free tool that measures a page's speed from two sources: real-user data from Chrome over the last 28 days, and a lab test run with Lighthouse. The real-user data tells you whether you pass Core Web Vitals; the lab test, with its 0 to 100 score, helps you find what to fix.

To check it on your own site: SEO audit

Speed is one part of SEO, and PageSpeed Insights is the most direct way to measure it. The trouble is that its report puts data with different sources, periods and purposes on a single screen. This guide walks through it from top to bottom, in the order it is best read.

What does PageSpeed Insights measure?

PageSpeed Insights (PSI) is a Google service that reports on the user experience of a page on mobile and desktop, and suggests how to improve it1. When you enter a URL, it returns two blocks:

Below that, Lighthouse adds three more categories: accessibility, best practices and SEO. They are useful, but they have nothing to do with speed or Core Web Vitals.

How to read the real-user data

This is the top block, and the one that matters for decisions. It shows the three Core Web Vitals (LCP, INP and CLS) and two supporting metrics: FCP (First Contentful Paint, when the first content is painted) and TTFB (Time to First Byte, when the server starts responding)1. Each metric shows its 75th-percentile value and a bar splitting visits into good, needs improvement and poor.

Above them is the verdict: the Core Web Vitals assessment passes if the 75th percentile of LCP, INP and CLS is "good". If there is not enough INP data, good LCP and CLS are enough1. The thresholds for each metric and how to diagnose them are in the guide to Core Web Vitals.

Look at the two tabs, one for the URL and one for the origin:

• The URL tab is data for that exact page. It only appears if the page has enough visits.
• The origin tab aggregates every page on the domain. If the URL has no data of its own, PSI falls back to the origin; if there is no origin data either, the block is empty1.

This explains a common puzzle: two different pages with identical field data. It is not a bug; both are showing the origin. And if the block is empty, CrUX does not have enough visits for your site, because it only includes public pages with a minimum number of visitors that Google does not disclose2.

How to read the lab diagnostics

The bottom block is a simulated page load. On mobile, Lighthouse emulates a mid-tier device on a throttled mobile network; on desktop, a computer with a wired connection. The test runs from Google data centres in North America, Europe or Asia1.

It shows five lab metrics: FCP, LCP, TBT (Total Blocking Time, how long the main thread was blocked), CLS and Speed Index (how quickly the screen fills visually). INP is missing because nobody clicks during a simulated load; TBT is the proxy Lighthouse uses3.

It is normal for lab LCP and field LCP to differ. Web.dev puts it down to caching, each user's real device and network, personalised content and pages the browser restores instantly when you go back. Its advice: prioritise using field data and use the lab to find the cause4.

What does the performance score mean?

The performance score is a weighted average of five lab metrics, converted to a scale of 0 to 1005. Each metric is scored according to where it falls against real websites in the HTTP Archive, then weighted:

These are the weights Lighthouse has published since version 105; Lighthouse 13 made no changes to performance scoring6. The colours are 90 to 100 good, 50 to 89 needs improvement and 0 to 49 poor1.

Two practical conclusions. First, almost a third of the score depends on TBT, which is not a Core Web Vital. Second, the score and the Core Web Vitals assessment are different things. You can score 60 and pass on field data, or score 95 and fail. Google points out that good results in Search Console's report or in third-party tools do not guarantee a top ranking7.

Why does the score change every time?

Because every lab test is a fresh page load, in conditions that are never identical. PSI cites local network availability, client hardware availability and client resource contention1. Lighthouse adds causes that depend on your page: A/B tests, ads that change on every load and different traffic routing5.

A difference of a few points between two runs does not mean anything has changed. To compare before and after a fix, run the test several times and take the median: according to Lighthouse's documentation, the median of five runs is twice as stable as a single run8.

Insights and diagnostics: what they are called today

Lighthouse reorganised its performance recommendations in 2025. The old audits ("opportunities") were consolidated into insights, the same ones shown in the Performance panel in Chrome DevTools9. Lighthouse 13, released on 10 October 2025, removed the old audits from the report, and Chrome announced it for PageSpeed Insights within the following week6. If a guide tells you to look for "Serve images in next-gen formats" or "Eliminate render-blocking resources", it was written for an earlier version.

Insights do not add or subtract points on their own: Lighthouse 13 only changed audits that are not scored6. What they do is explain why a metric is bad. These are the ones you will see most often, named as Chrome documents them10:

Below the insights sit the diagnostics: audits that did not become insights, such as main-thread work or unused JavaScript. Use the filter above the list to show only the audits relevant to the metric that is failing: the report narrows to what affects it.

Mobile or desktop: which should you look at?

Start with mobile. Google uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking11. On top of that, the mobile lab test is tougher by design, with a throttled device and network1.

But do not skip desktop: field data is assessed separately for each device type, and Search Console can mark a URL as good on mobile and needing improvement on desktop12. Read each tab on its own.

What should you fix first?

This order stops you working on things that will not move anything:

1. Check the field verdict on mobile. If you pass, speed is not your bottleneck; do not chase a lab score of 100.
2. If you fail, find the failing metric in the real-user block: LCP, INP or CLS.
3. Filter the audits by that metric and start with the insight that attributes the most time or the most layout shift.
4. Prioritise template fixes. Removing lazy loading from the main image or adding dimensions to images is done once and reaches every page that uses the template. The image side is covered in the guide to image SEO.
5. Check in the lab using the median of several runs, and confirm in the field after 28 days.

The other three Lighthouse categories (accessibility, best practices, SEO) are reviewed separately, as part of a full SEO audit.

PageSpeed Insights and SmoothSeen

Declaration of interest: this blog belongs to SmoothSeen, a web audit tool that measures visibility in search engines and AI assistants. SmoothSeen takes its speed data from PageSpeed Insights, both the real-user data and the lab data. What you see in its report is therefore the same as what you would see in PageSpeed, the only difference being the normal variation between two lab runs. It combines that with the rest of its search visibility checks, compares it with your competitors and turns it into a prioritised action plan.

Frequently asked questions

Will a low PageSpeed Insights score cost me rankings?

Not directly. The 0 to 100 score comes from a lab test; what Google says its ranking systems use are Core Web Vitals, which are assessed with real-user data. Google also stresses that it always seeks to show the most relevant content, even when the page experience is sub-par. A low score does, however, point to problems your visitors are probably noticing.

Why does PageSpeed Insights show no real-user data for my site?

Because CrUX only includes public, indexable pages with a minimum number of visitors, a figure Google does not disclose, and it only collects data from Chrome on desktop and Android. If the URL falls short, PSI shows origin data; if the domain falls short too, you will only see the lab test. It is common for new sites and sites with little traffic.

Which matters more, mobile or desktop?

Mobile, in almost every case. Google indexes and ranks using the mobile version of your site, and the mobile lab test simulates a slower device and network, so it uncovers problems that desktop hides. Check both, but fix what fails on mobile first, unless your analytics show that nearly all your visits come from desktop.

Where have the "opportunities" I used to see gone?

Since Lighthouse 13, released in October 2025, the old opportunities and many diagnostics have been consolidated into insights, such as Improve image delivery or Render-blocking requests. They are the same insights shown in Chrome's Performance panel. The way the score is calculated did not change: only the way the recommendations are presented.

What to do next

Run your home page through PageSpeed Insights on mobile, note whether you pass on real-user data and, if not, which metric fails. Filter the audits by that metric and fix what can be solved in the template first. To see how speed fits with everything else, carry on with the guide to what SEO is.