Why I stopped chasing perfect Lighthouse scores

Three years ago I was the kind of developer who'd spend a Friday night shaving 80ms off a page load. I had a spreadsheet of Lighthouse scores across client sites. I got a small hit of satisfaction every time a column went from 89 to 100.

Then one client I'd optimized to a perfect 100 lost a round of traffic. Another client whose site scored in the 70s kept growing. The signal wasn't there. I'd been measuring the wrong thing for years.

Here's what I do instead now, and why I think a lot of web developers are stuck where I used to be.

The gap between lab and field

Lighthouse runs in a simulated environment. Specific CPU throttling, specific network shape, specific viewport. You open Chrome DevTools, click audit, and get a number. That number is reproducible on your machine. It's also effectively a lab benchmark — not what your users experience.

Google Search Console shows you something different. Core Web Vitals there come from real user monitoring — the actual load times, actual interaction delays, actual layout shifts that your actual users experienced on their actual phones. This is "field data." It's what Google's algorithm uses.

The two numbers can disagree by a lot.

I've seen this exact gap multiple times. Lighthouse 100 on desktop, field LCP at the 75th percentile above 2.5s because real users are on iPhone 11s with 10 tabs open on hotel wifi. The lab test doesn't know about any of that.

What I optimize for now

The real metric is: how long does it take for my users — the actual ones in Search Console field data — to see the main content of the page?

I check the Core Web Vitals report in Search Console every couple of weeks. The three numbers I watch:

• LCP p75 (Largest Contentful Paint, 75th percentile of real users). Target under 2.5s.
• INP p75 (Interaction to Next Paint). Target under 200ms. This replaced FID in 2024.
• CLS p75 (Cumulative Layout Shift). Target under 0.1.

If these three are in the green zone, the site is performing well for real users. That's the north star. Lighthouse score is a convenience while I'm still developing — it reproduces quickly, it runs locally, it tells me if I just shipped something catastrophic. But it's not the goal.

What I've stopped caring about

I don't shave milliseconds anymore unless the field data says I should. If Search Console shows all green, the site is objectively fast enough for users. If Lighthouse says 89 because of some specific measurement quirk, who cares. The only reason to invest further is if real users are struggling, and real users will show up in field data.

When Lighthouse is still useful

It's not worthless. It's just not the goal.

Lighthouse is a fantastic regression detector. If a site was scoring 92 and suddenly scores 74 after a deploy, something got meaningfully worse. I run it on every PR via a CI integration, and I look at the diff, not the absolute number. If the score drops by more than 5 points on the same page, I look at what changed.

It's also useful for finding specific actionable issues. The "unused JavaScript" warning. The "eliminate render-blocking resources" hint. These are concrete things to look at. But they don't all need fixing. Some are pedantic. Some apply to situations you've already considered.

The real performance audit I'd run

What I'd tell a younger developer

If you're under a year into web development and you've been chasing Lighthouse scores, that's fine. It teaches you the mechanics. You learn what a render-blocking resource is. You learn why layout shift happens. That grounding is valuable.

But recognize when you've learned the lesson. At some point the score stops being a learning tool and becomes a vanity metric. When you've been inlining critical CSS for six months and the real user metrics haven't moved, you've crossed that line. Move on to the field data.

The work changes. You stop fiddling with synthetic tests and start thinking about the specific phone that the specific person at 10 PM in Surrey has in their hand. That's the audit that matters.