How to Read a Google PageSpeed Insights Report

What the score measures

The 0-100 score is a weighted composite built from a single simulated visit: Lighthouse loading the page on a modeled mid-tier phone over a throttled connection, once. In the current scoring model, Total Blocking Time carries 30% of the weight, Largest Contentful Paint and Cumulative Layout Shift 25% each, and First Contentful Paint and Speed Index 10% each. It's one test under fixed conditions. Google doesn't use the score itself for ranking.

That single-run design is also why the score can shift a few points between two checks of the same URL a minute apart, since server response time varies from request to request, a simulated run has some built-in variance of its own, and nothing about the page needs to change for either to happen. Small swings are noise.

Lab data versus field data

The report is two separate sections in one interface. Field data, at the top when there's enough of it, comes from the Chrome UX Report: real Chrome users who loaded that page over the previous 28 days. Lab data, below it, is the single simulated Lighthouse run.

The Core Web Vitals assessment uses field data. A page passes when the 75th percentile of LCP, INP and CLS are all in the good range, meaning at least three in four real visits met each threshold. Lab data exists to help you find and fix problems, and it can't pass or fail you.

A low-traffic page often has no field data of its own, because the Chrome UX Report needs enough real visits before it publishes a number. In that case PageSpeed Insights falls back to data for the whole origin, meaning all pages on the site, and if the origin is too quiet as well, it shows no field data at all. For a quiet page, the lab test is what you can act on.

When lab data and field data disagree

Sometimes the lab score for a page looks fine and the field data for that same page looks worse, or the reverse. Both readings can be accurate at the same time, because they're measuring different things.

Field data covers a rolling 28-day window. A fix you shipped last week hasn't worked its way through the average yet. It also reflects real visitors on real devices and real networks, which cover a far wider range of hardware than the single mid-tier phone Lighthouse simulates, including older phones on slower connections that never show up in a lab test at all. A returning visitor with your CSS and fonts already cached will post a faster real-world experience than the lab run, which always starts cold. Neither number is wrong. The lab score is a controlled snapshot, the field data is a messy average of everyone who showed up, and for a few weeks after any change the two can move independently.

Mobile versus desktop: two separate reports

Every URL gets two reports, mobile and desktop. They rarely agree. The mobile report throttles both the network and the simulated processor to approximate a mid-range phone on an ordinary mobile connection, which is a much harsher environment than the desktop report's near-unthrottled connection and full-power CPU. A site that scores in the 90s on desktop can land in the 40s on mobile for the identical page, and that gap reflects two different experiences of the same page rather than an inconsistent tool.

Google indexes the mobile version of pages, a practice called mobile-first indexing that it finished rolling out in 2023. If you only glance at the desktop score because it looks better, you're reading the version of your site that matters less for search. Read mobile first.

The three Core Web Vitals

Largest Contentful Paint measures how long the biggest visible element, usually a hero image or a large heading, takes to render. Good is 2.5 seconds or less, and the usual culprit is an oversized, uncompressed image or a font that blocks rendering while it loads.

Interaction to Next Paint measures how quickly the page responds after a click, tap or keypress, and good is 200 milliseconds or less. It replaced First Input Delay as a Core Web Vital in March 2024. Heavy JavaScript is the typical cause.

Cumulative Layout Shift tracks how much visible content jumps around while the page loads, and good is 0.1 or less. The cause is usually an image, an ad slot, or an embedded widget rendering without a reserved size, so the surrounding content jumps once it finally loads in.

Total Blocking Time: the number driving the score behind the scenes

INP is the responsiveness metric in the Core Web Vitals assessment, while the lab score leans heavily on a related number: Total Blocking Time. TBT adds up every stretch of main-thread work longer than 50 milliseconds between when the page starts painting and when it's considered interactive, then sums the excess over that threshold across the whole load.

A page can post a fine-looking Largest Contentful Paint and still land a mediocre lab score. TBT is usually why. A single script that ties up the main thread for 400 milliseconds contributes 350 milliseconds of blocking time on its own, and a handful of those add up fast. TBT is a lab-only estimate of the problem INP measures in the field, which is whether the main thread is free when someone tries to interact. A high TBT reading is an early warning.

How Lighthouse simulates a slow connection

Both the mobile and desktop lab reports come from a single automated pass of Lighthouse, Google's open-source auditing tool, and that pass deliberately throttles your machine's true speed. The goal is a consistent, comparable baseline instead of a number that depends on whatever office wifi or laptop happened to load the page that day.

