What is Lighthouse?

What is Lighthouse?

Lighthouse is an open-source, automated auditing tool developed by Google that evaluates web pages across four categories: Performance, Accessibility, Best Practices, and SEO. Originally released in 2016 as a Chrome extension, it's now built directly into Chrome DevTools (available under the "Lighthouse" panel since Chrome 60). Each category produces a score from 0 to 100, calculated from weighted metrics — for example, the Performance score in Lighthouse 12 weights Largest Contentful Paint at 25%, Total Blocking Time at 30%, and Cumulative Layout Shift at 25%. Lighthouse runs in a simulated throttled environment by default, emulating a mid-tier mobile device on a slow 4G connection. This makes scores reproducible but often lower than real-user data from CrUX. We run Lighthouse on every staging deploy across our projects — it's the fastest way to catch performance regressions before they hit production.

How it works

Lighthouse can run in three ways: Chrome DevTools, the lighthouse npm CLI, or as a Node module. Under the hood, it launches a headless Chrome instance via the Chrome DevTools Protocol, navigates to the target URL, and collects trace data and network logs during page load.

Here's a basic CLI run:

npx lighthouse https://example.com --output=json --output-path=./report.json

The tool executes a series of "gatherers" that collect page artifacts (DOM snapshots, network requests, JavaScript execution traces), then runs "audits" against those artifacts. Each audit produces a pass/fail or numeric result. The audits are then weighted and aggregated into the four category scores using a weighted-mean formula.

Key detail: Lighthouse uses simulated throttling by default (Lantern engine), not applied throttling. Lantern models network and CPU constraints mathematically from unthrottled trace data. This is faster and more consistent than true network throttling but can diverge from real-world results — especially on pages with complex request waterfalls or heavy client-side rendering.

Scores are color-coded: 0–49 red, 50–89 orange, 90–100 green. But a single run's score can vary by 5–10 points due to server response times, third-party scripts, and local machine load. Google recommends running 3–5 times and taking the median. We automate this in CI using lighthouse-ci with assertions that fail the build if Performance drops below 80.

When to use it

Lighthouse is your go-to for lab-based, repeatable performance audits during development. It catches issues before users see them.

Use Lighthouse when:

• You need a quick health check during development or code review
• You're setting up CI/CD performance budgets (pair with lighthouse-ci)
• You want actionable, specific recommendations ("Defer offscreen images", "Reduce unused JavaScript")
• You're auditing accessibility compliance — it covers ~57% of WCAG 2.2 Level AA checks
• You need an SEO baseline (meta tags, crawlability, structured data validation)

Don't rely on Lighthouse alone when:

• You need real-user performance data — use CrUX or a RUM tool instead
• You're debugging intermittent issues in production (field data tells a different story)
• You're comparing scores across different machines without controlling for hardware variance
• You're optimizing for a specific geography — Lighthouse simulates one connection profile

We treat Lighthouse as the "smoke test" and Core Web Vitals field data as the "source of truth."

Lighthouse vs alternatives

PageSpeed Insights actually runs Lighthouse under the hood for its lab data, then pairs it with CrUX field data. If you only pick one tool, PSI gives you both views. But for CI automation and repeatable testing during development, the Lighthouse CLI is what you want.

Real-world example

On a recent Next.js 15 e-commerce project, our staging Lighthouse Performance score dropped from 92 to 64 after adding a third-party reviews widget. The Lighthouse report pinpointed the cause: the widget loaded 340 KB of render-blocking JavaScript and added 1.8 seconds to Total Blocking Time. We wrapped the widget in a dynamic import with next/dynamic and set loading: 'lazy', plus deferred it behind an Intersection Observer so it only loaded when the reviews section scrolled into view. The next Lighthouse run came back at 89. More importantly, CrUX data confirmed the fix two weeks later — the page's 75th-percentile TBT in the field dropped from 1,400 ms to 380 ms. That's the pattern: Lighthouse finds it fast, field data confirms it matters.