Beacon
Real Chrome · real Lighthouse · every run kept
A page audited once tells you how it did that afternoon, on that machine, under whatever load it happened to meet. Beacon keeps every run it has ever taken, so a number arrives with its own history attached — and a fix gets checked against the reading that prompted it, not against memory. Nothing here is estimated or cached; if it's on the page, a browser measured it.
Five steps, start to answer
The whole loop, as it happens in the app: list your pages, let Beacon measure them, ship your fix, measure again, and read the difference. Scroll to walk through it.
Paste URLs or upload a sheet, then name the run — Iteration 1. The name is what you'll pick from later, so make it mean something.
Each URL gets a full Lighthouse pass in a real headless Chrome — 15–45 seconds each, one at a time, so they don't skew each other.
Scores and Core Web Vitals for every page in the run. This is your baseline — the thing your fix has to beat.
Same list, new name — Iteration 2. Nothing else to configure; Beacon keeps both runs side by side.
Pick both runs in Compare → By Bulk Run. Every URL is matched up and sorted worst regression first, so the page you broke is line one.
The same run, asked three ways
Beacon keeps the whole run — categories, vitals, conditions — so the dashboard can put three different questions to the same data instead of making you audit three times.
Every audited URL with its latest result, and the vitals underneath the headline number — because a score of 94 says less than an LCP of 1.2s.
/pricing · 3 minutes ago Performance 94 FCP 0.8s Accessibility 100 LCP 1.2s Best Practices 96 TBT 40ms SEO 100 CLS 0.01
Every run ever taken of one URL, newest first, each carrying the conditions it ran under — so a dip you can explain doesn't get mistaken for one you can't.
/pricing · performance 03 Sep 94 ▲ 12 clean 27 Aug 82 ▼ 3 clean 20 Aug 85 — 0 noisy · 2 concurrent 13 Aug 85 — first run
Two bulk runs you named yourself, matched URL by URL and ordered worst regression first — so the page that got slower is the first line, not the twelfth.
"Iteration 1" → "Iteration 2" · 15 URLs /checkout 72 → 58 ▼ 14 /search 80 → 76 ▼ 4 /pricing 82 → 94 ▲ 12 /home 91 → 91 — 0
Why the readings hold up
Lighthouse numbers drift when the machine running them is busy — that's physics, not a bug. An instrument that hides it is the problem. Beacon records what else was happening and shows you.
This URL was audited less than a minute back. A second run wouldn't measure anything new, so Beacon declines it and says so — rather than spending a slot to produce a near-duplicate that looks like corroboration.
This one shared a CPU with two sibling audits. The figure is genuine, but it's stored as concurrentAudits: 2 and badged in the dashboard, so a contention artefact never gets read as a regression.
No neighbours, no cache, no shortcuts — one full Lighthouse pass in a browser that was doing nothing else. These are the runs worth comparing against, and Beacon marks which ones they are.
Chrome extension
Bulk runs cover the pages you remember. The extension covers the rest — it audits your own site as you browse it, so the record fills in from normal work rather than from someone remembering to go and measure.
Install it once, paste in your key, and it watches for navigations to your brand's own domains — nothing else. Land on one and it fires an audit against the dashboard; the result is in History by the time you've finished reading the page. There's a button in the popup for auditing the current page on demand too.
It's built narrow on purpose. Manifest V3, no content scripts, no
<all_urls> — its host permissions list only the dashboard
itself, and each person gets their own API key so revoking one doesn't
break anyone else's install.
Unzip, then load it at chrome://extensions with Developer mode on → Load unpacked.
Three ways to start one
Same cooldown, same contention tracking, same stored shape — so a run someone triggered by hand is still comparable with one the extension fired last Tuesday.