# Your Lighthouse score is not a performance budget

*Jul 12, 2026 · 3 min read*

> A score is a snapshot. A budget is a build that fails. Here is the CI config we put on every project, and the three numbers we hold it to.

**In short:** A Lighthouse score measures one run on one machine. A performance budget fails the build when a metric regresses. Set budgets on LCP, CLS and total JavaScript, enforce them in CI on every pull request, and the number stops drifting between launch and month six.

The short answerA Lighthouse score is a weighted average of five lab metrics captured in one run. A performance budget is a threshold that fails your build when a specific metric regresses. The score tells you roughly where you stand today; the budget is what stops you sliding backwards over the next six months.

Every project we take over from another agency arrives with a screenshot of a green Lighthouse score somewhere in the handover pack. It is usually eighteen months old, it was usually run on a laptop on office wifi, and it is usually the last time anybody measured anything.

## Why a score drifts and a budget does not

The score is an average. That is the whole problem. Five metrics, each weighted, collapsed into one number between 0 and 100. Largest Contentful Paint can get half a second worse while Total Blocking Time happens to improve, and the composite barely moves. Your customer does not experience a composite. They experience the half second.

A budget inverts the relationship. Instead of asking "what did we score", it asks "did any single number cross the line we agreed". If it did, the build does not merge. Nobody has to notice, nobody has to remember, and nobody has to volunteer to care about performance in a sprint where three other things are on fire.

## Which three numbers we hold every project to

We budget on three, and only three, because a budget nobody can recite is a budget nobody enforces.

**LCP under 2.0 seconds** on a throttled mid-tier mobile profile. Not 2.5 — the official "good" threshold — because 2.5 is where Google stops penalising you, not where a person stops feeling the wait. Building to the pass mark leaves you no headroom for the marketing team adding a hero video in month four.

**CLS under 0.05.** The official threshold is 0.1. In practice, anything above about 0.05 means an image, an ad slot or a late-loading font is moving content under someone\'s thumb. It is also the cheapest metric to fix and the easiest to regress, which makes it the best canary in the set.

**A hard cap on shipped JavaScript**, in kilobytes, agreed at kickoff. This is the one that actually changes behaviour, because it turns "should we add this library" from a taste argument into an arithmetic one.

## Where the check has to run

On the pull request. Not nightly, not weekly, not on a dashboard someone has bookmarked.

A nightly job produces a Slack message at 3am naming a commit from yesterday. By the time anyone reads it, three more commits have landed on top and nobody wants to be the person who reverts the sprint. A pull request check produces a red tick next to the change that caused it, while the person who wrote it still has the context loaded. The fix takes ten minutes instead of a planning cycle.

## What this costs

About two hours to set up and roughly ninety seconds per pull request. That is the entire price. The alternative — the one we keep being hired to fix — is a rebuild in year two because the site got slow so gradually that nobody could point at the commit that did it.

---

Source: https://rscs.ae/blog/lighthouse-score-is-not-a-performance-budget
RSX Digital | Custom Web Apps, Mobile & AI Solutions UAE — rscs.ae