Reading a Lighthouse report without panic

A printed website performance report on a wooden desk, its front page showing four gauge dials, one amber and three green, with tortoiseshell reading glasses and a pencil resting on the fanned pages and a closed laptop and cup of coffee behind.

A speed report just landed in your inbox: four colored dials and a long list of findings with names like “Eliminate render-blocking resources.” Most owners look at the color and stop. The color is the least useful part of the page, and the parts worth reading sit further down, once you know how much to trust each one.

What one run actually is

The report almost certainly came from Lighthouse, an auditing tool built into Chrome; Google’s PageSpeed Insights page runs it too. A run is one load of one page under deliberately rough conditions. For the mobile test, Lighthouse pretends to be a mid-range phone with its processor slowed to a quarter of real speed, on a connection capped below two megabits, which is why a page that feels instant on your own phone can come back with a number that ruins your morning. It’s a stress test.

It is also lab data: a simulation, not a recording of your visitors. Google’s search assessment rests on field data from real visitors, and we’ve written about that distinction separately.

Why two scores disagree

While writing this post we ran Lighthouse against our own home page twice, a few minutes apart. The mobile test said 95. The desktop test said 100. Nothing about the page changed in between; the desktop test simply skips the slow-phone simulation, so the same headline that took 2.1 seconds to draw on the pretend phone drew in 0.6 on the pretend desktop.

So when two people wave two different scores for the same site, check which test each of them ran before anyone argues. Then read the mobile one, since it’s the stricter of the two.

Runs also disagree with themselves. The simulation carries noise, and the same untouched page can drift a few points between mornings, so a 93 where last week said 96 is the same site. A score in the 60s after a 90 last month means something actually changed.

Four scores, and only one is a blend

The performance dial gets the screenshots, but the report carries four scores: Performance, Accessibility, Best Practices, and SEO. The last three are mostly checklists. An image has a text description or it doesn’t; the page has a title or it doesn’t. Failures there tend to be specific and cheap to fix, and since they affect real people and real indexing instead of a simulation, they’re usually the best value on the page.

The performance number is a weighted blend of five separate measurements, and in the current version more than half the weight sits on two of them: how long the page keeps the phone’s processor too busy to respond, and how long the biggest visible element takes to draw. Two pages can land on the same score for completely different reasons. The metrics underneath the dial are what tell a developer where to look.

What the findings list knows

Below the scores sits the list everyone dreads, each line with an estimated saving beside it. What the tooltips never quite say is that Lighthouse observes what happened during the load and then guesses at why, and the guess is only sometimes right.

Our own report is a tidy example. That mobile 95 came down to a single finding: the layout shifted by 0.128 while the page loaded, and the report blamed our logo, flagging it as an unsized image. The logo ships with its dimensions declared; it wasn’t the problem. The real cause was a script that swapped the navigation into its mobile-menu form after the page had already drawn, nudging everything below it, and once we moved that one script the next run measured the shift at zero. The report had seen the symptom perfectly and named the wrong suspect.

None of that makes the list worthless. It makes each line a lead for a person to check before anyone acts on it. The estimated savings come from the same guesswork, and a few of the stock suggestions, deferring scripts among them, will quietly break a page.

What to do with the report

Run it on the pages that earn the money. Scores are per page, and the home page is usually the most polished thing a business owns. The landing page your ads point at is carrying the forms, the scripts, and the traffic.

Run it twice before reacting. If the second run disagrees by a few points, you’ve found the noise floor and can stop watching it.

Find the failing metric before asking for a quote. A layout-shift problem is a different job from a slow server, with a different price. The single dial hides which one you have.

Hand the report off instead of working through it. The useful handoff to a developer is the page address plus which metric is red. Working down the findings list yourself is how a site ends up broken in a way nobody notices until checkout.

Where this fits

A Lighthouse report is a good smoke alarm and a bad repair manual. We audit the sites we host on a schedule, which is how our own layout shift got caught and fixed the same day, and the work lands as routine hosting and site care before a red dial ever makes the rounds.

Keep reading

  • Core Web Vitals, explained for owners

    What LCP, INP, and CLS actually measure, why the score out of 100 is not your Core Web Vitals, and which parts of a performance report are worth acting on.

  • How uptime monitoring works

    What a monitor actually checks, why detection is never instant, what those uptime percentages come to in minutes, and the failures a basic check never sees.

Somebody sent you a score?

Send over your address and we will separate the real findings from the guesswork, with a straight answer on what fixing them would cost.