How to read a website speed test without panicking

A client sent me a screenshot last month with no message attached. Just the top of a PageSpeed Insights report, a big red 38 in a circle, and then a second text a minute later: "is this bad??"

It's a fair question, and the honest answer is that I couldn't tell from the screenshot. The number she'd photographed is the part of the report I read last, if I read it at all. The bit that would have told me whether her site was actually losing customers was further down, and it turned out to be mostly green.

That gap, between the number the tool shouts at you and the numbers that matter, is what this post is about. It's not about why sites are slow or how to fix them. I've written that one already. This is the step before it: sitting in front of a speed test result and working out what it's telling you.

The report is two different tests stapled together

Open PageSpeed Insights, put in your address, and you get one page that looks like one result. It isn't. Google's own description of the tool says it provides both lab and field data, and those two things are measured in completely different ways.

Field data is what real people using Chrome experienced on your site over the previous 28 days. Google collects it from actual visits through something called the Chrome User Experience Report, which everyone shortens to CrUX. It sits near the top of the report under a heading about what your real users are experiencing. This is the part that reflects the customer in the car park on patchy 4G, because she's in it.

Lab data is a simulation. A tool called Lighthouse loads your page once, on a slowed-down virtual phone over a throttled connection, and reports what happened. That single run produces the big 0 to 100 score. It's a diagnostic. It's useful for finding out why something is slow, and it's the wrong number to use for deciding whether something is slow, because it's one visit under conditions Google chose, not the spread of visits your customers actually had.

Here's the catch for small sites: the field section only appears if enough Chrome users have visited to make the data meaningful. Google doesn't publish a visitor count, it says a page needs sufficient data to be included, and that a page that's new or has too few real-user samples won't have it. When that happens the tool falls back to figures for the whole site rather than the page you typed in, and if the whole site is thin too, you get the lab score and nothing else. Plenty of tradie and local-service sites land there. If you can't see a "real users" section on your report, you're looking at a simulation, and you should hold the number more loosely.

The three numbers Google actually grades

Underneath both halves are the same three measurements, which Google calls Core Web Vitals. Everything else on the report is either an input to these three or a suggestion for improving them.

Largest Contentful Paint (LCP) is how long until the biggest thing on the screen, usually your hero photo or headline, has appeared. Google's guidance is that a good LCP is 2.5 seconds or less, and anything over 4 seconds is poor. This is the one that maps to a visitor's gut feeling of "is this loading or not".

Interaction to Next Paint (INP) is how long the page takes to visibly respond after someone taps something. The threshold is 200 milliseconds or less for good, and over 500 milliseconds for poor. On a small business site this mostly shows up as a menu button that does nothing for a beat after you tap it, or a form that seems to ignore the first press.

Cumulative Layout Shift (CLS) measures how much the page jumps around while it loads. It's a score, not a time. Good is 0.1 or less. This is the one where you go to tap "Call now" and an ad or a late-loading image shoves the button down and you tap something else instead.

The pass mark for all three is the same and it's worth knowing exactly, because it's more forgiving than people assume. Google measures at the 75th percentile of page loads, split by mobile and desktop. In plain terms: if three out of four of your real visitors got a good experience, you pass. The slowest quarter of visits, the ones on ancient phones and terrible reception, don't drag you under on their own.

What is a good website speed test score?

A website passes Google's speed assessment when real visits show a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, each measured at the 75th percentile over the previous 28 days. The 0 to 100 score at the top of a PageSpeed report is not that assessment.

The score is a lab number from one simulated load. A site can score 45 in the lab and pass all three field measurements, which is exactly what my client's site did; her real visitors were mostly on decent phones in the suburbs, not the throttled device Lighthouse pretends to be. The reverse happens too, and it's worse: a site can score in the 90s on a marketing page nobody visits while the service page that actually earns the money fails LCP for real people. Read the field data first, on the pages that get the traffic, and treat the score as a hint about where to look next.

What to ignore

Most of the report, honestly. Some specifics.

The desktop tab. Run the mobile test and read that. Desktop is where your site looks best and where the fewest customers are.

A single lab run. Lighthouse results move between runs because the simulated network and device aren't perfectly stable and because your server, your hosting and any third-party scripts are having a different moment each time. If you run it three times and get 38, 52 and 44, none of those is the real number. That spread is the real number, and it's telling you the lab test is noisy for your site.

The long list of opportunities with "estimated savings". Each row shows a possible time saving in seconds if you did that one thing. They don't add up the way the layout implies, some of them aren't possible on your platform, and a few of them (a third-party chat widget, a fonts service) are trade-offs you already made on purpose. Use the list to understand which of the three vitals is failing and roughly why. Don't use it as a to-do list.

Anyone else's score. A competitor scoring 90 doesn't mean their site is faster for your customers, it means their homepage loaded fast on a simulated phone once. If you want to compare, compare the field data, and only if both sites have it.

The temptation to chase the number. I've watched people strip a site of its photos to get a lab score from 60 to 95, on a page whose real visitors were already passing. They made the page worse for the customer to improve a diagnostic reading. The score is not the customer.

What to actually do with the result

Run the mobile test on the three pages that get the most traffic, not just the homepage. For a trades or local-service business that's usually the homepage, the main service page and the contact page. If the site has field data, write down which of the three vitals is red or orange on each page. If it doesn't, run the lab test a few times and note which vital is consistently the worst rather than what the score says.

That gives you a short, specific sentence like "the service page fails LCP on mobile", which is something a developer can act on in an hour. "Our PageSpeed is 38" is not; it's an invitation to argue about the tool. From there, the causes are almost always the same short list, and that post walks through them in the order they usually do damage.

If you'd rather someone else read the report, the free website audit crawls every page rather than the one you paste in, and comes back as a ranked list rather than a score. Either way, the thing to do this week is small: run the mobile test on your service page, find the field section or confirm it isn't there, and write down which vital is failing. That one line is worth more than the number at the top.