Lighthouse is an open-source automated auditing tool for web pages that loads a URL in a Chromium browser under controlled conditions, records what happens and produces a report with scores, metrics and specific improvement opportunities. In web testing, it is the most widely used lab tool for checking performance, accessibility, best practices and search engine optimization in a single run.
Lighthouse is built into Chrome DevTools, powers the lab section of PageSpeed Insights and is available as a command-line tool and Node module. Its strength is repeatable diagnosis under a fixed device and network profile. Its limitation is the same fact seen from the other side: a single simulated visit does not represent real users, so its numbers complement field data rather than replace it.
How a Lighthouse audit runs
A Lighthouse run has three stages. First, gatherers drive the browser through the Chrome DevTools Protocol and collect artifacts such as a performance trace, network requests, the DOM and screenshots. Next, audits analyze those artifacts and produce individual results, for example whether images are properly sized or whether buttons have accessible names. Finally, the audits are weighted into category scores from 0 to 100.
By default, the mobile configuration emulates a mid-range phone on a slow 4G connection, with roughly 150 ms of round-trip latency, about 1.6 Mbps of throughput and a 4x CPU slowdown. Lighthouse usually applies this through simulated throttling: it loads the page at full speed and then models how the load would unfold on the slower profile. This is fast and fairly stable, but the result is an estimate rather than a measured load.
Lighthouse supports three modes, each answering a different question.
| Mode | What it measures | Typical use |
|---|---|---|
| Navigation | A full page load from start to finish | Load performance and the overall score |
| Timespan | An arbitrary period of user interaction | Interaction responsiveness, layout shifts after load |
| Snapshot | The page in its current state | Accessibility of modals, menus and other states |
Lighthouse categories and performance metrics
A standard report contains four categories: Performance, Accessibility, Best Practices and SEO. Older versions also had a Progressive Web App category, which has since been removed. Each category score is shown with a color band: 0 to 49 is poor, 50 to 89 needs improvement and 90 to 100 is good.
The Performance score is a weighted average of five lab metrics. Each metric value is first mapped to a 0 to 100 score on a log-normal curve derived from real-world website data, then combined with the weights shown below, which apply to recent major versions.
| Metric | What it captures | Weight | Good mobile value |
|---|---|---|---|
| Total Blocking Time (TBT) | Main-thread blocking between FCP and interactivity | 30% | Up to 200 ms |
| Largest Contentful Paint (LCP) | When the main content becomes visible | 25% | Up to 2.5 s |
| Cumulative Layout Shift (CLS) | Unexpected movement of visible content | 25% | Up to 0.1 |
| First Contentful Paint (FCP) | When the first text or image appears | 10% | Up to 1.8 s |
| Speed Index | How quickly the viewport fills visually | 10% | Up to 3.4 s |
Total Blocking Time is the lab proxy for responsiveness. A navigation run involves no real clicks, so it cannot measure Interaction to Next Paint, the Core Web Vital for responsiveness; long JavaScript tasks during load are the best available signal.
Lighthouse compared with other testing tools
Lighthouse is one of several tools in the web testing toolbox, and the important distinction is between lab data, collected in a controlled run, and field data, collected from real visitors. The table places Lighthouse next to its closest neighbors.
| Tool | Data type | Strength | Limitation |
|---|---|---|---|
| Lighthouse | Lab, single device profile | Repeatable, actionable diagnostics | One synthetic visit |
| PageSpeed Insights | Lab plus field from real Chrome users | Shows how real visitors experience the page | Field data needs enough traffic |
| Browser DevTools performance panel | Lab, detailed trace | Deep debugging of individual tasks | Manual, expert interpretation |
| Real user monitoring | Field, own visitors | Full device and network diversity | Requires instrumentation |
| Dedicated accessibility checkers | Automated rules | Broader rule sets than Lighthouse | Still miss most judgment-based issues |
Search ranking signals use field data from the Core Web Vitals, not the Lighthouse score. A page can score 95 in the lab and still fail Core Web Vitals for real mobile users, or the reverse, because real devices, networks and interaction patterns differ from the emulated profile.
Using Lighthouse effectively
Lighthouse is most valuable as a regression detector and a diagnostic guide, not as a single number to chase. Teams get consistent results by controlling the environment and comparing like with like.
- Run several times and use the median, because scores vary between runs by several points even on an unchanged page.
- Test in an incognito window or from the CLI, since browser extensions inject scripts that distort results.
- Read the opportunities and diagnostics, which name the exact resources and estimated savings behind a low score.
- Automate with Lighthouse CI to run audits on every pull request and fail builds that break performance budgets.
- Use timespan mode to test interactions such as opening a menu or filtering a product list.
Limitations and common misreadings
The Lighthouse score is a simplified model of one scenario, and several misunderstandings follow from treating it as more. The table lists the most frequent ones.
| Misconception | Reality | Better approach |
|---|---|---|
| A score of 100 means a fast site | It means one emulated load went well | Confirm with field data |
| The score is a ranking factor | Rankings use field Core Web Vitals | Track real-user metrics |
| Accessibility 100 means accessible | Automated audits cover a fraction of issues | Add manual and assistive technology testing |
| Scores are comparable across machines | Hardware and load affect results | Use one controlled environment |
| Every opportunity is worth fixing | Savings estimates are approximate | Prioritize by metric impact |
Lighthouse also audits only the page state it can reach. Content behind login, consent dialogs or complex user flows needs scripted navigation or timespan runs, otherwise the report describes a page that real users rarely see.
In simple terms
Lighthouse is like a vehicle inspection for a web page. It drives the page through a standard test on a simulated, fairly slow phone. Then it reports what works well and what needs repair.
The report gives scores out of 100 and a list of concrete fixes, such as images that are too large. It is a test drive, not real traffic. Actual visitors may have faster or slower phones, so the score is a guide rather than a final verdict.
A practical example
A news publisher notices that article pages score only 38 for mobile performance in Lighthouse. The report shows a Largest Contentful Paint of 5.8 seconds and a Total Blocking Time of 1,400 ms. The diagnostics point to a lead image loaded lazily by mistake, a heavy advertising script that runs before content and web fonts that block text rendering.
The developers remove lazy loading from the lead image and give it high fetch priority, defer the advertising script until after the main content and switch fonts to swap display. They also add Lighthouse CI to the deployment pipeline with a budget that fails any build whose median LCP exceeds 3 seconds.
Repeated runs now show a median performance score in the high 80s and LCP close to 2.4 seconds. Over the following four weeks, the field data in PageSpeed Insights confirms the change: the share of real mobile visits with good LCP rises clearly, which is the result that actually matters.