What Is Google Lighthouse and What Does Its Report Actually Tell You?
Google Lighthouse is an open-source automated auditing tool that loads a page in a real (headless) browser and scores it across five categories: Performance, Accessibility, Best Practices, SEO, and PWA. You run it from Chrome DevTools, the command line, or through PageSpeed Insights, and you get a report in roughly under a minute. It is most useful as a single-page diagnostic: it tells you what is slow or broken on that URL and what to change. It is not a site-wide crawler, so if you need to audit many pages at once, pair it with a broader audit platform.
Where Lighthouse runs
| Entry point | Best for | Notes |
|---|---|---|
| Chrome DevTools (Lighthouse panel) | Ad-hoc checks on the page you're viewing | Runs against your local session, including pages behind a login |
| PageSpeed Insights | Quick public check plus field data | Combines lab (Lighthouse) scores with real-user CrUX data when available |
| Lighthouse CLI / Node module | Scripting, CI, repeatable runs | Lets you fix throttling and run the same config every time |
All three use the same underlying audit engine, so the category list and metric definitions are consistent. What differs is the environment and whether you get real-user data alongside the lab run.
The five categories
- Performance — how fast the page renders and how stable it is, scored from lab metrics.
- Accessibility — automated checks against WCAG rules: color contrast, alt text, form labels, heading and landmark structure, ARIA roles, focus order.
- Best Practices — general web hygiene: HTTPS, safe libraries, correct image aspect ratios, console errors.
- SEO — basic on-page signals: title, meta description, crawlability, legible font sizes, tap target spacing.
- PWA — installability and offline behavior. Only relevant if you're building a progressive web app; most sites can ignore it.
How the Performance score is built
The Performance number is a weighted blend of lab metrics, not a direct measurement of "speed." The core ones:
- FCP (First Contentful Paint) — when the first text or image appears.
- LCP (Largest Contentful Paint) — when the main content element finishes rendering. Usually the heaviest-weighted metric.
- TBT (Total Blocking Time) — how long the main thread is blocked by long tasks, which delays interactivity.
- CLS (Cumulative Layout Shift) — how much visible content jumps around during load.
- Speed Index — how quickly content is visually populated.
Each metric is compared against Google's thresholds and mapped to a 0–100 sub-score, then the sub-scores are combined with fixed weights. That's why two pages with the same LCP can still score differently — TBT or CLS can drag one down.
Reading the report and prioritizing fixes
Work top-down by impact, not by the order audits are listed:
- Start with the metric that scored worst. If LCP is red, fix the largest element (usually a hero image or heading). If TBT is red, look for long JavaScript tasks.
- Read the "Opportunities" section. These are estimated savings — e.g. "Properly size images," "Eliminate render-blocking resources," "Reduce unused JavaScript." Each one links to the exact elements involved.
- Check "Diagnostics" for context the opportunities don't cover, like DOM size or main-thread work breakdown.
- Fix accessibility and SEO items in the same pass. They're usually cheap: missing alt text, low contrast, a missing meta description.
The report tells you what failed and points at the elements; it does not rewrite your code. Treat each failing audit as a task with a specific target.
Why scores vary between runs
Lighthouse is a lab tool, so results depend on the run conditions:
- Throttling — default mobile emulation simulates a slow 4G connection and a mid-tier CPU. Change it and the score changes.
- Third-party scripts — ads, analytics, and A/B tools load inconsistently and can swing TBT.
- Server response time — a slow backend on one run inflates FCP and LCP.
- Browser extensions and local state — DevTools runs can be affected by what's loaded in your session.
To get consistent numbers: run the CLI with a fixed config, run several times and compare the median, and test in a clean profile or CI environment rather than your daily browser.
When Lighthouse isn't enough
Lighthouse audits one URL per run. It won't tell you that 40 of your 500 pages share the same broken template, and it doesn't track whether a fix held after the next deploy. For that you need a tool that crawls the whole site and re-checks over time.
For example, a platform like Repolog runs a headless browser against your page and executes 60+ checks in one pass — SEO, Core Web Vitals pulled from Lighthouse (FCP, LCP, TBT, CLS, Speed Index on mobile emulation), accessibility via axe-core against the WCAG 2 rule set, 19 read-only security checks, and AI-readiness checks (robots.txt access for GPTBot, ClaudeBot, PerplexityBot and Google-Extended, JSON-LD structured data, sitemap.xml and llms.txt presence). The practical difference is scope and workflow: Lighthouse gives you a deep single-page lab report; a multi-page audit tool gives you coverage and a ranked fix list across the site.
A sensible split: use Lighthouse while you're actively fixing a specific page, and a site-wide audit when you need to know which pages to fix first or confirm a fix stuck.