How to actually read a Lighthouse report

The headline Lighthouse score is a weighted composite of several metrics, and treating it as the goal tends to produce the wrong optimizations — like a team spending a week shaving 200ms off Speed Index while an INP problem three times as impactful for real users sits untouched further down the report.

We start every triage in the 'Diagnostics' and 'Opportunities' sections, not the score. Opportunities are ranked by estimated time savings, which gives an honest picture of what's actually worth fixing first — usually unused JavaScript, render-blocking resources, or oversized images, in roughly that order of frequency in the audits we run.

Lab data from a single Lighthouse run is also just one sample on one simulated connection. Before committing engineering time to a fix, we check it against field data (real user monitoring, or CrUX data if the site has enough traffic) to confirm the lab finding actually reflects what real users experience — lab and field can disagree more than people expect.

One habit worth adopting: run Lighthouse in CI on every pull request against a performance budget, not just occasionally by hand. Catching a regression in a five-line diff is trivial; catching the same regression three months later after ten more changes have landed on top of it is a much longer investigation.