Why your site scores 98 on your laptop and 40 on your customer’s phone

Somebody sends you a screenshot with a green 98 on it and the conversation is over. That is the problem with performance scores: they are persuasive out of all proportion to what they actually tell you.

I want to walk through a real audit of my own site, including the parts where the tool was wrong and the part where I was wrong, because reading these reports properly is a skill and almost nobody is taught it.

The scores I got, and what they meant

Running an audit on the local build gave me this:

Category	Score
Accessibility	100
Best Practices	78
SEO	66

Two of those look like failures. Neither is.

Best Practices lost points on exactly two audits: is-on-https and redirects-http. The site was running on a local development server over plain HTTP. There is no possible way to pass an HTTPS check on a machine that is not serving HTTPS.

SEO lost points on is-crawlable, because the site had “discourage search engines” switched on — as every unfinished site should.

Three failures, all of them artefacts of where the test was run rather than properties of the site. If I had panicked and started “fixing” them, I would have been changing a build that had nothing wrong with it.

This is the first rule of reading an audit: separate the findings that are about your site from the findings that are about your test environment. A surprising number of agency performance reports are padded with the second kind, because it makes the list longer.

The number that actually matters

The category score is a weighted average of a dozen audits, and averages hide things. What you want are the field metrics — the ones Google actually uses, and the ones that correspond to something a human experiences.

There are three. Largest Contentful Paint: how long until the main thing on screen has appeared. Interaction to Next Paint: how long between a tap and something happening. Cumulative Layout Shift: how much the page moves around while it is loading.

On a simulated slow 4G connection with the processor throttled to a quarter of desktop speed, my front page produced an LCP of 997 milliseconds and a CLS of 0.00. The thresholds are 2,500 ms and 0.1. That is a real result, because it was measured under conditions that resemble a real phone.

Measured on my laptop over local network with no throttling, the same page would produce numbers so good they would be meaningless.

The gap between your laptop and their phone

This is where most of the disagreement about site speed comes from. Two people look at the same site and one says it is fast and the other says it crawls, and both are telling the truth about what they saw.

The difference is roughly this: a mid-range Android has perhaps a quarter of the processing power of a development laptop, on a connection with a tenth of the bandwidth and a hundred times the latency, often with a battery-saving mode throttling it further. JavaScript that parses in 80 milliseconds on your machine takes 400 on theirs. That is not a rounding error, it is the entire experience.

So when you run an audit, throttle it. Mobile emulation, slow 4G, 4× CPU slowdown. The number will be worse and it will be true. A performance report run without throttling is not a report, it is a compliment.

The measurement that was lying to me

Here is the part I found genuinely instructive.

I was testing layout stability while interacting with the page — opening an accordion in the FAQ section, which by definition pushes content down. The trace came back with a cumulative layout shift of 0.28, nearly three times the acceptable threshold. My first instinct was to go and rebuild the accordion so it reserved space.

Before doing that, I looked at the individual shift records rather than the total. Every one of them carried a flag: hadRecentInput: false.

That flag is how the browser distinguishes between a page that moves on its own and a page that moves because somebody asked it to. Content shifting down after you click “expand” is not a defect — it is the feature. Core Web Vitals excludes any shift that happens within half a second of a user interaction, precisely so that working interfaces are not punished.

So why was the flag false? Because I had triggered the clicks programmatically, from a script. A synthetic click is not trusted input. The browser saw content jumping with no user behind it, which is exactly the pattern it is designed to catch.

I repeated the test with a real click driven through the browser’s own input pipeline. Same accordion, same movement, and this time hadRecentInput: true. Counted CLS: zero.

The lesson is not “CLS is unreliable”. The lesson is that a measurement is only as good as your understanding of what it measures. Had I trusted the first number, I would have spent a day rebuilding a component that was working correctly, and made it worse in the process.

What I now check, in order

1. Field metrics before category scores. LCP, INP, CLS, measured under throttling. The 0–100 score is a summary for stakeholders, not a diagnostic.
2. Which audits failed, individually. Not how many. Three failures caused by testing over HTTP are not three problems.
3. What the LCP element actually is. Usually a hero image or a headline. If it is something unexpected — a stray banner, a late-loading web font — that is the real finding.
4. Whether layout shifts carry recent input. Shifts caused by the user are excluded, and confusing the two sends you chasing a phantom.
5. Transfer sizes. A score cannot tell you that compression is switched off at the server. Bytes on the wire can.

What to do with the report your agency sent you

Ask three questions.

Where was this run? If it was run on a staging server over HTTP, or on somebody’s laptop, several of the findings are about the test.

Was it throttled? If not, the numbers describe an experience none of your customers are having.

Which findings would change what a visitor sees? This is the only question that matters commercially. Some audits are genuinely about user experience. Others are hygiene items that will never be perceived by anyone. Both belong in a report; only one belongs at the top of it.

A 98 that came from an unthrottled test on a fast machine tells you almost nothing. An 85 with a sub-second LCP on emulated slow 4G tells you the site works. I would take the second every time, and so would your customer, who has never seen your score and never will.