How Lighthouse Performance Scores Are Recorded and Calculated

A client forwards a PageSpeed Insights screenshot with a big green 94 and asks whether the site is “fast enough for Google.” Another week the same URL shows 81 on mobile after a tag manager change, and the account thread fills with theories. Both reactions treat the Lighthouse Performance score as a single truth. It is not. It is a lab construct: metrics recorded under controlled conditions, then calculated into a 0–100 number with curves and weights that Google documents and occasionally revises.

Chrome’s Lighthouse performance scoring guide is the source of truth for that math. What follows translates it for agency reporting: what gets recorded in a run, how the score is calculated, which weights apply in current Lighthouse 10 documentation, why the number is not the same as field Core Web Vitals, and how Apogee Watcher stores category scores from scheduled runs without pretending they are CrUX. Keep the calculator open while you read if you want to poke individual metrics.

What a Lighthouse Performance score actually is

The Performance score is a single 0–100 summary for one lab run of one URL under one device strategy (mobile or desktop). It is not a ranking factor by itself. It is not a rolling average of real visitors. Opportunities and Diagnostics in the report do not add points directly; they explain ways the underlying metrics might improve, which can raise the score indirectly when those metrics move.

Colour bands in the docs are simple: 0–49 poor (red), 50–89 needs improvement (orange), 90–100 good (green). A perfect 100 is unusually hard. Moving from 99 to 100 can need as much metric improvement as moving from 90 to 94. For client language, “good” means a lab run that cleared 90 under that profile, not that every user on every network had a green experience.

PageSpeed Insights uses Lighthouse for the lab block. When people say “the PageSpeed Insights score,” they usually mean that lab Performance category, sometimes while looking at a CrUX field panel on the same screen. Keep those two stories separate in every deck.

How Lighthouse records lab metrics in a controlled run

Recording comes first. Lighthouse (and PageSpeed Insights lab mode) loads the URL in a controlled environment: a chosen form factor, simulated network and CPU throttling for typical mobile profiles, and a single navigation. During that load it measures timings and layout behaviour. Common Performance metrics include First Contentful Paint (FCP), Speed Index (SI), Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Diagnostics such as Time to First Byte (TTFB) may appear as supporting detail. None of those values are taken from real visitors in that run.

The lab profile matters. Mobile and desktop use different throttling and, since Lighthouse 6, different scoring curves so desktop is not scored on mobile HTTP Archive distributions. Running on a quiet office machine with extensions disabled still differs from a busy shared CI worker. Chrome documents common causes of score fluctuation: ads and A/B tests, routing changes, device power, extensions, antivirus. Treat a single paste as a sample from a distribution, not as the only possible score for that URL.

Scheduled monitoring reduces the “two screenshots, no baseline” problem. You still measure lab conditions, but you compare like with like over time. That is the operational gap we described in PageSpeed Insights versus automated monitoring.

How Lighthouse calculates the 0–100 Performance score

Calculation is a second step. Lighthouse does not average raw milliseconds into one number. For each metric it maps the recorded value onto a 0–100 metric score using a log-normal scoring curve calibrated from HTTP Archive site data. Those metric scores stay under the hood in the usual report UI. The visible Performance score is then a weighted average of the metric scores.

Chrome describes the curve control points clearly. The 25th percentile of HTTP Archive data for a metric maps to a metric score of 50. The 8th percentile maps to 90 (the “good” control point). Between roughly 0.50 and 0.92 the relationship is nearly linear; near 0.96 returns diminish and further metric gains buy less score. Exploring a metric in the Lighthouse scoring calculator is the fastest way to see how a raw LCP or TBT value becomes a metric score before weights apply.

Because the curves come from real-site distributions, “good” is relative to the web as captured in HTTP Archive, not to an arbitrary round number your client invented in a brand guideline. When Lighthouse major versions change weights or curves, historical scores need a footnote. Always cite the Lighthouse version your tool used when you compare quarters.

Lighthouse scoring weights (Lighthouse 10)

Chrome’s documented Lighthouse 10 weights for the Performance score are:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index (SI)	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

TBT carries the largest single weight. LCP and CLS share 25% each. FCP and Speed Index are lighter. Earlier majors differed; Lighthouse 8 still weighted Time to Interactive and used a different CLS weight. Verify the table for the version you ship in CI or see in PageSpeed Insights, and re-check the calculator when Google publishes a new major.

INP may appear in field tooling and in some report contexts, but the lab Performance blend documented for Lighthouse 10 emphasises TBT as the interactivity proxy inside the score. Do not tell a client that “INP is 30% of the Lighthouse score.” Point them at TBT for lab scoring and at field INP for CrUX and Search Console when samples exist. Metric definitions live in LCP, INP, and CLS explained; field interactivity detail is in our INP guide.

Why the Performance score is not the same as Core Web Vitals field data

