A Google Lighthouse score is a lab Performance number from 0 to 100 for one controlled run. Scoring does not average raw milliseconds. Each metric is mapped through an HTTP Archive curve, then weighted into one score for a single URL and one device strategy.
Agencies usually meet that number as the green or amber circle in PageSpeed Insights. Clients treat it as "Google speed." It is neither a ranking factor by itself nor a field Core Web Vitals percentile. It is recorded under simulated conditions, then calculated with documented weights that change across Lighthouse majors.
TL;DR: Record lab metrics in a throttled run, convert each to a 0–100 metric score, apply Lighthouse 10 weights (TBT 30%, LCP and CLS 25% each, FCP and Speed Index 10% each), and report the blend as lab only. Keep CrUX and Search Console on a separate slide. Chrome’s Lighthouse performance scoring guide is the source of truth; what follows is the agency translation, including a worked example and FAQ.
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.
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.
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.
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.
Suppose a mobile lab run produces these metric scores (already mapped through the curves; not raw milliseconds): FCP 90, Speed Index 85, LCP 70, TBT 60, CLS 95. Apply the Lighthouse 10 weights:
- FCP: 90 × 0.10 = 9.0
- Speed Index: 85 × 0.10 = 8.5
- LCP: 70 × 0.25 = 17.5
- TBT: 60 × 0.30 = 18.0
- CLS: 95 × 0.25 = 23.75
Sum ≈ 76.8, which rounds to a Performance score in the mid-70s (needs improvement). The same raw LCP in milliseconds can yield a different metric score when the curve or Lighthouse major changes, so always cite the version beside the number. Open the Lighthouse scoring calculator to poke individual levers before you promise a client that "ten points is one easy fix."
Lighthouse version footnote: Weights and curves above follow Chrome’s documented Lighthouse 10 Performance scoring. PageSpeed Insights and CI runners may ship a different major. When you compare quarters or tools, record the Lighthouse version (or PageSpeed Insights date) on the report. A five-point swing across a major upgrade can be scoring math, not a regression.
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.
Mid-article check: run the URL you are arguing about
Before you debate a screenshot in Slack, run a free PageSpeed check on the same URL and strategy (mobile or desktop). Pair the lab Performance score with the metric breakdown, then keep the scoring calculator open so stakeholders see how LCP, TBT, and CLS drive the blend. Scheduled history in Apogee Watcher beats one heroic paste after a tag-manager change.
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.
- 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.
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.
What is a Google Lighthouse score?
A Google Lighthouse score usually means the Performance category (0–100) from one lab audit, alongside Accessibility, Best Practices, and SEO category scores. The Performance number is the weighted blend covered here. It is not an average of real-user timings and not a Search Console field status.
How does Lighthouse scoring work?
Recording comes first: Lighthouse loads the URL under a fixed device and throttling profile and measures lab metrics (FCP, Speed Index, LCP, TBT, CLS under current docs). Calculation comes second: each metric maps to a 0–100 metric score via log-normal HTTP Archive curves, then those metric scores are weighted into the visible Performance number.
What is a good Lighthouse Performance score?
Chrome’s colour bands: 0–49 poor, 50–89 needs improvement, 90–100 good. "Good" means that lab run cleared 90 under that profile, not that every visitor on every network had a green experience. Chasing 99–100 is usually vanity; spend engineering time on user-visible LCP and TBT first.
How do lab Lighthouse scores differ from PageSpeed Insights and CrUX?
PageSpeed Insights shows a Lighthouse lab block and, when eligible, a CrUX field block on the same page. The lab circle is Lighthouse scoring. CrUX is aggregated Chrome field data (percentiles for LCP, INP, CLS), not the weighted 0–100 Performance blend. For when to lean on synthetic lab runs versus real-user monitoring, see when to use synthetic versus real user monitoring. Do not collapse "the PageSpeed Insights score," "Lighthouse," and "Core Web Vitals" into one sentence in a client deck.
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.
