Lighthouse Score Explained: What Each Category Actually Measures

Most people encounter their Lighthouse score as a single number - green if you're lucky, red if you're not - and treat it like a grade. In reality it's four separate scores, each built from a different set of checks, and "improve your Lighthouse score" means something completely different depending on which one you're actually looking at.

The Four Categories (and What They're Really Testing)

Every Lighthouse run produces a Performance, Accessibility, Best Practices, and SEO score. They don't share a scoring method and they don't measure related things - a site can score 98 on Accessibility and 40 on Performance without any contradiction.

• Performance - a weighted composite of lab timing metrics (covered below), not a simple pass/fail checklist. This is the only category where the score is a calculated number rather than a percentage of passed audits.
• Accessibility - automated checks against WCAG success criteria: color contrast, missing alt text, form labels, ARIA usage, focus order. It catches roughly a third of real accessibility issues - the ones a script can detect without a human judging whether something actually makes sense to a screen reader user.
• Best Practices- a grab-bag of modern web hygiene: whether you're serving images in next-gen formats, using HTTPS, avoiding deprecated APIs, not logging errors to the console in production, and a few genuine security checks like avoiding vulnerable JS libraries.
• SEO- crawlability and indexability basics: a valid meta description, a descriptive title tag, legible font sizes, tap targets sized for mobile, and a robots.txt that isn't accidentally blocking everything. It has almost nothing to do with actual search ranking beyond confirming Google can read and render the page at all.

Why Your Score Changes Between Runs

Run Lighthouse twice in a row on the same URL and you'll often get two different Performance scores. This isn't a bug - lab data is collected on a real machine with real variance in CPU scheduling, network conditions, and background load, and Performance is the only category built from timing measurements sensitive to that noise. Accessibility, Best Practices, and SEO are built from static checks against the rendered DOM, so those three barely move run to run.

A few things make Performance variance worse than it needs to be: running audits with browser extensions installed (each one adds CPU overhead and sometimes injects its own scripts), testing on a laptop actively running other software, and comparing a run from a fast home connection against one from a throttled CI environment. For anything you're going to act on, run it a few times and look at the median, not the first number you see.

The Weighted Formula Nobody Reads

The Performance score isn't an average of pass/fail audits - it's a weighted blend of six metrics, each scored on a curve against real-world data from the HTTP Archive, then combined:

• Largest Contentful Paint (25%) - when the biggest visible element finishes rendering.
• Total Blocking Time (30%) - how long the main thread was too busy to respond to input.
• Cumulative Layout Shift (25%) - how much visible content jumped around unexpectedly.
• First Contentful Paint (10%) - when anything at all first appears.
• Speed Index (10%) - how quickly content visually fills in on average.

The weights are why a site can look "fast" to a person and still score poorly - a page that paints quickly but keeps a hidden tab or heavy third-party script tying up the main thread gets hit hard on Total Blocking Time, which is nearly a third of the whole score. See our Core Web Vitals guide for what LCP and CLS specifically measure and how to fix them.

Lab Data vs. Field Data

Everything above is lab data- a simulated visit on a controlled connection. It's useful for debugging because it's reproducible, but it can diverge from field data- what real visitors on real devices and real networks actually experience, collected via the Chrome User Experience Report. Google's ranking signal is based on field data, not your Lighthouse score directly. A good lab score is a strong predictor, not a guarantee.

Which Score Is Actually Worth Chasing

Treat the four categories differently, because they carry different weight in the real world:

• Performance matters directly - it affects both user experience and, through Core Web Vitals, search ranking. Worth optimizing for real.
• Accessibilitymatters for reasons a score can't capture - legal exposure and whether real people with disabilities can use your site. Treat 100 as a floor confirming the automatable third of issues are gone, not proof the site is accessible.
• Best Practices is worth glancing at for the genuine security-relevant checks (vulnerable libraries, missing HTTPS) but chasing 100 by fixing every deprecated-API warning is usually not the best use of your time.
• SEO is a floor, not a strategy. Passing it means Google can technically crawl and parse your page - it says nothing about whether the page will rank for anything.

A full performance audit breaks each category down into a prioritized fix list instead of leaving you to reverse-engineer which of the underlying audits actually moved the number.