Skip to content
Booking projects for spring 2027
hello@valden.studio
Manchester, UK
Thursday, 16:42
Start a project
All articlesBuild · 4 min read

Why your Lighthouse score is lying to you

A perfect 100 on your laptop says very little about how the site feels on a mid-range phone on a train. What we measure instead, and the fixes that actually move it.

Niamh GallagherLead developer, Webflow and Framer

Clients often send us a screenshot of a green 100 from Lighthouse and ask why their site still feels slow. Others send a red 42 and ask whether the site is broken. In both cases, the score is answering a different question from the one they are asking.

What Lighthouse actually measures

Lighthouse loads a single page once, on a simulated mid-range phone with a throttled connection, and reports how that one load went. It is a lab test: useful, repeatable and good at catching regressions. It is not a measure of what your customers experience.

The score itself is a weighted blend of five lab metrics, and the weights change between versions. A site that scored 92 last year can score 84 today without a single line of its code changing.

Your customers arrive on hundreds of different devices, over patchy mobile data, with browser extensions, cookie banners and cached files that the lab test never sees. Some of them land on the home page. Most land deep inside the site, from search or an advert.

Three ways the score misleads

It tests one page. The home page is rarely the slowest page on a site. Product pages with large galleries, articles with embedded videos and location pages with maps are usually worse, and they are the ones people arrive on.

It ignores what happens after load. Interaction to Next Paint, the Core Web Vital that replaced First Input Delay in 2024, measures how quickly the page responds when someone taps a filter or opens a menu. A page can load beautifully and then freeze for half a second every time a visitor touches it. A single lab run barely sees this.

It varies more than people realise. Run the same test five times and the score will often move by ten points. Treat any single number as a range, not a verdict.

“A fast site is one that feels fast to the person on the 7:42 from Stockport, not one that scores well on the developer’s laptop.”

Niamh Gallagher, Lead developer, Webflow and Framer

What we measure instead

We still run Lighthouse on every build, because it catches mistakes early. But the numbers we report to clients come from real visitors.

  • Field data from the Chrome User Experience Report, through PageSpeed Insights or Search Console, which shows how real Chrome users experienced your pages over the last 28 days.
  • Real user monitoring on the site itself, so we can see the slowest templates, devices and countries rather than an average.
  • The 75th percentile, not the median. Google judges Core Web Vitals at the 75th percentile, and so should you: it is the experience of your less fortunate visitors.
  • Template-level results, so we know whether product pages, articles or landing pages are the problem.

The fixes that usually matter

On most of the sites we inherit, the same handful of problems account for most of the slowness. None of them is glamorous.

  1. Hero images that are too large, in the wrong format, or lazy-loaded when they should load first.
  2. Third-party scripts: chat widgets, heatmaps and tag managers carrying tags nobody remembers adding. We audit them all and delay whatever can wait.
  3. Fonts loaded from several sources with no fallback sizing, which makes text jump as it loads.
  4. Heavy JavaScript running on every interaction, often from a slider or animation library loaded on every page.
  5. Layout shifts from cookie banners and adverts that push content down after it appears.

Fixing those five usually does more for real users than any amount of score-chasing. On a recent store rebuild, removing two unused tracking tags and resizing the product gallery improved mobile Largest Contentful Paint at the 75th percentile by over a second, while the Lighthouse score barely moved.

How to read your own results

If you only have five minutes, open PageSpeed Insights and enter one of your busiest product or service pages rather than the home page. Look at the top section, which reports what real users experienced. If your Core Web Vitals assessment passed, you are in good shape, whatever the lab score below it says. If it failed, the metric in red tells you where to start.

If a page does not have enough traffic for field data, the report will say so. In that case, look at the result for the whole site instead, or at your busiest templates as a group rather than page by page.

And if the score on your laptop is 100 but your customers still complain, believe your customers.

Planning a new site?Start with a call.

Thirty minutes is enough for us to tell you which platform suits your team, roughly what it will cost and how long it will take. You get a written recommendation either way.

Start a projectBooking projects for spring 2027
Built by Visuvate