Google Lighthouse: complete guide to auditing your website

What is Google Lighthouse and what is it actually for?

Google Lighthouse is an open-source audit tool developed by Google, natively integrated into Chrome DevTools since 2017. Its principle: load a page in a controlled context, measure a series of technical indicators, and produce a structured report with scores and actionable recommendations.

Lighthouse audits up to five categories: Performance, Accessibility, SEO, Best Practices, and PWA — the last of which was removed in Lighthouse 12 (May 2024). Each produces a score from 0 to 100.

What Lighthouse does not do: measure the experience of your real users. Every Lighthouse report is lab data — synthetic data produced under standardized conditions, on a virtual machine with an emulated device and a simulated connection. This is the fundamental limitation to internalize before everything else.

Lab data vs field data: the distinction that changes everything

Lighthouse = diagnosis under standardized conditions. CrUX = your audience's reality.

PageSpeed Insights combines both: the top section of the page shows CrUX field data (when available, which requires a minimum amount of traffic on the origin); the bottom section contains the Lighthouse lab report. Conflating these two sections accounts for the majority of misunderstandings around performance scores.

How to run a Lighthouse audit

Three methods, depending on context and the level of reproducibility required.

Chrome DevTools

1. Open the target page in Chrome
2. F12 → Lighthouse tab
3. Select categories and profile (Mobile or Desktop)
4. Click Analyze page load

For a reproducible run: open a private browsing window and disable all Chrome extensions. An ad blocker or password manager can alter the page's behavior and skew results.

PageSpeed Insights

PageSpeed Insights requires no installation. Enter a URL, get a Lighthouse lab report + CrUX field data in 30 seconds. It's the fastest method for a first read — and the only one that exposes both sources side by side.

Node.js CLI

For CI/CD audits or pages behind authentication:

npm install -g lighthouse

# Standard audit, mobile profile, HTML report
lighthouse https://example.com \
  --output html \
  --output-path ./report.html \
  --throttling-method=simulate \
  --emulated-form-factor=mobile

# Authenticated pages (example with session cookie)
lighthouse https://example.com/dashboard \
  --extra-headers '{"Cookie": "session=abc123"}' \
  --output json

The --budget-path option lets you fail a CI build if a performance threshold is exceeded — useful for preventing regressions on every deployment.

Variability: why two successive runs diverge

Running the same audit twice in a row can produce Performance scores that differ by 10 to 15 points. Three causes:

• CPU jitter: the virtual machine shares resources with other processes at run time
• Connection state: even with simulated throttling, resources travel across your local network to the server
• Network caching: a first run may initiate CDN connections that a second run finds already established

Practical rule: never draw conclusions from a single run. Run at least 3 consecutive runs and take the median.

Decoding the 5 score categories

Each Lighthouse audit produces up to five distinct scores. Only the Performance score is a numerical composite. The other four aggregate weighted binary audits (pass/fail).

The Performance score in detail

The score is not a simple average. Each metric is weighted, then transformed via a logarithmic curve to compress extremes. Current weightings (Lighthouse 12):

LCP + TBT = 55% of the score. Improving these two metrics produces the biggest shift. INP does not factor into the lab score — it is a field-only Core Web Vital that requires real interactions to be measured.

Color zones follow three thresholds: green (90–100), orange (50–89), red (0–49).

Accessibility: automated auditing doesn't see everything

An Accessibility score of 100 does not mean your site is accessible. Automated tools detect roughly 30 to 40% of WCAG issues. The rest — logical focus order, semantically empty alt text, keyboard navigation in complex components — requires manual testing with a screen reader.

SEO: an entry point, not an audit

Lighthouse's SEO score covers the fundamentals: <title> and meta description tags present, alt attributes on images, crawlable links, valid robots.txt. It says nothing about content quality, link profile, field Core Web Vitals, or crawl structure. It's a useful signal for catching glaring errors — nothing more.

The performance metrics that matter: LCP, INP, CLS, TBT, FCP, Speed Index

⏱️ ↓

0 ms

TTFB

🖼️ ↓

0 s

LCP

📐 ↓

0

CLS

🎯 ↑

0 /100

Score

Six metrics make up the Performance score. Three are official Core Web Vitals (LCP, INP, CLS), used by Google as ranking signals.

For full definitions, measurement mechanisms, and fix strategies, see the Core Web Vitals measured by Lighthouse page.

LCP — Time to display of the largest visible element in the viewport: hero image, text block, video with poster. This is the metric most impacted by CDN quality, image optimization, and render-blocking resources.

INP — Responsiveness to user interactions (clicks, keystrokes). Replaced FID as a Core Web Vital in March 2024. Measurable in the field only — in lab, Lighthouse uses TBT as an approximation.

