Your Lighthouse score is probably lying to you.
The same page, the same afternoon, the same settings. Fifty-four out of a hundred, then ninety-nine. The only thing that changed was what else the measuring laptop happened to be doing — and we published the fifty-four before we worked that out.
A correction. An earlier version of this article said our home page scored 54 for performance and blamed four specific things. The 54 was a bad measurement, and three of the four were not even on the page. What follows is the replacement — and the story of how the number went wrong turns out to be more useful than the article we meant to write.
The two numbers
On the afternoon of 9 September 2026 we ran Lighthouse against our own home page on the mobile profile. It scored 54, with 2,900 milliseconds of total blocking time. That is a bad result, and we wrote it up.
A few hours later, checking something else, we ran it again. Three times.
| Run | Score | Blocking time | First paint | Speed index |
|---|---|---|---|---|
| The one we published | 54 | 2,900 ms | 2.2 s | 4.2 s |
| Later, run 1 | 99 | 0 ms | 1.3 s | 2.6 s |
| Later, run 2 | 100 | 10 ms | 1.3 s | 2.6 s |
| Later, run 3 | 98 | 20 ms | 1.6 s | 3.1 s |
Same URL, same day, same Lighthouse version, same mobile profile, same cpuSlowdownMultiplier: 4. Nothing was deployed in between. A forty-five point swing, and a blocking time that moved by a factor of well over a hundred.
What was actually different
The first run was taken while the same laptop was driving a browser test suite across thirty-odd pages. The later ones were taken while it was doing nothing else.
This is the part that is not obvious, and it is why the mistake is worth writing down. Lighthouse does not simulate a slow phone. It slows down the machine you already have. The mobile profile applies a 4× CPU multiplier on top of whatever your computer is currently managing. If your laptop is at ten per cent, four times that is a fair impression of a mid-range Android. If your laptop is already saturated, four times that is not a phone. It is a machine in distress, and every timing in the report is measured against it.
Blocking time suffers most, because it counts main-thread tasks longer than 50 ms — and on a contended processor, ordinary work crosses 50 ms constantly. Ours read twenty milliseconds on a quiet machine and 2,900 on a busy one.
The rule: a local Lighthouse run is only worth reading if the machine running it is otherwise idle. Not "mostly idle" — close the test suite, close the video call, close the twelve Chrome windows. Then run it three times and take the middle one.
How to get a number you can trust
1. Use PageSpeed Insights instead
PageSpeed Insights runs the same audit on Google's hardware rather than yours. It removes this entire class of problem and costs nothing. If you only ever do one thing, do that one.
2. Read the field data, not the lab data
Above the score, a PageSpeed report often carries a section drawn from the Chrome User Experience Report. That is not a simulation. It is what actually happened to real people, on real phones, on real connections, over the last month.
The score underneath is a lab result: one synthetic load, one simulated device, one moment. It is good for finding what is slow and close to worthless as a measure of whether your site is slow. When the two disagree, the field data is right.
3. Compare against yourself, not against 100
Chasing the last few points is usually a waste. The gap between 90 and 100 is often smaller, in human terms, than the gap between one visitor's phone and another's. What is worth watching is direction: is this page slower than it was last month, and what changed.
What the page actually costs
Measured properly, here is our home page with one of the sites we built for contrast:
| Page | Mobile | Desktop | Blocking time |
|---|---|---|---|
| getweblabs.uk home page | 98 – 100 | 100 | 0 – 20 ms |
| Nord Dental, built by us | 100 | 100 | 0 ms |
The home page loads three scripts and no framework. The most expensive thing on it is a particle canvas in the hero, and even that costs almost nothing measurable. Layout shift is zero, because every image has its dimensions written on it.
The earlier version of this article blamed GSAP, ScrollTrigger and Lenis for the imaginary 2,900 milliseconds. Those are animation libraries, we do use them, and they are on some of the demos. None of them is on the home page at all. That is what happens when you explain a number instead of checking it.
The things that genuinely make sites slow
All of which still matters, because plenty of sites really are slow. When they are, it is almost always one of these:
- Third-party scripts. Chat widget, analytics, heat map, cookie banner, review widget, a pop-up offering 10% off. Each is small; eight of them is a second of blocking, and no single vendor is at fault.
- A theme built to be sold. It ships a slider, a portfolio grid, a booking widget and six icon sets so it demos well for every possible buyer, and loads most of them whether your page uses them or not.
- Images with no width and height. Not the file size — the missing attributes. Without them the browser leaves no room, so everything jumps when the picture lands. That is why you have tapped the wrong link on a news site.
- A server that thinks about it first. If the first byte takes 800 ms, nothing in the page wins that back.
The test that costs nothing: open your site and turn JavaScript off. If the content is still there and the links still work, your JavaScript is decoration and can be deferred. If the page is blank, the JavaScript is your site, and that is a longer conversation.
Why the mistake is still printed above
We could have replaced this quietly and said nothing. The reason not to is that on the same afternoon we took four invented client testimonials off this site, and corrected a Lighthouse claim that had been measured on one page and printed on another.
This was that same error with our own name on it: a number nobody checked, explained with confidence. Deleting it would have made the site tidier and us less worth believing.
Want your own site measured properly?
Send us the URL. We will run it on an idle machine, three times, and send the field data alongside — with nothing to buy at the end of it.
Ask for a speed check