---
title: "LHCI vs Unlighthouse: Which Lighthouse CI Tool Should You Use?"
description: "Honest side-by-side comparison of @lhci/cli and Unlighthouse. Setup, URL discovery, budgets, reporting, and when each tool fits your workflow."
canonical_url: "https://unlighthouse.dev/learn-lighthouse/lhci-vs-unlighthouse"
last_updated: "2026-04-13"
---

`@lhci/cli` (from Google) is best for tracking a known list of critical URLs over time with performance budgets and historical dashboards. Unlighthouse is best for auditing every page of a site at once via auto-discovery. The two tools solve different problems.

## The two tools

<tab-comparison>
<div icon="i-heroicons-command-line" label="@lhci/cli">

Google's official Lighthouse CI. You provide a list of URLs, it runs Lighthouse N times per URL, asserts against budgets, and uploads results to temporary storage, the filesystem, or an LHCI server. Around [2.3M monthly npm downloads](https://www.npmjs.com/package/@lhci/cli) in 2026 (following the Feb 2026 registry bot-filtering event).

```bash
npm install -g @lhci/cli
lhci autorun
```

</div>
</tab-comparison>

<div icon="i-simple-icons-lighthouse" label="Unlighthouse">

Open-source CLI that crawls your sitemap and internal links, then runs Lighthouse on every discovered route. Produces a navigable HTML client, JSON exports, and CI assertions. No URL manifest needed. Around [100k monthly downloads](https://www.npmjs.com/package/unlighthouse).

```bash
npx unlighthouse --site https://example.com
```

</div>

::

## Side-by-side comparison

<table>
<thead>
  <tr>
    <th>
      
    </th>
    
    <th>
      @lhci/cli
    </th>
    
    <th>
      Unlighthouse
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Made by
      </strong>
    </td>
    
    <td>
      Google Chrome team
    </td>
    
    <td>
      Harlan Wilton (OSS)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Setup time
      </strong>
    </td>
    
    <td>
      10-30 min (config file + budgets)
    </td>
    
    <td>
      Under 1 min (zero config)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        URL discovery
      </strong>
    </td>
    
    <td>
      Manual list in <code>
        lighthouserc.js
      </code>
    </td>
    
    <td>
      Auto-crawl via sitemap, robots.txt, links
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Default URLs tested
      </strong>
    </td>
    
    <td>
      Only what you specify
    </td>
    
    <td>
      Every internal route found
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Performance budgets
      </strong>
    </td>
    
    <td>
      Yes, per URL, rich assertions
    </td>
    
    <td>
      Yes, global score thresholds
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Architecture
      </strong>
    </td>
    
    <td>
      Sequential/Isolated for precision
    </td>
    
    <td>
      <strong>
        Smart Sampling
      </strong>
      
       for site-wide speed
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Historical tracking
      </strong>
    </td>
    
    <td>
      Yes via @lhci/server
    </td>
    
    <td>
      No built-in dashboard
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Local HTML UI
      </strong>
    </td>
    
    <td>
      Static report per URL
    </td>
    
    <td>
      Interactive client, sortable, filterable
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        CI integration
      </strong>
    </td>
    
    <td>
      First-party GitHub App, status checks
    </td>
    
    <td>
      <code>
        unlighthouse-ci
      </code>
      
       command, JSON output
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        PR comments
      </strong>
    </td>
    
    <td>
      Via GitHub App
    </td>
    
    <td>
      Via third-party actions
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Variance reduction
      </strong>
    </td>
    
    <td>
      Runs N times, uses median
    </td>
    
    <td>
      Configurable, defaults to 1 run
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Server/DB required
      </strong>
    </td>
    
    <td>
      Optional (LHCI server)
    </td>
    
    <td>
      No
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        npm downloads (monthly)
      </strong>
    </td>
    
    <td>
      ~2.3M
    </td>
    
    <td>
      ~100k
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Best for
      </strong>
    </td>
    
    <td>
      Regression tracking on key URLs
    </td>
    
    <td>
      Site-wide audits, catching outliers
    </td>
  </tr>
</tbody>
</table>

## When to use @lhci/cli

Pick LHCI when:

- You have a handful of critical URLs (homepage, checkout, product page) and want to track them over weeks or months.
- You need [hard performance budgets enforced on every PR](https://web.dev/articles/lighthouse-ci#budgets), with builds failing when thresholds break.
- You want to use **Lighthouse 13** diagnostics (requires LHCI v0.15+ and [Node.js 22+](https://nodejs.org/en/blog/release/v22.0.0)).
- You want a historical dashboard showing score trends, and you're willing to [host @lhci/server](/learn-lighthouse/lighthouse-ci/server) or use temporary public storage.
- You're already invested in the Google Chrome tooling ecosystem and want [first-party GitHub App integration](https://github.com/apps/lighthouse-ci).

LHCI's strength is depth on a narrow set of pages. It was designed for the workflow where a team picks 5 to 10 representative URLs, sets budgets, and watches for regressions commit by commit. In 2026, the roadmap focuses on [SHA-pinning security](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions) for all CI actions to prevent supply chain attacks.

## When to use Unlighthouse

Pick Unlighthouse when:

- You want to audit the entire site, not just a predefined list.
- You don't know which pages are slowest, and you want to find out.
- You need to audit 1,000+ pages; Unlighthouse's **Smart Sampling** identifies route patterns and only audits representative samples, making it [10x faster than sequential testing](/guide/guides/dynamic-sampling).
- Setup speed matters; you want to go from install to results in under a minute.
- You need to spot patterns across routes, for example a shared layout causing [CLS](/learn-lighthouse/cls) on 200 blog posts.
- You want an interactive UI for browsing per-page results, not static HTML reports.

Unlighthouse's strength is breadth. It finds problems you didn't know to look for. The homepage might score 95, while `/pricing/enterprise` scores 62 because a marketing tag manager ships 400KB of JavaScript that never hit the homepage.

## Running both in parallel

The tools complement each other. A common setup:

- **Every PR**: `@lhci/cli` runs on 5-10 critical URLs with strict budgets. Fast feedback, historical tracking via LHCI server.
- **Weekly scheduled job**: Unlighthouse scans the full site, posts a summary to Slack, flags any page scoring below 70.

<code-group>

```yaml [PR Pipeline (LHCI)]
name: Lighthouse CI
on: [pull_request]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx @lhci/cli@latest autorun
```

```yaml [Weekly Audit (Unlighthouse)]
name: Weekly Health Check
on:
  schedule:
    - cron: '0 6 * * 1' # Monday 6am
jobs:
  unlighthouse:
    runs-on: ubuntu-latest
    steps:
      - run: npx unlighthouse-ci --site https://example.com --build-static
      - uses: actions/upload-artifact@v4
        with:
          name: unlighthouse-report
          path: .unlighthouse
```

</code-group>

## Summary

Pick `@lhci/cli` for deep regression tracking on a curated URL list with historical dashboards. Pick Unlighthouse for fast, site-wide audits that surface problems across every route. Run both if you want per-PR gates plus scheduled full-site coverage.

<u-button icon="i-heroicons-rocket-launch" label="Try Unlighthouse" size="lg" to="/">



</u-button>