# How the Lighthouse performance score is calculated

> The Lighthouse performance score is a weighted average of five metric scores: TBT 30%, LCP 25%, CLS 25%, FCP 10% and Speed Index 10%. Here is how it works.

Published: 2026-11-15 · Author: AiroPages

The Lighthouse performance score is a weighted average of five lab metrics. Lighthouse measures Total Blocking Time, Largest Contentful Paint, Cumulative Layout Shift, First Contentful Paint and Speed Index, turns each one into a 0 to 100 score, then combines them with fixed weights: 30%, 25%, 25%, 10% and 10%. Knowing those two steps tells you which fixes will actually move your score.

## The five metrics and their weights

Since Lighthouse 10, the performance score has used five metrics, and the weights are still the same in Lighthouse 13.

| Metric | Weight | What it measures |
|---|---|---|
| [Total Blocking Time (TBT)](/glossary/tbt) | 30% | How long long tasks blocked the main thread during load |
| [Largest Contentful Paint (LCP)](/glossary/lcp) | 25% | When the largest image or text block in the viewport appeared |
| [Cumulative Layout Shift (CLS)](/glossary/cls) | 25% | How much visible content moved unexpectedly during load |
| First Contentful Paint (FCP) | 10% | When the first text or image appeared |
| Speed Index | 10% | How quickly the visible part of the page filled in |

Together, TBT, LCP and CLS account for 80% of the score. FCP and Speed Index matter, but improving them alone rarely changes the overall number much.

The score bands are the same for every category:

- **90 to 100:** good (green)
- **50 to 89:** needs improvement (orange)
- **0 to 49:** poor (red)

See the [Lighthouse score](/glossary/lighthouse-score) glossary entry for how the other categories are scored.

## Step 1: each metric becomes a 0 to 100 score

Lighthouse cannot average milliseconds with layout shift values, so it first converts each raw metric into a score between 0 and 100. It does this with a scoring curve for each metric, based on a log-normal distribution.

You do not need the math to use it. What matters is the shape:

- **At the fast end, the curve is flat.** If a metric is already very good, making it even faster adds only a point or two.
- **In the middle, the curve is steep.** Here, a modest improvement can add many points to that metric's score.
- **At the slow end, the curve is flat again.** If a metric is very slow, a large improvement may still leave it near zero until it reaches the steep part.

