A Lighthouse score is often the first thing anyone looks at when performance comes up, and often the last thing anyone understands. It's a single number built from several weighted metrics, run against a simulated environment that doesn't match any real user's device or network. That doesn't make it useless — it makes it a lab measurement, not a verdict, and reading it well means knowing what it's actually measuring and what it can't tell you.
What the score is actually made of
The Lighthouse performance score is a weighted combination of metrics, not one number in disguise. First Contentful Paint and Speed Index describe how quickly something useful appears on screen. Largest Contentful Paint marks when the largest visible element finishes rendering. Total Blocking Time approximates how much the main thread was too busy to respond to input during page load. Cumulative Layout Shift measures unexpected visual movement. Largest Contentful Paint and Total Blocking Time are weighted the heaviest of the group, which is why a single long-running script during load tends to move the score far more than a small delay in first paint.
Lab data is not field data
Lighthouse runs in a controlled, simulated environment — throttled network, throttled CPU, a single page load, no real user behavior. That makes it reproducible, which is exactly why it's useful for catching regressions in CI. It also means it can't tell you what real users on real devices, on real networks, in real locations actually experience. The Chrome User Experience Report and any real-user-monitoring setup measure "field data" — actual sessions from actual visitors. A page can score well in Lighthouse and still have a poor Core Web Vitals rating in the field, if the lab run doesn't reflect the conditions most of the traffic experiences. Treat Lighthouse as a way to catch problems early and consistently, and field data as the source of truth for what to prioritize.
Reading past the score
The number at the top is the least useful part of the report. The Opportunities and Diagnostics sections below it are where the actual work is — each one names a specific issue, with an estimated time savings attached. Working through those in order of estimated savings, rather than chasing the headline score directly, is usually the faster path to actually improving it, because the score moves as a side effect of fixing what it's measuring.
- Eliminate render-blocking resources before optimizing anything else — CSS and synchronous scripts in the head delay First Contentful Paint more than almost anything else on the page.
- Treat the reported "Largest Contentful Paint element" as a literal pointer — Lighthouse names the exact element responsible, so start there instead of guessing.
- Unused JavaScript and CSS often point at a bundling problem, not dead code — a route pulling in an entire library for one function is a common cause.
- Layout shift almost always comes from images or embeds without reserved dimensions, or web fonts swapping in after layout — both have a straightforward fix.
Running it where it actually catches problems
A Lighthouse run in DevTools, done occasionally by a developer who remembers to check, catches almost nothing. Wired into CI against a preview deployment, on every pull request, with a budget that fails the build past a threshold, it catches regressions before they ship — which is the only point in the workflow where a performance fix is cheap. The desktop and mobile presets matter here: most real traffic on a consumer-facing site skews mobile, so a mobile-throttled run is usually the one to gate on, even when the desktop number looks better.
Lighthouse and a Performance panel trace answer different questions. Lighthouse says what's wrong and roughly how much it costs. The Performance panel says exactly why — which function, which task, which frame. Used together, one tells you where to look and the other tells you what you're looking at.