CLS — Visual stability: accumulates unexpected layout shifts. Caused by images without declared dimensions, web fonts without font-display, late DOM injections (cookie banners, third-party widgets).

TBT — Total time the main thread is blocked for more than 50ms between FCP and TTI. An imperfect proxy for INP: a page with low TBT can still have high INP if interactions trigger heavy JavaScript post-load.

Lighthouse's limits: what the score doesn't tell you

This is the section most guides skip. Understanding it is what separates amateur use of Lighthouse from professional use.

The throttling profile doesn't match your audience

By default, Lighthouse mobile simulates a Moto G4 with a CPU 4× slower than the host machine, and a Slow 4G connection (1.6 Mbps, 150ms latency). This profile represents the bottom of the global device range — it was designed to push developers to optimize for everyone.

But if your real audience uses recent devices and fast connections, this profile is systematically pessimistic. Your score will be mechanically lower than your users' actual experience — and you risk prioritizing optimizations that don't improve their real-world lives.

Runs are always cold-cache

Lighthouse loads the page with no browser cache. Your real visitors return with a partially warm cache, already-established CDN connections, and resources in memory. The first load measured by Lighthouse is the worst case — legitimate as a regression signal, but misleading as a measure of average experience.

Red lab score, green field Core Web Vitals

The gap can be spectacular.

◆Field notes·8 years · 35+ clients

My field experience — Lighthouse score < 50, Core Web Vitals passed on CHANEL.

I worked with CHANEL for four years on their web performance. The mobile Lighthouse score for chanel.com showed red: FCP at 5.9s, LCP at 14.6s, Speed Index at 7.2s under PSI conditions. A report any uninformed client would read as "slow site, needs fixing urgently." The field reality was the opposite: LCP at 1.7s, INP at 177ms, CLS at 0 in CrUX data. Core Web Vitals passed globally — among the best scores in the luxury sector for web performance. The explanation: PSI emulates an old Moto G4 on Slow 4G, a profile with no relation to CHANEL's real audience, which uses premium devices and fast connections. On those actual devices, the edge CDN serves assets in milliseconds, and the optimizations deployed over those four years — modern image format rollout, INP optimizations — pay off where it counts. The lesson: Lighthouse's throttling profile is calibrated for the bottom of the global spectrum. If your audience is on premium devices, your lab score will always be lower than your field reality. Always cross-reference with CrUX before drawing a conclusion.

The TTI case: when Lighthouse removes a metric because it doesn't work

Up through Lighthouse 9, the Performance score included Time To Interactive (TTI) — a metric meant to measure "when the page becomes interactive." It was weighted at 10% of the score. It was removed in Lighthouse 10 (February 2023) and replaced by TBT. The reason? TTI was fundamentally unstable and poorly correlated with real user experience.

The core problem: TTI waits for a 5-second window with no Long Tasks (JS tasks exceeding 50ms) and at most 2 resources downloading in parallel. In practice, a single 51ms task reset the counter — a brutal threshold effect that made the metric highly sensitive to minor third-party JavaScript variations. On real sites with analytics, widgets, or A/B tests, TTI would swing widely between consecutive runs.

As Boris Schapira summarized in his analysis of the metric: TTI doesn't measure "the time before the page becomes interactive" — it's an assurance that from a certain point onward, there's no more jank. An important distinction, and counterintuitive for anyone reading "Time To Interactive" at face value.

This is a concrete example of how Lighthouse metrics evolve over time, and how today's metrics are not definitive. TBT, which replaced TTI, is itself an imperfect proxy for field INP — it measures main thread pressure at load time, not responsiveness to real interactions.

What Lighthouse doesn't capture at all

• Real INP: interactions require a real user. TBT does not reliably predict INP once heavy JS handlers fire post-load.
• Geographic performance: a run from your local machine. WebPageTest lets you test from Paris, Mumbai, São Paulo — on sites without a properly configured CDN, gaps regularly exceed 3s on LCP.
• Multi-page performance: Lighthouse audits one URL at a time. Internal navigation (SPA transitions, prefetch, Service Worker) is not captured.
• The actual state of the page: active A/B tests, personalization, filled cart, push notifications — none of this is reproduced in a synthetic run.

When to use what

To choose between PSI and WebPageTest depending on use cases, see the WebPageTest vs PageSpeed Insights comparison. To go further with a professional performance audit, Lighthouse is our starting point — never our only tool.

FAQ

Sources

• Lighthouse — official GitHub repository
• Lighthouse documentation — Chrome Developers
• PageSpeed Insights
• Web.dev — Core Web Vitals and web metrics
• Chrome UX Report (CrUX) — documentation
• Measuring Interactivity with TTI — Boris Schapira