Each curve is set by two control points: the value that earns a score of 50 and the value that earns a score of 90. According to [Chrome's documentation on performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring), these control points are derived from real-world website data in the HTTP Archive, so the score reflects how your page compares with the web at large.

Mobile and desktop use **different curves**. Desktop curves are stricter, because desktop devices and connections are faster, so the same LCP time earns a lower score on desktop than on mobile. This is one reason why [mobile and desktop scores differ](/blog/mobile-vs-desktop-lighthouse-scores) in more ways than just throttling.

## Step 2: the weighted average

Once every metric has a score, Lighthouse multiplies each by its weight and adds them up:

**Performance score = (TBT score × 0.30) + (LCP score × 0.25) + (CLS score × 0.25) + (FCP score × 0.10) + (Speed Index score × 0.10)**

The result is rounded to a whole number. That is the number shown in the gauge at the top of the report.

## A worked example

The numbers below are illustrative, chosen to show how the weights work. They are metric scores, not raw timings.

Imagine a product page whose five metrics score like this on mobile:

| Metric | Metric score | Weight | Contribution |
|---|---|---|---|
| TBT | 40 | 30% | 12.0 |
| LCP | 70 | 25% | 17.5 |
| CLS | 100 | 25% | 25.0 |
| FCP | 85 | 10% | 8.5 |
| Speed Index | 80 | 10% | 8.0 |
| **Total** | | | **71** |

The page scores 71, in the orange band. Now compare three possible changes:

1. **Cut JavaScript so TBT's score rises from 40 to 80.** The TBT contribution goes from 12 to 24, and the overall score rises to **83**.
2. **Improve FCP and Speed Index by 15 points each** (to 100 and 95). Each adds 1.5, and the overall score rises only to **74**.
3. **Add an ad slot without reserved space, so CLS's score falls from 100 to 60.** The CLS contribution drops from 25 to 15, and the overall score falls to **61**.

The lesson: a 40-point gain in a 30% metric is worth 12 points overall, while 15-point gains in two 10% metrics are worth 3 points combined. And a single layout shift problem can undo a lot of good work, because CLS carries the same weight as LCP.

You can try your own numbers in Google's Lighthouse Scoring Calculator, which is linked from every Lighthouse report.

## Why TBT and LCP dominate

TBT and LCP together carry 55% of the score, and in practice they decide most results.

- **TBT has the largest weight** and is the metric most sensitive to JavaScript. On the mobile test, with its 4 times CPU slowdown, frameworks, tag managers and third-party widgets quickly push TBT into the steep part of its curve.
- **LCP is often the hardest metric to make fast.** It depends on server response time, render-blocking files, image size and how early the browser discovers the LCP resource. A problem anywhere in that chain delays it.
- **CLS is often already good.** Many pages have little or no layout shift during load and get a full or near-full CLS score. That makes CLS "free points" on those pages, and a sudden loss when something starts shifting.

TBT is also the most variable metric between runs, which is part of [why your Lighthouse score changes every time you run it](/blog/why-lighthouse-scores-change).

## What does not affect the score

Several things appear in the report but do not change the performance score directly:

- **Insights and diagnostics.** Items such as LCP request discovery, render-blocking requests and improve image delivery explain problems and estimate savings, but only the five metrics are scored.
- **Estimated savings.** A saving of 1.2 seconds in an insight does not mean the score will rise by a fixed amount. It depends on where the affected metric sits on its curve.
- **INP.** Interaction to Next Paint needs real user input, so it is not part of a lab run. TBT stands in for it.
- **Field data.** The Chrome UX Report section in PageSpeed Insights is shown separately and does not feed into the lab score.
- **The other categories.** Accessibility, Best Practices and SEO have their own scores and do not affect performance.

Server response time is not one of the five metrics either, but a slow first byte delays FCP, LCP and Speed Index, so it lowers the score indirectly.

## What moves the score most

If you want the biggest gain for the least work, follow the weights and the curves:

1. **Reduce main-thread JavaScript.** Remove unused scripts, defer the rest, delay third-party tags and break up long tasks. This targets TBT, the 30% metric.
2. **Speed up the LCP element.** Serve a properly sized image, do not lazy-load it, make sure the browser finds it early, and reduce render-blocking CSS.
3. **Protect CLS.** Set dimensions on images and embeds, and reserve space for ads, banners and late-loading content.
4. **Then tidy FCP and Speed Index.** Inline critical CSS, load fonts efficiently and cut server response time.
5. **Focus on metrics in the steep zone.** A metric scoring 30 to 80 will usually gain more from a fix than one already at 95.

Pushing from 95 to 100 is hard because every metric has to sit on the flat, fast end of its curve at once, and normal variance can still cost a point or two. For most sites, getting key templates into the green is a better use of time than chasing a perfect 100.

## How to check this across your whole site

The manual way is to run Lighthouse on each URL, save the JSON reports, and pull out the five metric values and scores so you can see which metric is dragging each page down. With the CLI or the PageSpeed Insights API you can script this over your sitemap, then sort pages by their weakest metric. It is the only way to see the pattern, because Lighthouse only tests one URL per run, as we explain in [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page).

AiroPages runs every page on mobile and desktop with PageSpeed Insights settings and groups identical issues by page template, ranked by how many pages each affects and its impact. That makes it easier to see, for example, that TBT from one script is holding down every blog post.

## Follow the weights

The Lighthouse performance score is simple once you see its two steps: five metrics, each scored on a curve, combined with fixed weights. Start with TBT and LCP, keep CLS clean, and spend less time on the 10% metrics until the big three are in good shape. The score will follow.