Four audit categories cover the page, not the whole product
The CLI exposes 4 main categories: performance, accessibility, best practices, and SEO. A run launches Chrome, gathers page artifacts, applies audits, and writes an HTML report by default. JSON and CSV outputs make the same findings usable in scripts. Chrome DevTools is the easiest route for a developer inspecting the current tab, while the CLI adds flags for throttling, device emulation, selected audits, extra headers, saved traces, and output paths.
That friendly report sits on a large codebase. Our checkout contained 1,518 files, about 149,990 lines of source, and 219.3 MB before installation. The repository includes the core runner, report renderer, browser clients, localization, fixtures, and build tooling. A team embedding Lighthouse through its Node module should pin the package and the Chrome environment rather than treating the score as a simple HTTP API whose behavior stays fixed independently of its browser.
Node 22 and local Chrome are required for the CLI
The README requires Node 22 or later and a local Chrome installation. A basic command takes one URL and writes a dated report, while CHROME_PATH selects a specific browser binary. Mobile emulation and network or CPU throttling are enabled through configuration. The run happens locally, and the FAQ says reports are not processed by a remote server. That makes the CLI suitable for private preproduction pages when the test machine can reach them.
Authenticated pages need deliberate session handling. Lighthouse normally loads a page as a new user, with no prior storage. The docs describe 4 working paths: script login with Puppeteer, use the logged-in DevTools tab, pass headers, or connect to a prepared debugging browser. Sharing is a separate privacy choice. The online viewer can open a local JSON report, while its share action requires GitHub sign-in and saves the report as a secret Gist.
What happened when we ran it
Our sandbox installed 1,036 Yarn packages in 95 seconds and consumed 586 MB on disk. The harness found no supported build script or target, so it skipped build rather than marking it successful or failed. The repository README gives contributors a separate build-all command, but our measured result covers only what the harness invoked. This was commit 7d21d0b in an unprivileged container with 3 CPUs, 8 GB of RAM, and no secrets.
The test command failed with exit code 1 after 4 seconds. Its final useful error says Node tried to open dist/report/flow.js and could not. The log tail does not establish why that file was absent, so we cannot say whether a particular build command, package state, or repository defect caused it. Our scan found 7 CI workflow files, no Dockerfile, and no tests directory. The fresh checkout simply did not pass the test step we ran.
Repeated controlled runs matter more than one green score
Lighthouse's own variability guide lists changing page behavior, network conditions, server response, client hardware, resource contention, and browser scheduling as sources of movement. It recommends consistent hardware, isolated runs, and aggregate values from multiple attempts. A single performance score can be useful for finding a severe regression, but it is weak evidence for a small improvement. Accessibility and SEO audits also catch detectable rules, not every usability or search problem.
Our 3-CPU, 8 GB sandbox result measured repository setup and tests; it did not audit a target website or produce a performance score. That boundary prevents a common category error. Before making Lighthouse a release condition, run the actual production-like page several times on stable hardware, preserve the JSON, and compare distributions. Pair those lab results with field data if real users matter. The web-vitals library is a narrower option for measurements collected during actual visits.
The CLI is strongest as an engine inside a repeatable process
Saved gather artifacts let teams collect browser data once and audit it later, which helps separate collection from report generation. Custom configurations can select audits or add new gatherers, and plugins can package specialized checks. Output in 3 formats also makes it straightforward to archive a human report while parsing JSON for a dashboard. These are strong building blocks, though Lighthouse itself does not supply a full history, alert policy, or multi-page crawler.
Lighthouse CI is the natural companion when every commit needs several samples and budget assertions. sitespeed.io is a better fit for broader site runs and long-term performance records. The raw Lighthouse CLI remains useful for a developer who wants one trace-rich inspection without operating a monitoring service. Its 586 MB installed footprint and browser requirement are acceptable on a dedicated CI worker, but costly in a small utility container used for many unrelated checks.
v13.4.1 is active despite 469 open items
GitHub recorded a September 10, 2026 push, 30,758 stars, 428 open issues, and 41 open pull requests. Release v13.4.1 was published on July 20 after four earlier v13 releases between April and June. The latest repository activity included merged test and browser-integration work. That combination shows current maintenance and a large support surface; the 469 combined items should not be read as 469 confirmed bugs.
Lighthouse earns its place in a web team's diagnostic kit because the browser integration, audit explanations, saved artifacts, and machine-readable output are useful together. The source checkout was less tidy in our run: 1,036 packages installed cleanly, then tests stopped on a missing report file. Most users should consume the released tool, repeat important runs, and keep real-user evidence beside the lab report before a score blocks deployment.