Google Lighthouse: A Practical Guide for Developers

Lighthouse is an open-source tool from Google that audits web pages and gives you a report with scores and recommendations. It covers performance, accessibility, best practices, SEO, and, when relevant, PWA.

This article covers how to use it day-to-day, what to pay attention to in the report, and a few tips that make a real difference — without confusing lab data with what your actual users experience.

Why You Should Use Lighthouse

• Fast, actionable feedback: in seconds you get a prioritized list of issues and suggestions, without setting up a complex testing environment.
• Covers multiple dimensions: not just "it's slow" — also contrast ratios, labels, HTTPS, meta tags, and render-blocking resources.
• Fits into your workflow: run it from Chrome DevTools, the command line, or integrate it into CI to catch regressions before they reach production.
• Works alongside other tools: PageSpeed Insights uses Lighthouse under the hood, but adds real user data (CrUX). Lab data plus field data is the ideal combination.

If you do one thing after reading this: run Lighthouse on the URL that actually matters to your users, and run it again after every significant change to see whether things improved.

What Lighthouse Audits

Scores range from 0 to 100. A rough guide: below 50 is red, 50–89 is amber, 90 and above is green. Use these as a signal, not a pass/fail certificate.

How to Run Lighthouse

Chrome DevTools (best for local iteration)

1. Open the page in Chrome.
2. Open DevTools → Lighthouse tab.
3. Choose categories and device (mobile is the standard).
4. Click Analyze page load.

This is the most practical option for local pages or authenticated routes, since it runs inside your existing Chrome session.

CLI (automation and CI)

npm install -g lighthouse
lighthouse https://your-site.com --output html --output-path report.html

To audit only specific categories:

lighthouse https://your-site.com --only-categories=performance,accessibility

Export to JSON if you want to store results or open them in the Lighthouse report viewer.

PageSpeed Insights

Paste a public URL and get the Lighthouse analysis plus, when available, real user experience data from CrUX. It's the fastest way to get field context without any setup.

What to Focus on in the Report

Core Metrics

• FCP (First Contentful Paint): when the first text or image appears on screen.
• LCP (Largest Contentful Paint): when the main visible element finishes loading.
• TBT (Total Blocking Time): how long the main thread was blocked by JavaScript.
• CLS (Cumulative Layout Shift): how much elements shift around during load.

Opportunities vs Diagnostics

• Opportunities: specific changes with estimated time savings. Prioritize the ones with the biggest impact first.
• Diagnostics: additional context about the DOM, third-party scripts, fonts, etc. Useful for understanding the root cause.

Audits worth checking on every run:

• Unused JavaScript
• Cache policy on static assets
• Text visible while fonts load (font-display)
• preconnect to critical origins
• Unnecessary redirects
• Videos instead of heavy GIFs

Accessibility: Don't Trust the 100 Alone

Lighthouse covers only the accessibility issues that can be detected automatically. Many others — keyboard navigation order, focus management, state announcements — require manual testing. A score of 100 doesn't mean your site is accessible to everyone.

Useful Tips

1. Run in incognito mode: prevents Chrome extensions from skewing results.
2. Keep emulation consistent: use the same device and screen size every time so you can compare audits meaningfully.
3. Save the JSON: you can reload old reports in the viewer and track changes over time.
4. Be careful with preload: only add rel=preload after measuring — preloading the wrong resource can delay the first render.
5. Watch third-party scripts: filter by "third party" in the Network tab and cross-reference with script evaluation time. Many regressions come from analytics, widgets, or ads.
6. Integrate into CI: set minimum score thresholds in your pipeline to catch regressions automatically. Lighthouse CI makes this straightforward.

The Honest Caveat: A 100 Is Not a Perfect Site

Lighthouse runs in simulated lab conditions. That's useful for catching technical problems, but it doesn't reflect what your users actually experience on their devices and networks.

What Lighthouse tells you → specific technical issues and regressions. What real users experience → you need RUM or field data like CrUX.

The right combination is Lighthouse during development + PageSpeed Insights or WebPageTest to understand real-world behavior in production.

Conclusion

Run Lighthouse early and often. It's cheap to execute, gives your team a shared vocabulary — LCP, CLS, TBT — and connects performance, accessibility, and SEO improvements in one place. Pair it with manual accessibility testing and real user metrics when your traffic justifies it.

Resources

• Introduction to Lighthouse — Chrome Developers
• Lighthouse for Load Performance — Chrome Blog
• PageSpeed Insights
• Lighthouse CI — GitHub