Unlighthouse vs PageSpeed Insights: Why I Run Site-Wide Lighthouse Audits Before I Deploy

The PageSpeed Insights Loop, and Why It Hurts

PageSpeed Insights (PSI) is the tool everyone reaches for, and for good reason — it runs Google's own Lighthouse engine and, crucially, it shows you Core Web Vitals field data from real users via the Chrome User Experience Report (CrUX). That field data is the number that actually matters, because it's what Google measures for ranking. There is no substitute for it.

But PSI has two structural limitations that make it a poor first tool. First, it audits one URL at a time. If you have a 40-page site and you want to know whether a problem is isolated or site-wide, you're pasting 40 URLs into a form one by one. Second, it only ever sees what's live. To find out whether a fix worked, you have to deploy it, wait for the deploy to propagate, then re-run PSI — and if the fix didn't move the needle, you do it again. You end up testing hypotheses in production, one page and one deploy at a time.

That loop is fine when you're chasing the last few points on a single hero page. It is miserable when you're trying to understand the overall health of a site you've just inherited, or when the same issue is quietly dragging down every route and you don't know it yet.

What Unlighthouse Actually Does

Unlighthouse is an open-source tool built on top of Google Lighthouse by Harlan Wilton (harlan-zw on GitHub). Instead of auditing a single URL, it crawls your site, discovers all the routes, and runs a full Lighthouse audit against each one — Performance, Accessibility, Best Practices, and SEO — then aggregates everything into a single dashboard. You point it at a domain or a local dev server, and a few moments later you have a Lighthouse score for every page on the site in one view.

It runs locally. There's no account, no API key, no quota. Because it's your own machine running headless Chrome, you can run it against localhost:3000 while your dev server is up, which means you can audit changes before they ship. That single property — auditing the whole site, locally, pre-deploy — is what breaks the PSI loop. You're no longer learning whether a fix helped by deploying it; you're learning by re-running a local scan.

Unlighthouse gives you breadth and speed; PageSpeed Insights gives you depth and truth. The mistake is using either one for the job the other is better at.

— Chris de Gruijter

How I Use It — The Two Commands

You don't need to install anything to try it. There are two modes I reach for, depending on whether I want to explore results interactively or pipe them into something.

Interactive mode

For day-to-day optimisation work, the interactive UI is the one I live in. It crawls the site, then opens a live dashboard at localhost:5678 where you can sort pages by score, drill into any individual report, and watch results stream in as the crawl progresses.

The dashboard is the real product here. Sorting all routes by SEO score, or by performance, instantly tells you whether a problem is one bad page or a pattern across the whole site. That distinction is the entire reason the tool exists.

CI / headless mode

When I want machine-readable output — to gate a deploy, to diff scores over time, or to feed results into another script — there's a headless CI mode that runs without the UI and writes a report.

On larger sites, you don't need to audit every single one of thousands of URLs to get a representative picture. Unlighthouse uses dynamic sampling — it intelligently samples representative routes (one product page stands in for the product template, one blog post for the post template) so a scan stays fast while still covering every distinct page type. For pattern detection that's exactly what you want: the templates, not every instance.

The Real Win: Site-Wide Pattern Detection

Auditing one page tells you about one page. Auditing every page at once tells you about your codebase. Almost every meaningful issue on a templated site is a pattern — it lives in a shared layout, a global stylesheet, a component used on every route, or a config file. PSI shows you the symptom on whichever page you happened to test. A site-wide scan shows you that the symptom is on all 42 pages, which immediately reframes it from "fix this page" to "fix this once, everywhere."

These are the recurring patterns Unlighthouse surfaces in one pass that I'd otherwise discover page-by-page through PSI:

• An oversized global CSS bundle — when 80%+ of a stylesheet is unused on every route, that's not a page problem, it's a build problem. Seeing the same "reduce unused CSS" flag on every page in the dashboard makes the global cause obvious immediately.
• Generic, non-descriptive link text — "Read More" and "Learn More" repeated across a site hurt SEO and accessibility at scale. One page flagging it is easy to dismiss; every page flagging it tells you it's coming from a shared card or list component.
• An invalid robots.txt directive — a single malformed line in robots.txt can cap the SEO score on every page of the site at once, because every page is audited against the same file.
• Missing font-display — a font config issue lives in one place but degrades every route's render. The whole-site view shows the flash-of-invisible-text penalty landing everywhere uniformly.
• Unconverted images — JPEG/PNG content images served instead of WebP/AVIF, usually because the wrong component or a raw <img> tag is used in a shared partial.

To make it concrete without naming anyone: on one site I worked on, a single invalid directive in robots.txt was capping the SEO score on all 42 scanned pages. Through PSI alone I might have spotted a low SEO score on one page, fixed something page-specific, and moved on — never realising every page shared the same ceiling. Unlighthouse made it obvious in one scan: 42 pages, same SEO flag, same root cause. Fixing one file lifted the SEO score across the entire site at once. That's the kind of leverage you only get from breadth.

The Workflow I Actually Recommend

The point of all this isn't "use Unlighthouse instead of PageSpeed Insights." It's to put each tool where it's strongest. Here's the order I work in:

1. Scan the whole site locally with Unlighthouse — against the live domain first to get a baseline, or against the dev server if I'm mid-change. This gives me the full picture across Performance, Accessibility, Best Practices, and SEO for every page type.
2. Sort by score and look for patterns — anything that shows up on most or all pages is a site-wide cause living in shared code or config. Those are the highest-leverage fixes.
3. Fix the patterns in one local pass — global CSS, shared components, font config, robots.txt, image handling. Re-run the local scan to confirm the scores moved, with zero deploys in the loop.
4. Deploy once the local scan is clean — not after every individual experiment.
5. Verify on production with PageSpeed Insights — this is where PSI belongs: confirming the real, Google-scored result on the live site, and reading the CrUX field data that reflects what actual users experience.

Lab data and field data aren't the same thing, and that's the other reason this ordering works. Unlighthouse (like the Lighthouse CLI) gives you lab data — a controlled, synthetic measurement that's perfect for iterating quickly because it's deterministic and instant. PSI gives you that plus CrUX field data: the 75th-percentile Core Web Vitals from real Chrome users over the trailing 28 days. You optimise against lab data because it's fast to iterate on, then you confirm against field data because that's the number Google ranks on. Trying to iterate against field data directly is hopeless — it lags by weeks.

Where Each Tool Wins

If I had to compress the whole comparison into a table in my head, it looks like this:

• Unlighthouse — breadth: every page in one scan, fast local iteration, pre-deploy auditing, site-wide pattern detection, accessibility and SEO sweeps at scale, no quota.
• PageSpeed Insights — depth and truth: real Google scoring, CrUX field data from actual users, the single-URL number that matters for the live site, the authoritative source for Core Web Vitals.

Unlighthouse doesn't replace PSI — it can't, because it has no access to CrUX field data and it isn't the number Google reports. And PSI doesn't replace Unlighthouse, because it can't show you the whole site at once or let you iterate before you deploy. Used together, in that order, they cover the entire optimisation cycle: broad and fast first, authoritative and final last.

A Note on Credit

Unlighthouse is free and open source, built on Google Lighthouse and maintained by Harlan Wilton. If it earns a place in your workflow the way it has in mine, the project lives at unlighthouse.dev and the source is on GitHub at harlan-zw/unlighthouse. It's the rare tool that genuinely changes how you work rather than just adding another dashboard to check — worth a star.