30
17 Comments

Why your Lighthouse score lies to you sometimes

One thing surprised us while building Betterlytics, our analytics tool:

A lot of founders obsess over Lighthouse scores.

But Lighthouse doesn't measure your real users. It simulates:

  • one device

  • one network speed

  • one environment

In reality, visitors are nothing like that. They might be on:

  • a 4-year-old Android phone

  • bad 3G connections

  • an overloaded laptop CPU

  • browsers full of extensions

When we started collecting real-user Core Web Vitals, we noticed something interesting.

Some sites with a 95+ Lighthouse score were actually slow for real users.

And some sites with mediocre scores performed great in the wild.

The difference is synthetic tests vs real-user monitoring (RUM).

Synthetic tests are great for debugging. But if you want to know how your site actually feels to users, you need real visitor data.

Curious how others track performance:

Do you mostly rely on Lighthouse, or do you track real-user performance metrics too?

posted toAvatar for product Betterlytics
Betterlytics
  1. 2

    I’ve seen the same thing when testing production apps. Lighthouse looks great, but real user data sometimes tells a very different story. Are you collecting Core Web Vitals directly from the browser?

    1. 1

      Yeah, exactly! Synthetic tests and real-world data can diverge quite a bit

      We collect Core Web Vitals directly from the users' browsers, so the metrics reflect real devices, networks, and usage patterns. This tends to surface issues that Lighthouse miss, especially things like layout shifts from late-loading content or slow interactions on lower-end devices :)

      1. 1

        That makes a lot of sense. Capturing metrics directly from real users is way more valuable than relying only on synthetic tests.

        I’ve noticed things like INP and CLS issues show up much more clearly with real traffic, especially on lower-end devices or slower networks. Lighthouse often misses those edge cases.

        Are you also tying these metrics back to specific user sessions or segments (like device type or region)? That feels like where a lot of actionable insights come from.

        I’ve been working with FastAPI and analytics pipelines recently, so this is exactly the kind of problem I enjoy digging into. If you ever want another set of eyes on performance tracking or data flow, I’d be happy to help.

        You can reach me here: kevin.chisumdev@gmail.com

        1. 1

          You're spot on about INP and CLS especially. Those tend to look "fine" in Lighthouse but looks different once real users visit your site.

          Yeah, we do tie Core Web Vitals back to sessions and segment heavily (device, browser, geography, etc.). That's honestly where most of the useful insights come from, otherwise it's just aggregate numbers without much direction. Being able to pinpoint "this specific device group is struggling with interactions" makes a huge difference.

    2. 1

      This comment was deleted 5 months ago

  2. 1

    The synthetic vs RUM gap is real. We health-check our site regularly and catch issues Lighthouse misses. Curious how you handle low-traffic sites where RUM sample sizes are tiny.

  3. 1

    This is interesting because a lot of people treat Lighthouse like a final verdict instead of a snapshot.

    I’ve seen sites score great but still feel slow or clunky in real use.

    Feels like actual user experience matters way more than chasing a perfect number.

  4. 1

    The gap between synthetic scores and real-user experience is one of those things that sounds obvious once you say it, but almost nobody acts on it. A 95 Lighthouse score feels like a stamp of approval. It's hard to look at that number and think "this might be lying to me."

    The device gap is what makes it tricky. Lighthouse simulates a mid-tier phone on a throttled connection — which is already better than what a lot of real visitors are actually using. A founder tests their page on a MacBook Pro with fiber internet, sees a green score, and moves on. Meanwhile half their audience is loading the same page on a 4-year-old Android over mobile data, and the experience is completely different.

    We ran into a version of this when analyzing page speed across multiple sites. The scores looked reasonable in isolation. But when we compared speed scores against other conversion factors, pages with "good" speed scores still had users bouncing — because the perceived load experience (layout shifts, delayed interactivity) didn't match the synthetic number. The score said fast. The visitor felt slow. Those are two different things.

    The broader lesson applies beyond speed too. Any single-metric tool gives you confidence, not clarity. Confidence feels good. Clarity is what actually helps you fix things.

    To answer your question: we've learned to treat Lighthouse as a baseline sanity check, not a source of truth. If the score is bad, something is definitely wrong. If the score is good, you still don't know how real visitors experience the page.

  5. 1

    Lighthouse is useful, but it’s still a proxy and not the product experience itself. I’ve seen plenty of cases where a “worse” score still delivered better UX and conversion because the page matched user intent better. Curious which real world metric diverged most for you from the Lighthouse score?

  6. 1

    Spot on. I’ve seen 99/100 Lighthouse scores tank in the wild because of heavy hydration on low-end devices or third-party scripts that fire after the initial paint. Synthetic tests are just a laboratory baseline. At Joinble, we prioritize Edge Computing (Cloudflare) specifically to reduce that variance, but RUM is the only way to see the 'long tail' of user experience. Lab data is for CI/CD; Field data is for business.

  7. 1

    One thing that makes this even more misleading is that many founders end up optimizing for the test itself rather than the real user experience. People spend hours trying to move a score from 92 to 99 in Google Lighthouse by removing unused CSS, compressing images, or shaving a few kilobytes off their JavaScript bundle. Those optimizations can be useful, but they often ignore the things that actually slow users down in production: heavy third-party scripts, analytics tags, blocking APIs, slow backend responses, or hydration delays in modern frameworks. A page can look perfect in a lab test and still feel sluggish the moment a real user tries to interact with it.

    Another factor is geography and device variability. Synthetic tests typically run from a small set of locations on controlled hardware, but real visitors might be thousands of kilometers away from your server, using older Android phones, unstable mobile networks, or laptops overloaded with extensions. When you start measuring real-user data through metrics like Core Web Vitals, the picture often looks very different. That’s why I tend to treat Lighthouse primarily as a debugging tool rather than a performance KPI. It’s great for identifying technical issues, but the only thing that really matters is how fast the site actually feels to the people using it.

    1. 1

      Well explained, that's exactly the issue. A lot of advice online pushes people to chase a 99+ Lighthouse score, often for SEO reasons, but that number itself isn't what Google cares about. What matters is the "real" user experience, reflected in Core Web Vitals from the Chrome User Experience Report.

      Lighthouse is great for debugging and spotting potential issues, but it won't capture things like slow third-party scripts, backend latency, or how the site performs for real users on different devices and networks.

  8. 1

    I often found that Lighthouse would give me different scores than Google Page Speed. I could never quite figure out which was more accurate. What do you think?

    1. 1

      That's expected! They're measuring different things. Lighthouse uses synthetic lab tests, while Google PageSpeed also shows real user data when available. For accuracy, real user metrics naturally matters more :)

  9. 1

    Interesting insight. Lighthouse scores can definitely be misleading compared to real user data.

    I'm currently building a small web experiment inspired by the Million Dollar Homepage — a pixel grid where anyone can buy a block and place their logo with a link. It's fascinating to see how performance and traffic behave with real users.

  10. 1

    Interesting insight. Lighthouse scores can definitely be misleading compared to real user data.

    I'm currently building a small web experiment inspired by the Million Dollar Homepage — a pixel grid where anyone can buy a block and place their logo with a link. It's fascinating to see how performance and traffic behave with real users.

    1. 1

      This comment was deleted 5 months ago

  11. 1

    Great explanation! Sometimes I also notice my Lighthouse scores don’t match real user experience—especially with dynamic content or heavy third-party scripts. Lab tests vs real users can be quite different!