Lighthouse performance score

The Lighthouse performance score is the number between 0 and 100 at the top of every PageSpeed Insights report, and the number most people quote when they talk about "page speed". It is a lab score: Lighthouse loads the page once in a simulated environment, measures a handful of metrics and combines them with fixed weights. That makes it useful for diagnosis and for comparing two versions of the same page, and unsuitable as a target in itself. This guide explains how the score is calculated, why it moves between runs, how it relates to the Core Web Vitals that Google actually uses, and how to improve it without optimizing for the wrong thing.

From PerfDelta's measurements: The median mobile Lighthouse score of the 4,079 measured home pages is 42. Only 1% reach 90 or more, while 64% stay below 50. More in the data section below.

How the score is calculated

Lighthouse measures five metrics during the lab run and converts each into a sub-score from 0 to 100 using a log-normal curve calibrated on real-world data from the HTTP Archive. The sub-scores are then weighted:

Metric	Weight	What it captures
Total Blocking Time	30%	how long long tasks block the main thread during load
Largest Contentful Paint	25%	when the main content is visible
Cumulative Layout Shift	25%	how much the layout moves during load
First Contentful Paint	10%	when the first content is visible
Speed Index	10%	how quickly the visible area fills in

The weights are those of Lighthouse 10 and later; earlier versions included Time to Interactive and weighted the metrics differently, which is one reason scores from old reports are not comparable. A score of 90 to 100 is shown in green (good), 50 to 89 in orange (needs improvement), 0 to 49 in red (poor). Because the curves are log-normal, the last points toward 100 are much harder to earn than the first points away from 0.

The audits listed below the score, such as render-blocking resources or unused JavaScript, do not feed into the score directly. They are diagnostics that explain why the metrics came out as they did.

Why the score changes between runs

Running Lighthouse twice on the same page rarely gives the same number. The test machine, its current load, the network path to the server, A/B tests and ads on the page, and the page's own caching state all vary. A difference of a few points between two runs means nothing. Lighthouse itself documents this variability and recommends several runs or a controlled environment for comparisons. PerfDelta's monitoring addresses it by testing on a fixed schedule and showing the trend rather than single values.

Lab score versus Core Web Vitals field data

The score is not what Google uses for ranking. Google's page experience signals use the Core Web Vitals from the Chrome UX Report: real visitors, real devices, the 75th percentile over 28 days. Three differences matter:

• Device and network. The mobile lab run simulates a mid-range phone on a slow 4G connection. If your visitors mostly use recent phones on fast networks, field data looks much better than the lab score.
• INP has no lab equivalent. The score uses Total Blocking Time as a proxy for responsiveness; the field uses INP, measured on actual interactions. A page can block the main thread at load and still respond well later, or the reverse.
• One load versus thousands. The lab tests one cold load of one URL. The field aggregates every page view, including repeat visits with warm caches.

The practical consequence: a page can have a lab score in the 30s and pass the Core Web Vitals with real users, and a page with a score above 90 can still fail INP in the field. Both happen regularly in our measurements; the data section below shows how often. When the two disagree, the field data decides what Google sees, and the lab score tells you where to look.

How to improve the performance score

Because of the weights, the fastest way to raise the score is to work on the heaviest items first:

1. Total Blocking Time (30%). Reduce and defer JavaScript, break up long tasks and limit third-party scripts. See Reduce JavaScript execution time and Third-party code.
2. Largest Contentful Paint (25%). Make the LCP image discoverable and high priority, remove render-blocking resources, and keep TTFB low.
3. Cumulative Layout Shift (25%). Reserve space for images, ads and embeds, and load fonts with a size-adjusted fallback (see font-display).
4. FCP and Speed Index (10% each). Both follow from the steps above; inline critical CSS and a small HTML document help further.

Avoid the shortcuts that raise the score without helping visitors: delaying all JavaScript until after the Lighthouse run ends, serving a different page to the test agent, or hiding content until the measurement is over. They are easy to detect, they do nothing for field data, and they make the diagnostic value of the score disappear.

What a good score is

Treat 90 and above as the sign that the page has no large lab-visible problems, and 50 as the line below which a mid-range phone on a slow connection has a poor experience. Between the two, use the metric breakdown rather than the single number. For the business, the goal is passing Core Web Vitals in the field; the score is the tool that gets you there.

Frequently asked questions

Does the Lighthouse score affect Google rankings?

Not directly. Google uses Core Web Vitals field data from the Chrome UX Report. The score is a lab tool that helps you find and fix the causes behind poor field data.

Why is my mobile score so much lower than my desktop score?

The mobile run throttles CPU and network to simulate a mid-range phone on slow 4G, so JavaScript takes several times longer to execute and large files take longer to arrive.

Why does my score change every time I run the test?

Test machine load, network conditions, ads and A/B tests all vary between runs. Differences of a few points are noise; compare trends over several runs instead.

Can a page pass Core Web Vitals with a poor score?

Yes, and it happens often, because real visitors tend to have faster devices and networks than the lab simulation. The reverse also happens, especially for INP, which the lab cannot measure.