Field Core Web Vitals come from real Chrome users in the Chrome User Experience Report (CrUX), with Search Console and the PageSpeed Insights field section as common surfaces. Lab Performance scores come from one synthetic navigation. Both can mention LCP and CLS; only the lab score folds in Speed Index and TBT with the weights above. Field INP has no twin inside that Lighthouse 10 weight table.

Question	Lab Performance score	Field Core Web Vitals (CrUX)
Who was measured?	Controlled lab profile	Real Chrome users (sample)
What number?	Weighted 0–100 from metric scores	Percentiles for LCP, INP, CLS (and related)
Interactivity in the blend?	TBT (lab)	INP (field)
Good enough for SEO field status?	No, not by itself	Search Console / CrUX when eligible
Useful after a deploy?	Yes, fast regression signal	Yes, after the rolling window catches up

Agencies need both clocks. Lab catches “we broke the template today.” Field answers “Chrome users over ~28 days still feel it.” We covered the field lag in Why your Core Web Vitals fix is not in CrUX yet and the synthetic versus RUM split in When to use synthetic versus real user monitoring. Missing field rows are a sampling problem, not proof the lab score is wrong; see When PageSpeed Insights shows no CLS or INP.

Why Lighthouse scores fluctuate between runs

Variability is normal. The same URL can move several points between back-to-back runs when ads, consent banners, third-party scripts, or CPU contention differ. Chrome’s variability documentation exists for a reason. For retainers, prefer medians or repeated scheduled runs over a single heroic screenshot. Agree the device strategy (mobile versus desktop) before you argue about a five-point swing.

CI and local DevTools can also disagree because of Lighthouse version, throttling presets, and whether the environment matches PageSpeed Insights. When you automate audits with coding agents or DevTools workflows, still treat the Performance number as lab math under a stated version. Our note on Lighthouse audits with AI agents covers the agency gap between one-off agent runs and portfolio schedules. Separate audits such as Baseline Features change Best Practices diagnostics without rewriting the Performance weight table; see Lighthouse’s Baseline Features audit.

How agencies should report Lighthouse scores to clients

Name the artefact: “Lighthouse / PageSpeed Insights lab Performance score,” not “Google’s speed ranking.”
State device and version: mobile or desktop, and Lighthouse major when known.
Show the drivers: LCP, TBT, and CLS usually explain most of the blend under current weights.
Separate field status: CrUX / Search Console on their own slide or paragraph.
Use trends: three or more scheduled runs beat one paste after a deploy.
Open the calculator when a stakeholder wants to know how many milliseconds buy the next ten points.
Avoid score chasing at 99–100 unless the contract truly requires vanity greens; spend engineering time on user-visible LCP and TBT first.

Budgets work better on metric thresholds than on a single Performance integer, because the integer hides which metric moved. Pair score trends with LCP and TBT budgets on money URLs so engineering knows what to fix. A five-point score drop that is all TBT is a different ticket from one that is all CLS.

Where Apogee Watcher stores Performance scores

Apogee Watcher schedules PageSpeed Insights tests across multi-tenant portfolios and stores the lab category scores and metric payloads from those runs for trends, budgets, and alerts. That history is lab data under Google’s PSI/Lighthouse pipeline. It is not a substitute for CrUX percentiles, and it does not claim to weight INP inside the Performance blend.

Use Watcher when you need the same URLs retested on a cadence after deploys, with mobile and desktop strategies and client-ready charts. Use CrUX and Search Console for field Core Web Vitals when samples exist. Use the scoring calculator when someone asks how the 0–100 number is built. Layer the tools; do not collapse them into one green circle in a slide.

Start a free trial to schedule PageSpeed tests and keep Performance score trends beside metric budgets. Or run a free PageSpeed check on a priority URL and open the Lighthouse scoring calculator beside the result.

FAQ

Does Google use the Lighthouse Performance score as a ranking factor?

Google’s ranking systems use page experience signals tied to real-user Core Web Vitals concepts, not your lab Performance integer as a published ranking weight. Treat the score as an engineering and reporting aid. Use CrUX and Search Console for field status when data exists.

Why is Total Blocking Time in the score if INP is the Core Web Vital?

Lab runs need a synthetic interactivity signal during a single load. TBT fills that role inside the documented Lighthouse 10 Performance weights. INP is a field metric built from real interactions over a page life. Report both without merging them into one sentence.

Do Opportunities change the Performance score directly?

No. Only metric scores feed the weighted average. Opportunities and Diagnostics guide fixes that may improve those metrics on the next run.

Why did desktop scores change a lot after older Lighthouse versions?

Before Lighthouse 6, desktop runs could be scored against mobile-derived curves and look artificially strong. From v6 onward, desktop has its own scoring. Compare desktop history carefully across that boundary.

Can Apogee Watcher show how each metric score was weighted for a run?

Watcher stores the PageSpeed Insights / Lighthouse results from scheduled tests for trends and budgets. For interactive weight exploration, use Google’s scoring calculator and Chrome’s scoring documentation alongside your Watcher history.