How the Lighthouse performance score is calculated

What the score is

Lighthouse loads your page once in a lab, measures a handful of timings, and combines them into a single number from 0 to 100. In the report, 90 to 100 is shown in green, 50 to 89 in orange and 0 to 49 in red. It is the big circle at the top of the performance section in Lighthouse and in the lab part of PageSpeed Insights.

It is useful as a quick summary and as a way to compare two tests of the same page. It is not a measurement of how real visitors experience the page. The Core Web Vitals are judged on data from real visits, which is a different thing, and lab and field numbers often disagree.

The five metrics and their weights

In Lighthouse 13.5, the score is built from these metrics:

Two things are missing from the table on purpose. Interaction to Next Paint (INP) is a Core Web Vital, but it needs a person tapping, so it has weight 0 in a standard load test. Time to Interactive is still calculated inside Lighthouse but no longer counts: in older versions it carried 10%. The weights have changed over time as the Lighthouse team learned what matters most to visitors. In Lighthouse 8, for example, Cumulative Layout Shift counted for 15%.

The long list of recommendations below the score, the insights and diagnostics, does not feed into it. Lighthouse's documentation puts it plainly: only the metrics contribute. Fixing a recommendation raises the score only if it improves one of the five metrics.

How a metric becomes a score

Each metric has two control points: the value that earns a score of 90, and the value that earns 50. Lighthouse draws a smooth curve through them, so a faster result always earns more, but with diminishing returns. Here are the control points for the test settings Lighthouse uses by default:

The control points were set from how real websites in the HTTP Archive performed, so the scale reflects the web as it was when they were chosen. The mobile marks for LCP, FCP and CLS are the same as Google's "good" and "poor" marks for real visits. The desktop control points are tighter, since a desktop test assumes a faster computer and connection: a First Contentful Paint of 1.8 seconds, a 90 on mobile, scores about 38 on desktop.

Here is what the curve does for some mobile values. These numbers were calculated with Lighthouse's own scoring function.

Three things stand out. First, 90 is where "good" lands, so a page that only just meets Google's marks on every metric scores about 90 overall, not 100. Second, the top of the scale is flat: going from an LCP of 1.5 seconds to 1.0 seconds earns nothing. Third, the middle of the scale is steep, so moving a slow metric to a mediocre one gains much more than moving a good one to an excellent one.

Worked examples

The overall score is the weighted average of the five metric scores. Two made-up pages show how one weak metric pulls the whole number down.

Page A has slow scripts. Everything is at the "good" mark except Total Blocking Time, which is 1,000 milliseconds, scoring 27. TBT carries 30% of the weight, so it takes away about 22 points. The overall score is 73.

Page B has a heavy main image. Everything is good except LCP, at 5 seconds, scoring 27. With a weight of 25%, it takes away about 18 points. The overall score is 76.

A page at the "good" mark on all five metrics scores 90. A page at the 50 mark on all five scores 50. A page with an FCP of 1.0 seconds, an LCP of 1.5 seconds, a TBT of 100 milliseconds, no layout shift and a Speed Index of 2.0 seconds scores 99.

Using the weights to decide what to fix

Each metric's contribution is its weight times its score. The points you are losing on a metric are its weight times the gap to 100. For Page A above, that is 30 × 0.73 = about 22 points on TBT and nothing noticeable on the others. Look at your own report the same way: find the metric with the lowest score, multiply the gap by its weight, and fix that one first. Because Total Blocking Time has the largest weight, JavaScript is the biggest single lever on the lab score.

You can try your own numbers in the official Lighthouse scoring calculator.

Why the score changes from run to run

Lighthouse's own documentation says that most of the variation is not caused by Lighthouse but by what is being measured and where. The guide on why scores change goes through all seven sources. The common ones are:

• The page itself. A/B tests, changing ads and anything else that makes the page different on every load. Nothing can remove this variation.
• The network. Local network conditions, and routes that change between runs. Lighthouse's default method simulates a slow network after loading the page on a normal one, which smooths most of it out.
• The server. Response times vary, more so on shared hosting with other busy sites.
• The machine running the test. A powerful desktop and a weak laptop give different results, and other programs, browser extensions and antivirus software running at the same time add their own load. The documentation singles out extensions and antivirus as having a strong effect.

How to cope with it:

1. Run the test several times and use the median. Three is a minimum; the Lighthouse team says the median of five runs is twice as stable as one run.
2. Keep the conditions the same. The same page address, the same device setting (mobile or desktop), the same tool, ideally the same time of day.
3. Test in a clean browser. A private window with extensions turned off removes a common source of noise.
4. Do not chase small differences. A change of a few points between two single runs is noise. A change of 10 or more that holds up across runs is a real result.

What the score cannot tell you

• Whether you pass the Core Web Vitals. That is decided by field data. A page can score 100 in the lab and fail in the field, and the other way around.
• How your visitors feel. The lab simulates one device on one network. Your visitors have many.
• Anything about INP, the Core Web Vital for responsiveness, since a standard load test has no taps.
• Anything below the first screen after load. The lab test mostly sees the page load, not what happens when someone scrolls and uses the page.

Chasing the last few points rarely pays. Once the field data is good and the lab score is in the green, time is better spent on content and on the pages that matter most to your business.

Check your own page

Run the free audit and look at the performance score next to the five metric values underneath it. Find the metric with the lowest score and the highest weight, and read the guide for it. Then run the test three times before you decide that a change worked.

Sources

• Lighthouse performance scoring in the Lighthouse documentation: weights, what counts and why scores fluctuate.
• Lighthouse score variability: the sources of variation and how to deal with them.
• Lighthouse scoring calculator: try your own values.
• Lighthouse source code: the weights and control points quoted above are in core/config/default-config.js and core/audits/metrics.