PROVIDER Β· Open-source audit standard
Google Lighthouse
Google Lighthouse is Google's open-source audit tool built into Chrome DevTools, reporting performance, accessibility, best practices, SEO, and PWA scores in one run, and serves as the de facto standard for performance work and CI regression gates.
Pros
Cons
Product Information
Detailed Notes
Overview
Google Lighthouse is Google's open-source automated auditing tool, first shipped as a Chrome extension and built into Chrome DevTools after 2017, with a Node CLI and CI integrations alongside. One run reports performance, accessibility, best practices, SEO, and PWA scores, and it has become the shared vocabulary of Testing & Optimization work.
The value is not the score but the decomposition. Every deduction maps to a concrete metric such as LCP, CLS, or TBT and to a specific resource or code location, so most teams start optimising by clearing the red items in a Lighthouse report rather than buying tooling.
Know the limits. It defaults to a simulated mobile environment with synthetic data, scores shift a few points between runs on loaded machines, and it measures technical metrics rather than user perception, which means production needs real user monitoring to cross-check.
Core Strengths
- Free and open source under Apache 2.0 with no report limits, so anyone can reproduce the same scoring basis
- Five score groups per run covering performance, accessibility, best practices, SEO, and PWA
- Each deduction maps to a concrete metric and resource, and reports export as JSON for CI and dashboards
- CLI plus Lighthouse CI allow performance budgets in merge requests that block regressions
Product Ecosystem
Scores and diagnostics
The performance score weights LCP, TBT, CLS, FCP, and SI, with opportunities and diagnostics alongside. TBT is the most overlooked, since it governs interactivity yet gets skipped by teams watching only LCP.
CLI and CI integration
Installed via npm it runs anywhere, and Lighthouse CI asserts against multiple URLs. Set thresholds rather than chasing 100, since a budget of LCP under 2.5s and a score floor near 85 is far more sustainable.
Drawbacks
- Synthetic data and simulated networks diverge from real devices, so scores do not equal experience
- Single runs fluctuate by a few points on loaded machines, inviting misreads
- No coverage of real user distribution or long-tail devices without RUM
- SEO and best-practice advice is conservative and some items do not apply to Chinese sites
Use Cases
- Starting performance work (β β β β β ) - Free and standardised, the first stop for diagnosing speed issues
- Blocking regressions in CI (β β β β β ) - Lighthouse CI stops performance backslides in merge requests
- Competitive and industry benchmarks (β β β β β) - Compares key metrics across sites on one basis
- Real user experience assessment (β β ) - Needs RUM data, synthetic tests alone fall short
Pricing
| Plan | Price | Scope |
|---|---|---|
| The tool | $0 | Open source with no usage limits |
| DevTools and CLI | $0 | Built into Chrome and free via npm |
| Lighthouse CI | $0 | Open source, runs in your own CI |
The tool is free and the cost is interpretation and execution. The real investment is converting opportunities into engineering tasks and setting threshold-based budgets, since score-watching without budgets regresses within weeks.
FAQ
-
What score is good enough? There is no universal number. Content sites should aim above 85 with LCP under 2.5 seconds, while e-commerce and interaction-heavy sites can accept above 75 provided Core Web Vitals pass. A do-not-regress budget matters more than any absolute score.
-
Why is the score much worse in production? Local runs are faster with stable networks and no real traffic. Production adds third-party scripts, regional network variance, and concurrency, so validate with RUM or real devices, and check third-party scripts and CDN hit rate first when the gap is large.
-
Can it audit logged-in pages? Yes, by passing custom headers or cookies through the CLI, or logging in with Puppeteer before auditing. Never put production credentials in CI configs, and use a read-only test account.