Lighthouse Performance

1. Thresholds — reads formFactor, warningBelowScore and failBelowScore. When failBelowScore is not lower than warningBelowScore the audit fails with a single check (401) and Lighthouse does not run.

2. Lighthouse run — runs the Lighthouse CLI (version pinned in the image, reported in the 100 check) with the performance category only, the desktop preset or the mobile form factor, and the 37AuditsBot user agent. The run has a time budget derived from the audit's remaining time; a page that does not finish loading inside it is an ERROR (500).

3. Lab metrics — five metrics of the same run are judged against the fixed good / needs-improvement / poor bands Lighthouse and web.dev publish: Largest Contentful Paint (2.5 s / 4 s), Cumulative Layout Shift (0.1 / 0.25), Total Blocking Time (200 ms / 600 ms, the lab stand-in for Interaction to Next Paint), First Contentful Paint (1.8 s / 3 s) and Time to First Byte (800 ms / 1800 ms). Good is a SUCCESS check (201–205), needs improvement a WARNING (301–305), poor a FAIL (402–406). These bands are not preferences, and the metric checks never change the status of the result. A metric Lighthouse did not measure produces no check.

4. Blocked or unloadable page — an HTTP 403, 429 or Cloudflare challenge on the document is the platform's blocked response (590). Any other Lighthouse runtime error (NO_FCP, PAGE_HUNG, DNS_FAILURE, ERRORED_DOCUMENT_REQUEST, …) is an ERROR (500) that names the error.

5. Score — the Performance score (0–100) is compared with the thresholds: below failBelowScore is FAIL (400), from failBelowScore up to but excluding warningBelowScore is WARNING (300). A category Lighthouse could not score is an ERROR (501). At or above warningBelowScore the audit succeeds (200).

6. Audits — every audit Lighthouse lists under the Performance score becomes a check: a scored audit below Lighthouse's pass mark (0.9) is a FAIL whose code is 400 plus the audit's fixed number in this auditor's catalog (35 audits, 410–448); an audit Lighthouse reports without a score or leaves to a manual check is an INFORMATION with 100 plus that number. An audit a newer Lighthouse adds gets 490 or 190 until the catalog is updated. Hidden Lighthouse audits and audits that do not apply to the page are not reported. The five metrics have their own rules (above), so they are not repeated here. These checks keep their own status but never change the result: the score alone decides it.

7. Report pin — every result carries an INFORMATION check (100) with the Lighthouse and Chrome versions, the device profile, the run duration and Lighthouse's benchmark index, because scores are only comparable between runs of the same Lighthouse version.

The Lighthouse navigation is not signed with Web Bot Auth: Lighthouse opens its own browser target and its only header hook adds headers to every request of the page, which breaks cross-origin fetches. Allowlist the 37AuditsBot user agent if the site challenges unsigned bots. With Basic auth the Authorization header is sent on every request the page makes, third-party origins included, so prefer allowlisting over credentials for a staging site that loads third-party scripts.

Preferences

An invalid value (missing, fractional, outside 0–100) makes the auditor fall back to that preference's default and log a warning. A fail threshold equal to or above the warning threshold is not an invalid value: it makes the audit fail (401) until the thresholds are fixed.

Every row maps to one checkRule* method and one CheckCode.

Each metric check carries in data: metric, value (milliseconds, or the unitless shift), goodUpTo, poorAbove and band, plus the shared fields. Every check also carries metrics (firstContentfulPaintMs, largestContentfulPaintMs, totalBlockingTimeMs, cumulativeLayoutShift, speedIndexMs, timeToFirstByteMs).

The score check carries in data: category, score, formFactor, both thresholds, failingAudits (up to ten audits of the category below Lighthouse's pass mark, lowest score first, each with id, title, score, displayValue), lighthouseVersion, chromeVersion, benchmarkIndex, elapsedSeconds and runWarnings. Each audit check (1NN, 4NN) adds auditId, auditTitle, auditScore (0–100 or null), scoreDisplayMode, displayValue, weight, group, numericValue, numericUnit, learnMore (Lighthouse's documentation link), inCatalog, itemCount and items (up to ten rows of Lighthouse's details table: DOM nodes reduced to selector, snippet, label and explanation; source locations to url:line:column).

Lab scores vary between runs

Lighthouse measures one load in a controlled environment. The Performance score depends on the host's CPU and the network at that moment, and typically moves a few points between runs of the same page. Treat a single point of change as noise; set the thresholds with a margin and watch the trend across audits. The benchmarkIndex in the 100 check says how fast the host was during the run.

Desktop and mobile are different bars

The desktop preset applies no CPU slowdown and a fast network, so its Performance score is normally much higher than the mobile one. Pick the profile that matches the audience and keep it, because the scores of the two profiles are not comparable.

Lab metrics are not field data

Lighthouse reports lab metrics, not what real visitors experience. Core Web Vitals in Google Search Console come from Chrome users (field data); a page can score well here and still fail Core Web Vitals in the field, or the reverse. Use this auditor to catch regressions early and the field data to confirm the user impact.

The run is unsigned

The Lighthouse navigation carries the 37AuditsBot user agent but no Web Bot Auth signature. A site that only admits signed bots answers with a challenge, which this audit reports as blocked (590).

The score alone decides the result

Lighthouse weighs its audits into the score, so a page can score 95 with one audit failing. The result follows the score, as Lighthouse's gauge does: that page is a SUCCESS. The failing audit is still listed as a FAIL check, because the item is what the owner has to fix, but it never changes the status of the result, and neither do the lab-metric checks. The check order follows Lighthouse's report: heavier audits first, then the lowest scores.

Codes are fixed per audit

Each audit keeps its number across Lighthouse upgrades, so a deep link to a code stays valid. An audit a newer Lighthouse adds is reported with 490 (failing) or 190 (informative or manual) and inCatalog: false in its data until the catalog in this auditor is extended; an audit Lighthouse removes keeps its number unused.

This documentation is built and hosted on Mintlify, a developer documentation platform.