Lighthouse is the free auditing engine built into Chrome, and it is probably the most widely run website test in the world. It powers the lab section of PageSpeed Insights, sits in a tab inside Chrome DevTools and runs in thousands of build pipelines. Yet most people use it badly: they run one test, stare at the performance score, panic about a number in orange, and start "fixing" things that make no difference to real visitors.
Used properly, a Lighthouse audit is a fast, repeatable way to find concrete problems with performance, accessibility, best practices and basic SEO hygiene on any page, including pages behind a login. The trick is knowing which mode to run, how to control the conditions, how the scores are calculated and which findings actually matter for rankings and conversions.
This guide explains how to run a Lighthouse audit step by step in 2026, how to read every part of the report (including the newer Insights audits and the Agentic Browsing category), and how to turn the results into a short, prioritised fix list.
Key Takeaways
- Lighthouse is a lab tool: it tests one page load under simulated conditions, so it is ideal for debugging but is not what Google uses to judge your real-world Core Web Vitals.
- Run it in Chrome DevTools for pages behind a login or on staging, and in PageSpeed Insights for a quick, more consistent public test.
- The Performance score is a weighted blend of five lab metrics; Total Blocking Time and Largest Contentful Paint carry the most weight.
- Scores fluctuate between runs. Run several tests and compare medians rather than chasing a single number.
- A perfect SEO score only means basic technical checks pass. It says nothing about content quality, links or relevance.
What Lighthouse Is (and What It Is Not)
Chrome's documentation describes the tool in one line:
“Lighthouse is an open-source, automated tool to help you improve the quality of web pages.”
— Chrome for Developers, Introduction to Lighthouse
It loads a page in a controlled environment, records what happens, and runs a series of audits against that recording. Because the conditions are simulated (a mid-range mobile device on a throttled connection by default), the results are reproducible enough to compare before and after a change. That is the strength of lab data.
The weakness is that a lab test is not your audience. Real users have faster and slower phones, warm caches, consent banners, logged-in states and different network routes. Google's page experience signals use field data from the Chrome UX Report, which you can see in the top half of PageSpeed Insights and in the Search Console Core Web Vitals report. Treat Lighthouse as the diagnostic scanner and field data as the scoreboard. Our guide to Core Web Vitals explains the field thresholds in detail.
The report categories in 2026
| Category | What it checks | How much it matters for SEO |
|---|---|---|
| Performance | Lab loading and responsiveness metrics plus Insights audits that explain what slowed the page | Indirect but important: it diagnoses problems that show up in field Core Web Vitals |
| Accessibility | Automated checks such as colour contrast, form labels, image alt text and ARIA usage | Indirect: better usability, better image understanding, legal risk reduction |
| Best Practices | HTTPS, console errors, deprecated APIs, image aspect ratios and similar hygiene | Low to moderate: catches broken or insecure behaviour |
| SEO | Basic crawlability and indexability checks: status code, robots.txt, noindex, title, meta description, link text, hreflang, canonical, alt text | A floor, not a ceiling: it catches technical blockers only |
| Agentic Browsing | Newer checks on how well AI agents can use the page, such as the accessibility tree, layout stability, WebMCP and llms.txt | Experimental: informational, not a ranking factor |
The Agentic Browsing category arrived in the Lighthouse 13 series and is reported as passed audits rather than a 0–100 score. It is worth a glance, but do not let it distract from the fundamentals; our explainer on llms.txt covers why that file is still optional.
Five Ways to Run a Lighthouse Audit
The same engine is available in several places. Which one you pick changes the conditions of the test.
| Method | Best for | Watch out for |
|---|---|---|
| Chrome DevTools (Lighthouse panel) | Staging sites, logged-in pages, debugging with other DevTools panels | Your own machine's CPU load and extensions affect results |
| PageSpeed Insights | Quick public tests on Google's servers, plus field data in the same view | Only works on publicly reachable URLs |
| Command line (npm package) | Batch testing, saving JSON/HTML reports, custom settings | Needs Node.js and Chrome installed |
| Node module / Lighthouse CI | Automated checks on every deploy with performance budgets | Requires developer set-up |
| Chrome extension | Occasional use | Chrome recommends DevTools instead; it cannot test local or authenticated pages |
How to Run a Lighthouse Audit in Chrome DevTools: Step by Step
- Open a clean browser window. Use an Incognito window or a fresh Chrome profile so extensions, cookies and cached data interfere as little as possible.
- Load the page you want to test and open DevTools (right-click, then Inspect).
- Select the Lighthouse panel. If you cannot see it, click the » overflow arrow in the DevTools tab bar.
- Choose a mode. Navigation (the default) tests a fresh page load. Timespan records a period while you interact. Snapshot audits the page in its current state without reloading.
- Choose the device. Start with Mobile, because Google indexes the mobile version of pages and mobile conditions expose more problems.
- Tick the categories you need. Untick the rest to speed the run up.
- Check the settings cog. Leave throttling on the default simulated option unless you have a reason to change it, and keep "Clear storage" on to simulate a first visit.
- Click Analyze page load and avoid using the computer while the test runs.
- Repeat three to five times and note the median scores and metric values before drawing conclusions.
- Save the report as HTML or JSON from the report menu so you can compare it after fixes.
Chrome's own DevTools documentation warns that device load, extensions and stored data all influence results, and that you should not directly compare audits run on different machines. When you need consistency for reporting, PageSpeed Insights or a CI server is a better baseline.
How to Read the Performance Section
The Performance score is a weighted average of five lab metrics. According to Chrome's scoring documentation, the weights (unchanged in Lighthouse 13) are:
| Metric | Weight | What it tells you | Usual causes when poor |
|---|---|---|---|
| First Contentful Paint (FCP) | 10% | When the first text or image appears | Slow server response, render-blocking CSS and JavaScript |
| Speed Index | 10% | How quickly content visibly fills the screen | Late-loading above-the-fold content, heavy fonts |
| Largest Contentful Paint (LCP) | 25% | When the main hero image or text block renders | Large unoptimised images, lazy-loaded hero images, slow TTFB |
| Total Blocking Time (TBT) | 30% | How long the main thread was blocked by long tasks | Heavy JavaScript, third-party tags, large frameworks |
| Cumulative Layout Shift (CLS) | 25% | How much the layout jumps around | Images without dimensions, injected banners, web fonts |
Scores of 90–100 are shown in green (good), 50–89 in orange (needs improvement) and 0–49 in red (poor). Notice that Interaction to Next Paint is not in the list: a navigation test has no real user clicking anything, so TBT acts as the lab proxy for responsiveness. To see INP-style data in the lab, use Timespan mode and interact with the page, then confirm with field data. Our guides to fixing LCP, improving INP and reducing CLS go metric by metric.
Insights and Diagnostics
Below the metrics, Lighthouse 13 groups most performance advice into Insights audits, which mirror the Insights you see in the DevTools Performance panel. Examples include LCP breakdown, layout shift culprits, render-blocking requests, image delivery, document request latency and third-party usage. Several older audits were removed in that release, so if a tutorial tells you to look for "Defer offscreen images" or "Preload key requests", it predates the change.
Read Insights in this order:
- LCP-related insights first, because LCP has a heavy weight and is often the easiest win (image size, priority hints, server response).
- Render-blocking requests next; see our guide to eliminating render-blocking resources.
- Long main-thread tasks and third-party code, which drive TBT and real-world INP.
- Layout shift culprits, which usually point at images, ads or embeds without reserved space.
Each audit shows estimated savings. Treat these as rough guides to priority, not promises.
Reading the Accessibility, Best Practices and SEO Sections
These three categories are pass/fail checklists. Failed audits are listed first, followed by "Additional items to manually check" and passed audits. A few practical notes:
- Accessibility: automated checks catch only a portion of real accessibility issues. A score of 100 does not make a site accessible, but the failures it flags (missing labels, poor contrast, missing alt text) are genuine. See accessibility and SEO for the overlap.
- Best Practices: console errors and mixed content often reveal broken scripts or plugins that also hurt tracking and conversions.
- SEO: Chrome's documentation states that Lighthouse "doesn't evaluate the quality of your description" when it checks meta descriptions. The category confirms the page can be crawled and indexed and has basic tags; it does not measure whether the page deserves to rank.
Turning a Lighthouse Report Into a Fix List
A report with forty flagged items is overwhelming. Use a simple triage process:
- Check field data first. If the URL or origin already passes Core Web Vitals in the field, performance work is lower priority than content or links.
- Group pages by template. Product pages, category pages, blog posts and the homepage usually share code. Fix the template once rather than page by page.
- Fix blockers before polish. A failed SEO audit such as a noindex tag or 4xx status code outranks any speed tweak.
- Start with the heaviest images and scripts. Compressing hero images (see image compression) and removing unused third-party tags typically improves several metrics at once.
- Retest with the same settings, compare medians, then monitor field data over the following 28 days.
For a site-wide view, pair Lighthouse with a crawler. Our Screaming Frog guide shows how to pull PageSpeed data for every URL in a crawl via the API, which is far quicker than testing pages one at a time.
Common Mistakes When Running Lighthouse Audits
- Chasing 100. A perfect score is not a ranking factor. Moving from 85 to 100 rarely changes anything users notice.
- Testing once. Chrome's documentation notes that much of the variability in scores comes from changing underlying conditions, not Lighthouse itself. Use medians.
- Testing with extensions enabled. Ad blockers and password managers inject scripts that distort results.
- Comparing desktop with mobile, or DevTools with PageSpeed Insights. Different hardware and throttling produce different numbers. Compare like with like.
- Treating lab data as Google's verdict. Rankings use field data. A page can score 60 in the lab and still pass Core Web Vitals for real users.
- Auditing only the homepage. Product and article templates usually carry most of your organic traffic.
- Following outdated advice. Audits are renamed and retired between versions; check which Lighthouse version produced the report (shown at the bottom).
Related Guides
- Screaming Frog for Beginners: Crawl Your Site Like Google
- Search Console URL Inspection Tool: A Complete Guide
- Bing Webmaster Tools: Setup and Key Features
Frequently Asked Questions
Is Lighthouse the same as PageSpeed Insights?
No. PageSpeed Insights runs Lighthouse on Google's servers for its lab section and adds real-user field data from the Chrome UX Report. Lighthouse on its own only produces lab data.
Does a higher Lighthouse score improve Google rankings?
Not directly. Google uses field Core Web Vitals as part of its page experience signals. Lighthouse helps you find the problems behind poor field data, but the score itself is not used for ranking.
Why does my Lighthouse score change every time I run it?
Network conditions, CPU load, ads, A/B tests and browser extensions all vary between runs. Run several tests and use the median, or use PageSpeed Insights or Lighthouse CI for more consistent conditions.
Can Lighthouse test pages that require a login?
Yes. Run it from the Lighthouse panel in Chrome DevTools while you are logged in. PageSpeed Insights can only test publicly accessible URLs.
Should I test mobile or desktop?
Start with mobile. Google uses mobile-first indexing and the default mobile throttling exposes performance problems more clearly. Test desktop too if most of your conversions come from desktop users.
Conclusion
A Lighthouse audit is most valuable when you treat it as a repeatable diagnostic rather than a report card. Run it in the right mode, control the conditions, read the Insights in order of impact, and confirm every improvement against real-user data. Fix templates, not single pages, and stop when field Core Web Vitals pass.
If your audits keep surfacing the same slow templates, our page speed optimization service can take it from diagnosis to deployment, and our wider guide to improving page speed is a good next read. Want an expert review of your own reports? Request a free quote.
References
- Introduction to Lighthouse – Chrome for Developers
- Lighthouse performance scoring – Chrome for Developers
- Lighthouse 13 release notes – Chrome for Developers
- Lighthouse panel in DevTools – Chrome for Developers
- Lighthouse SEO audits – Chrome for Developers
- Google Lighthouse: What It Is & How to Use It – Semrush Blog
