September 18, 2026 · 2 min read

PerformanceCore Web Vitals

Why your Lighthouse score lies to you

A 98 in a lab tells you almost nothing about what a real visitor on a real phone experiences. Here's what we check instead.

A green Lighthouse score feels like proof. It isn't — it's a single run, on a simulated mid-range phone, on a simulated network, with nothing else open in the browser. Real visitors aren't simulated, and the gap between a lab score and a real experience is where most "fast" sites quietly lose people.

What a lab score actually measures

Lighthouse runs your page once, in a clean Chrome instance, with fixed CPU and network throttling. That's genuinely useful for catching regressions in CI — it's consistent, so a drop from 95 to 80 means something changed. What it doesn't capture is variance: your actual visitors are on a huge range of devices, networks and conditions, and a single synthetic run averages all of that away.

The three numbers worth tracking instead

Field data, not lab data. The Chrome User Experience Report (CrUX) and your own Real User Monitoring tell you what actually happened for actual visitors — not what happened once, in a lab. If you only have one performance number to check weekly, make it field LCP, not lab Lighthouse.

INP, not just load time. Largest Contentful Paint tells you how long the page took to look done. Interaction to Next Paint tells you how long it took to respond after that — a page that paints fast but freezes on the first click has only fixed half the problem.

What happens on the worst device you'll realistically see, not the median one. A dashboard that's fine on an M-series laptop and unusable on a three-year-old Android phone is not actually fast — it's fast for whoever tested it.

On this site, our own budget is Lighthouse 90+ on mobile as a floor, not a target — the number we actually watch after launch is field LCP and INP, which we'll publish once there's real traffic to measure.

What we actually do differently

We treat performance as a design constraint from the first wireframe, not a cleanup pass before launch: fonts subset and preloaded, JavaScript that isn't needed for the first paint deferred or lazy-loaded, and anything genuinely heavy — like a WebGL scene — built so it never blocks the Largest Contentful Paint element, on any device. The lab score is a useful early warning, not the finish line.