Network throttling adds latency and caps bandwidth to approximate a real mobile connection rather than a fast broadband line, while CPU throttling slows the simulated processor to a fraction of what a modern laptop can do, closer to the budget phones plenty of mobile visitors carry. That's why a page that feels instant on your own machine can still post a mediocre lab score.

It's also why comparing scores across two different tools rarely helps. A different throttling profile, a different simulated device, or a different Lighthouse version can each move the number a few points on their own, before your page changes at all. The diagnostics beneath the score tend to be more stable across runs than the headline number, which is another reason to spend your attention there instead of chasing the exact score.

Insights and diagnostics: reading the list under the score

Lighthouse 13, released in October 2025, replaced the old Opportunities section with Insights, the same analysis Chrome DevTools uses. So older guides talk about "eliminate render-blocking resources" and "properly size images", while your report now says Render blocking requests and Improve image delivery. Same problems, new names.

Insights usually carry an estimated saving. Work through them by that saving rather than by how alarming the name sounds, because a plain item like Improve image delivery often saves more time, for less effort, than one that sounds serious.

Diagnostics point at real issues the tool can't put a clean number on. A diagnostic with no listed saving can matter more than an insight showing a small one, since the insight's figure covers one narrow fix, so don't read a missing number as a minor issue.

A PageSpeed report only covers one slice of a technical audit. If you're stitching together a full picture from free tools, free backlink checkers cover the link side of it, and it's worth knowing why a chat model can't do this job for you before trusting one to fill the gaps a speed report leaves open. If you'd rather have all of it consolidated into one instant scorecard instead of checking each piece separately, the free SEO report tool grades speed alongside the rest of a site's signals in a single pass. More free, no-signup ways to check a site's health live in the Free Tool archive, and if you'd rather have this done for you, the Website Optimizer Pack covers the same ground as a fixed-scope engagement.

A worked example: fixing a real diagnostic

Say a report flags Improve image delivery as the top insight, with an estimated saving of a couple of seconds. Opening it shows specific image URLs with the size the browser displays each image at and the size of the file being sent. A hero image displayed at 800 pixels wide but shipped as a 3,000-pixel original is a common finding. It's an easy one to fix. Resize the source file to match the largest size it's ever displayed at across breakpoints, then compress it before uploading again.

After making that change, check more than the headline score. See whether Largest Contentful Paint dropped in the lab report, since that's the metric an oversized hero image usually drags down directly. If LCP improves but the overall score barely moves, that's fine, because other items are competing for the same points and one fix rarely closes the gap on its own.

Repeat that for every item on the list: open it, read what it points at rather than only its label, fix the specific file or script named, and confirm the relevant metric moved before assuming the fix worked. Working through a report this way, one verified fix at a time, is slower than skimming the score and guessing, but it's the difference between a page that's faster and one that looks faster on a single lucky run.

A worked example: chasing a stubborn INP score

Say the lab report and the field data both agree that INP is the problem, and image sizing and font loading are already fixed. The next place to look is usually third-party scripts: a chat widget, an ad tag, an analytics snippet, a personalization tool. Each one loads its own JavaScript. All of it runs on the same main thread as your code.

Open the report's main-thread work diagnostic before assuming the problem is your own code. Third-party scripts often account for a large share of what's listed. A tag manager loading four other tags, a chat widget polling in the background, a personalization script running on every interaction: any one of these can single-handedly wreck an otherwise clean INP number.

You don't have to remove the script. Loading it after the page becomes interactive, rather than blocking on it during initial load, moves the same work to a point where a visitor is less likely to be mid-interaction when it runs. That's a defer-or-lazy-load problem more often than a rewrite-the-code problem, and it's worth checking before assuming a slow INP score means a costly rebuild.

A simple order to work through fixes

Start with images. They're usually the largest contributor to a slow LCP, missing width and height attributes are a common cause of layout shift, and the fix is cheap: resize images to their display dimensions, set their dimensions in the HTML and compress them before upload.

From there, look at unused or blocking JavaScript, since that's the more common source of a poor INP score. Then fonts. Whatever remains after those three areas is usually smaller and specific to one page.

Reading a PageSpeed Insights report this way, top to bottom by impact instead of by which line sounds the most technical, turns a score you can't act on into a list you can. After each fix, rerun the test rather than trusting memory of the old number, since a single run carries the variance mentioned earlier and one clean pass doesn't prove a fix worked.