Lighthouse
Google's open-source tool for auditing performance, accessibility, SEO, and best practices. Built into Chrome DevTools.
Overview
Lighthouse is an open-source, automated tool for improving the quality of web pages. Created by Google, it audits web pages across five categories: Performance, Accessibility, Best Practices, SEO, and Progressive Web App (PWA). Lighthouse is built into Chrome DevTools, available as a browser extension, and can be run from the command line or in CI/CD pipelines.
Lighthouse is unique among testing tools because it covers multiple quality dimensions in a single audit. It is often the first quality tool added to a web project because it requires zero setup and provides immediate, actionable feedback.
What it's used for
Lighthouse is essential for:
- Performance auditing: Measure Core Web Vitals (LCP, FID, CLS) and identify performance bottlenecks.
- Accessibility quick checks: Catch common accessibility issues automatically.
- SEO validation: Ensure pages are discoverable by search engines.
- CI/CD quality gates: Block deployments that degrade performance or accessibility scores.
Pros & Cons
Pros
- Free and built into Chrome — zero setup
- Covers performance, accessibility, SEO, and best practices
- Actionable recommendations with estimated savings
- Can run in CI via Lighthouse CI
- Backed by Google — scores influence search rankings
Cons
- Limited to Chrome rendering engine
- Accessibility checks are basic compared to Axe
- Performance scores can vary between runs
- Mobile simulation is not a substitute for real device testing
- SEO checks are rudimentary compared to dedicated tools
Platforms & Integrations
Lighthouse runs in Chrome, as a CLI tool (Node.js), or in CI via Lighthouse CI. It audits any publicly accessible web page.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | All audits, CLI, CI integration, browser extension |
NZ Context
Lighthouse is ubiquitous in NZ web development. Every NZ frontend developer and tester should know how to run a Lighthouse audit. Google's PageSpeed Insights (which uses Lighthouse) is frequently referenced in NZ digital marketing and SEO contexts. For NZ government websites, Lighthouse accessibility scores are sometimes used as a proxy for WCAG compliance, though dedicated tools like Axe are preferred for thorough testing.
Alternatives
- WebPageTest — More detailed performance testing with real device and connection profiles.
- Axe — More comprehensive accessibility testing.
- GTmetrix — User-friendly performance reporting with historical tracking.
When to choose Lighthouse
A quick decision guide for NZ teams evaluating web performance & quality auditing options.
| Choose Lighthouse when… | Choose something else when… | Combine with… |
|---|---|---|
| You need a single pass to cover performance, accessibility, SEO, and best practices simultaneously. | Your accessibility requirement is WCAG 2.1 AA compliance evidence — reach for Axe or Deque's axe-core for comprehensive ARIA and keyboard coverage. | Axe — run after Lighthouse to catch the 57% of accessibility issues automated tools miss. |
| You want a CI/CD quality gate that blocks regressions in Core Web Vitals without licensing fees. | You need stable, repeatable performance benchmarks from real global locations — Lighthouse scores vary run-to-run. Use WebPageTest or SpeedCurve instead. | WebPageTest — validates real-world load from diverse connection profiles and geographic regions. |
| Your team is browser-first and already lives in Chrome DevTools — zero friction onboarding. | You need cross-browser performance data (Safari, Firefox). Lighthouse runs Chromium only and cannot surface Safari-specific render blocking. | GTmetrix — provides historical score tracking and waterfall analysis useful for executive-level reporting. |
| You're auditing a public-facing NZ government or commercial page where Google search ranking is a KPI. | Your app sits behind authentication. Lighthouse cannot audit login-gated pages via DevTools without custom scripting; consider Playwright with lighthouse-plugin integration. | Google Search Console — pairs Core Web Vitals field data (real users) with Lighthouse lab data for a complete picture. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were a QA engineer joining the ListRight engineering team — where performance regressions directly affect conversion and Trust & Safety pages need accessible forms.
I would…
Start by wiring Lighthouse CI into the GitHub Actions pipeline with a score budget — performance ≥ 80, accessibility ≥ 90. This creates an objective regression baseline before anyone disputes whether a deploy "broke" the page. Then add Axe alongside it, because Lighthouse's accessibility checks are surface-level and ListRight's listing forms have complex ARIA patterns that Lighthouse won't flag. I would not use Lighthouse scores alone in accessibility sign-off documentation — they're a first filter, not a compliance gate.
If…
I were on the digital delivery team at Revenue NZ (IR), shipping citizen-facing forms where accessibility is a legal obligation and the user base skews older with lower-bandwidth connections.
I would…
Run Lighthouse in throttled mobile mode (simulated 4G) as the mandatory check before every release — it catches the most common issues on slow connections quickly. For compliance evidence, I would pair it with axe-core automated scans and scheduled manual keyboard + screen reader walkthroughs using NVDA. The Lighthouse report goes to developers as a fix list; the Axe report plus manual session notes go into the accessibility conformance record. IR's risk profile means you cannot rely on Lighthouse alone and you must keep audit artefacts for audit trail purposes.
If…
I were a tester at CloudBooks NZ noticing that Lighthouse performance scores for the invoicing dashboard vary by 15–20 points between local and CI runs, causing false-positive build failures.
I would…
Switch from single-run scoring to the median of five runs using --runs=5 in Lighthouse CI — this is the official recommendation and cuts variance significantly. I would also move the CI quality gate to block only on accessibility regressions (which are deterministic) and use SpeedCurve for performance trending over time using real field data. That way the CI gate is reliable and the performance story is told through a separate tool that handles variability properly.
The bottom line: Lighthouse is the right starting tool for almost every NZ web team — but it is a filter, not a verdict. Treat a score of 100 as "no obvious problems found," not as "this page is fully accessible and fast for all users."
Interview questions
Questions you are likely to get if you list Lighthouse on your CV — with what interviewers are really testing for.
What is the difference between Lighthouse's lab data and field data, and why does it matter in practice?
What they’re really testing: Whether you understand that Lighthouse scores are simulated measurements and can differ significantly from what real users experience.
Strong answer covers: Lab data = Lighthouse simulates a mid-tier device on throttled 4G in a controlled environment; field data = real Chrome User Experience Report (CrUX) data from actual users. Score variance of 10–20 points between runs is normal. In NZ, where many users are on mobile with variable rural connectivity, CrUX field data via Google Search Console often tells a very different story than a local DevTools run.
When would you use Lighthouse for accessibility testing over Axe, and when would you use both?
What they’re really testing: Whether you know the limits of automated accessibility tooling and can make sensible tool selection decisions rather than treating Lighthouse as a compliance gate.
Strong answer covers: Lighthouse catches surface-level issues quickly (missing alt text, low contrast, unlabelled inputs) and is good as a first filter in CI. Axe-core catches roughly twice as many issues including complex ARIA and keyboard navigation failures. For NZ government pages (which must meet WCAG 2.1 AA), Lighthouse alone is not sufficient evidence of compliance — run both and supplement with manual screen reader testing using NVDA or VoiceOver.
You’re joining the QA team at CloudBooks NZ and discover that Lighthouse CI scores for the invoicing dashboard vary by up to 20 points per run, causing builds to fail intermittently. How would you stabilise the quality gate?
What they’re really testing: Whether you understand score variance is a known Lighthouse limitation and have concrete strategies to handle it, rather than just raising or removing the threshold.
Strong answer covers: Switch to --runs=5 in Lighthouse CI so it uses the median of five runs (Google’s official variance reduction recommendation). Move the CI hard block to accessibility score only (deterministic) and treat performance as a warning trend rather than a pass/fail gate. Route performance trending to a dedicated tool like SpeedCurve that uses real field data. Document the rationale so the team understands it’s a tool limitation, not a lowered standard.
Your Lighthouse performance score passes in DevTools but the same page fails the Lighthouse CI check in GitHub Actions. How do you diagnose and resolve that?
What they’re really testing: Whether you can reason through environment differences between local and CI and know where to look when automated audits give inconsistent results.
Strong answer covers: Check CPU and network throttling settings — local DevTools may run unthrottled while Lighthouse CI applies 4x CPU slowdown by default. Verify the CI runner spec (shared GitHub-hosted runners are slower than a developer laptop). Compare the HTML actually served in each environment (CDN caching, environment-specific bundles, feature flags). Confirm you’re hitting the same URL (staging vs production, with vs without authentication). Run --preset=desktop locally to match if CI is using desktop mode.
How would you structure a Lighthouse CI quality gate for a large NZ e-commerce team shipping to production multiple times a day, where different squads own different page types?
What they’re really testing: Whether you can design a scalable, team-friendly quality process rather than a one-size-fits-all gate that either blocks shipping or gets ignored.
Strong answer covers: Define separate URL sets and score budgets per page type (homepage, product listing, checkout) since performance profiles differ. Use lighthouserc.js assertions at the category level for hard blocks (accessibility ≥ 90) and metric level for warnings (LCP ≤ 2500ms). Store historical reports in Lighthouse CI server or S3 so squads can compare trends. Integrate score summaries as PR comments so developers see results without leaving GitHub. Make the gate advisory initially — let teams build baseline data before enforcing hard failures.