Lighthouse calculates its performance score from weighted metric scores, not from the number of warnings in a report. Each raw measurement first passes through a scoring curve, so the relationship between milliseconds saved and points gained is not linear. To compare two results fairly, keep the Lighthouse version, device profile, throttling and page state consistent, then examine several runs alongside real-user data.
Read the version before interpreting the weights
The latest software release listed by the Lighthouse project when checked on October 17, 2026 was v13.5.0. That does not establish which version a particular PageSpeed Insights request or installed Chrome build used. Distribution schedules and your local browser installation can differ. The report's version is the relevant one for a comparison.
There is also a documentation distinction worth preserving. Chrome's general scoring page still labels its familiar table “Lighthouse 10.” The current Lighthouse main-branch configuration inspected for this article shows the same five nonzero weights. Access to the tagged v13.5.0 configuration could not be verified, so the table below describes the inspected main configuration and the documented Lighthouse 10 model, not a separately verified v13.5.0 release configuration. For a version-pinned audit, inspect that audit's JSON as shown below.
These are the verified weights in those two sources.
| Metric | Weight | What the result describes |
|---|---|---|
| First Contentful Paint (FCP) | 10% | When the first qualifying content appears |
| Speed Index (SI) | 10% | How quickly visible content fills in during loading |
| Largest Contentful Paint (LCP) | 25% | When the largest qualifying visible content appears |
| Total Blocking Time (TBT) | 30% | Blocking portions of long main-thread tasks in the measurement window |
| Cumulative Layout Shift (CLS) | 25% | Unexpected movement measured during the audited load |
The inspected configuration also lists INP with zero weight. A standard navigation score is therefore not an INP score. TBT can help identify main-thread work that deserves investigation, but substituting TBT for real-user INP changes the question being answered.
Changes to report organization do not automatically change scoring. Lighthouse 13 consolidated older performance audits into insights; its release announcement explicitly said that this did not change the performance score. An audit disappearing under its old name is not evidence that the underlying problem stopped mattering.
Convert measurements to scores before averaging
A raw LCP value is a duration. A CLS value is unitless. Adding those values directly would have no meaningful interpretation. Lighthouse first maps each measurement onto its own score, then combines the resulting scores according to their weights.
Google describes the metric scoring distributions as log-normal curves informed by HTTP Archive data. The curve means equal improvements in a measurement do not always produce equal score gains. An improvement near a steep part of the curve may move the score visibly, while a similar improvement near the top may hardly change the displayed integer. Mobile and desktop scoring are not interchangeable either: their configurations and scoring expectations differ.
For arithmetic only, imagine that all metric scores except TBT remain unchanged and TBT's normalized score improves by 10 points on a scale from 0 to 100. With a 30% weight, its contribution to the overall score improves by 3 points before display rounding. This is a hypothetical calculation, not a benchmark or a promise that a specific code change will produce that improvement.
The important distinction is between a metric value and its metric score. Removing 100 milliseconds of work does not mean adding 100 points, or even a fixed number of points. The starting value, scoring curve, measurement window and other metrics all matter. An optimization may also affect several metrics at once, making simple predictions even less reliable.
Use the official scoring explanation to understand the model. Use the values in your own report to choose an engineering task. A small score change can accompany a meaningful improvement in a slow page element, particularly when another metric is still limiting the total.
Warnings identify causes rather than direct point deductions
A render-blocking stylesheet does not carry a universal penalty of a fixed number of points. Its effect depends on whether it delays content that contributes to the measured metrics. Similarly, an unused script warning signals work that may be removable; the label itself is not an additional weighted metric.
This prevents two common mistakes. First, clearing every visible warning is not the same as improving the experience. Second, adding the estimated savings from several insights does not produce a reliable total saving. Suggestions can overlap, depend on the same request chain or change the browser's scheduling when applied together.
Read the request waterfall and main-thread timeline before making the change. If the largest image is discovered late, that is a different problem from an image discovered promptly but downloaded slowly. If JavaScript monopolizes the main thread, start with reducing JavaScript execution time rather than repeatedly recompressing an already small image.
Keep the individual metrics in a comparison record even when management wants a single score. A higher total can conceal a regression in one component. For example, a favorable CLS change could outweigh slower content delivery in the weighted total. The total alone cannot tell you whether that trade-off is acceptable for your page.
Control the conditions that make scores fluctuate
Lighthouse measures a running system. Background CPU activity, browser extensions, changing advertisements, experiments, cache state, network routing and backend load can all alter what happens during a run. A browser that injected an extension's script is no longer observing the same workload as a clean browser.
Throttling introduces another comparison boundary. Simulated throttling estimates performance from an observed trace, while applied throttling constrains the run itself. A number obtained under one method should not be treated as an exact repeat of a number obtained under another. Keep the method fixed and record it with the report.
The same URL may also return different experiences. A consent banner, authenticated account, location-dependent content or an active experiment can change the DOM, requests and scripts. Record the state being tested instead of assuming the URL fully identifies the experiment. Test meaningful states separately when both occur in production.
A cold first visit and a repeat visit deserve separate attention. A cached font or script can change the critical path, while a cached HTML response can change server timing. Preserve the intended cache policy across baseline and candidate runs. Do not compare a cold baseline with a warm candidate and attribute the entire difference to your code change.
Use an idle, stable machine for local comparisons. Close unrelated heavy applications, avoid running several audits concurrently and use a clean browser profile. Keep power settings consistent. These steps reduce avoidable noise; they do not turn a laptop into a representative sample of all visitors.
Run a reproducible command-line comparison
The CLI is useful because its command, package version and output can be saved together. It requires a compatible Node.js installation and Chrome or Chromium. Check the selected Lighthouse package's runtime requirements before installation. The commands below select the release observed during research; they are illustrative and were not executed against example.com for this article.
Save five separate JSON reports with one pinned package version and the default mobile configuration.
mkdir -p lighthouse-reports
for run in 1 2 3 4 5; do
npx --yes [email protected] https://example.com/ --only-categories=performance --chrome-flags="--headless" --output=json --output-path="lighthouse-reports/mobile-${run}.json"
doneFive runs are a practical starting sample, not a statistical guarantee or an official pass requirement. Use the same procedure for a baseline and a candidate. If results span a wide range, find the source of variation before deciding that a small difference represents progress.
Read the version, nonzero weights and score from a saved report instead of inferring them from a screenshot.
// inspect-lighthouse.mjs
import { readFileSync } from 'node:fs';
const file = process.argv[2];
if (!file) throw new Error('Pass a Lighthouse JSON report path.');
const report = JSON.parse(readFileSync(file, 'utf8'));
const performance = report.categories.performance;
console.log('Lighthouse version:', report.lighthouseVersion);
console.log('Performance score:', performance.score);
console.table(performance.auditRefs.filter(({ weight }) => weight > 0));Run the script against the first saved report.
node inspect-lighthouse.mjs lighthouse-reports/mobile-1.jsonThe JSON score is normalized, so a value of 0.9 corresponds to 90 before considering display formatting. Retain the complete reports, not only their scores. They contain settings and metric results needed to explain a difference later. If you need a desktop comparison, run a separate set using --preset=desktop; do not combine those results with the mobile set.
Use medians without hiding the spread
Order repeated scores and report the middle value as a simple median. Also retain the lowest and highest result and the individual metric values. A median is less sensitive to one unusually slow or fast run, but it cannot repair a poorly controlled test.
Do not manufacture a synthetic “best report” by taking the fastest LCP from one run, the lowest TBT from another and the lowest CLS from a third. That combination never occurred. Keep a representative report and the complete set so the relationship between measurements remains visible.
A useful comparison note contains the tested URL and revision, test state, browser and Lighthouse versions, device profile, throttling method, run count, median score and relevant metric spread. Add the change being investigated and any known environmental difference. The result becomes reproducible evidence rather than a number detached from its conditions.
PageSpeed Insights, DevTools and the CLI are different entry points with potentially different versions and environments. The PageSpeed Insights guide explains how to read that report. When two entry points disagree, first compare their settings and measured states; do not assume one is wrong because it produces the lower score.
Turn the score into the next useful measurement
A score of 100 is a rounded laboratory outcome under particular conditions, not a certificate that every visitor has a fast experience. It does not test every route, interaction, device, language or session length. Later layout shifts and slow interactions can remain invisible to an initial navigation audit.
Keep field data and lab data beside each other. Use controlled testing to explain a change quickly, then examine real-user measurements to see whether the intended audience benefits. Differences between them can identify a missing test condition instead of invalidating either dataset.
For the next iteration, pick one slow metric, identify its request or main-thread cause and make one reviewable change. Save a repeatable baseline through the PageSpeed analyzer when it is configured, or through the CLI above. Continue with the relevant page speed optimization guide after the measurement points to a cause. The useful target is a demonstrated improvement that survives repeat testing and reaches users.
