Lighthouse 13: Auditing Web Pages with a Node CLI, DevTools Panel, and Programmatic API

What Lighthouse Actually Measures

Lighthouse is a tool that loads a URL in Chrome and runs a set of audits. The README says it collects modern performance metrics and insights on developer best practices. It covers performance, accessibility, SEO, and common quality problems. The target user is a web developer who wants a repeatable, automated check of a page, either in DevTools, from the command line, or inside a build pipeline. It is not a monitoring tool. It does not watch a site over time. Each run is a snapshot of one page under controlled conditions. That distinction matters when you decide where it fits.

The Gather and Audit Lifecycle

Lighthouse separates its work into two phases: gathering and auditing. The CLI exposes this with `--gather-mode` (`-G`) and `--audit-mode` (`-A`). In gather mode, Lighthouse launches a browser, collects artifacts, and saves them to disk, then quits. In audit mode, it skips browser interaction, loads the saved artifacts, runs audits, and generates a report. You can combine both with `-GA` to do a normal run and also save artifacts for later. This split is useful for debugging and for re-running audits without touching the network. The README shows `lighthouse -GA=./gmailartifacts https://gmail.com` to store artifacts in a custom folder. Without a value, the default is `$PWD/latest-run`. This is a concrete mechanism that most casual users never touch, but it is the backbone of reproducible runs.

Running Lighthouse from the Command Line

The Node CLI is the most flexible entry point. Installation is global via `npm install -g lighthouse` or `yarn global add lighthouse`. The basic invocation is `lighthouse https://airhorner.com/`, which writes an HTML report to `./<HOST>_<DATE>.report.html`. You can change the output format with `--output`. For example, `lighthouse --output json` sends JSON to stdout, and `lighthouse --output html --output-path ./report.html` saves to a specific file. A notable quirk: when you specify an output path with multiple formats, Lighthouse ignores your extension for all formats. The README shows `lighthouse --output json --output html --output-path ./myfile.json` producing `myfile.report.json` and `myfile.report.html`. That is a small trap if you expect the path to be honored literally. The CLI also supports `--save-assets` to keep trace contents and devtools logs, and `--list-all-audits` to print every available audit.

Using Lighthouse as a Node Module

Beyond the CLI, Lighthouse can be called programmatically from Node. The README points to docs/readme.md and docs/configuration.md for details. This opens the door to custom integrations: you can run audits inside a test suite, a CI job, or a custom reporting tool. The configuration file lets you adjust which audits run and how they are weighted. The README does not show a code sample, so you will need to consult the linked docs for exact API calls. What is clear is that the Node module is the intended path for automation. If your project already uses Node, this avoids a separate global install. The trade-off is that you must manage the dependency and its Node version requirement yourself.

Where Lighthouse Falls Short

Lighthouse is a lab tool. It runs a single page load in a controlled browser, not real user traffic. The README does not claim otherwise, but the limitation is easy to forget when you see a score. Variance is a known issue: the repository includes docs/variability.md, which presumably explains why scores change between runs. Network throttling is configurable, and the FAQ mentions it, but you have to read the docs to tune it. Another gap is that Lighthouse does not test authenticated flows or multi-page journeys out of the box. You can extend it with custom audits, but the README only hints at that in the FAQ. For a team that needs continuous monitoring or real-device data, Lighthouse alone is the wrong tool.

The Alternative: Real-User Monitoring and Other Auditors

If Lighthouse is a synthetic, lab-based audit, the direct alternative is a real-user monitoring service like Google's own CrUX or a commercial product such as SpeedCurve or Calibre. Those tools collect field data from actual visitors, so they capture network conditions, device types, and user interactions that Lighthouse never sees. The approach differs fundamentally: Lighthouse controls the environment to isolate page performance; RUM measures the messy reality. Each has its place. Lighthouse gives you a reproducible baseline and a clear list of actionable audits. RUM tells you what real users actually experience. A common pattern is to run Lighthouse in CI to catch regressions and use RUM to track long-term trends. The README lists integrations with Web Perf services, which suggests many teams combine them.

Maintenance, Licensing, and Upgrade Cost

Lighthouse is an active project under the Apache-2.0 license. The last push was July 2026, with v13.4.1 released that same day. The project is not archived. The README states that Lighthouse requires Node 22 (LTS) or later. That is a hard constraint: if your environment is on Node 20, you cannot run the current version. Upgrading Lighthouse between major versions may change audit behavior or scoring, so you should pin the version in your package.json or CI config. The license is permissive, so you can use it in commercial products without paying a fee. The main cost is keeping up with new releases and re-baselining your scores when audits change. The project also asks for anonymous error reporting on first CLI run, which you can opt out of.

What to Verify Before You Adopt

Before you commit to Lighthouse, check three things. First, confirm your Node version is 22 or later. Second, decide whether you need the gather/audit split for your CI pipeline. The `-G` and `-A` flags are powerful, but they add complexity. Third, read docs/variability.md to understand why scores fluctuate. If you plan to run Lighthouse in a build, you should also test how long a run takes on your slowest page. The CLI has a `--quiet` flag to suppress output, which is useful in CI logs. Finally, if you need to compare scores across time, remember that a single run is not enough. You will need to run multiple times and average, or accept the variance. The README does not promise stability, and the docs exist precisely because scores are not perfectly reproducible.

Editorial conclusion

Adopt Lighthouse if you need a free, scriptable audit of performance, accessibility, SEO, and best practices, especially if you already use Chrome and Node 22+. Skip it if you need real-user monitoring or continuous in-browser measurement; Lighthouse runs synthetic, lab-based audits. Before relying on it, verify your Node version meets the 22 LTS requirement, test the gather/audit split for your CI workflow, and confirm you can handle the variance documented in docs/variability.md. Then run `lighthouse https://your-site.com --output json --output-path ./report.json` to see the raw data behind the scores.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes