Uptime and heartbeats
Know whether the release held with availability checks.
LighthouseCore Web VitalsBudgets
Catch the slow page before your users do.
Push Lighthouse runs from CI or your machine. Every run is graded against the budgets you set, and the score, all five categories, the eight timing metrics, and the raw artifact stay beside the commit that caused them.
92
Perf
- Budget≥ 90
- Largest contentful paint1.8s
- Cumulative layout shift0.02
- Total blocking time210ms
Performance results live in the Reliability stage.
One connected loop, held on the stage this capability serves. The other stages stay as context so you can see what feeds in and what comes next.
BD
Discovery
Feedback
Product
Engineering
Release
Reliability
Evidence
Reliability
Know whether it held.
Available now
Incidents and status pages
Keep incident response and customer-facing status context together.
Web performance
Review Lighthouse report evidence against configured targets.
Test intelligence
Investigate test outcomes and flakiness evidence across runs.
Lab runs, graded — not RUM, not APM
This ingests Lighthouse lab runs pushed from CI or your machine. It is not real-user monitoring or application performance monitoring, and it does not crawl your URLs on its own. What it does, it does completely: grade every run against your budgets, keep every metric, and hold the history beside the commit.
Core Web Vitals, plotted on Lighthouse's own thresholds.
Each vital lands on a good → needs-work → poor track with the exact boundaries marked: LCP 2.5s/4.0s, INP 200ms/500ms, CLS 0.10/0.25, FCP 1.8s/3.0s, TBT 200ms/600ms, TTFB 800ms/1800ms.
- LCP1.8sgoodlargest contentful paintgood ≤ 2.5s · poor ≥ 4.0s
- INP240msneeds workinteraction to next paintgood ≤ 200ms · poor ≥ 500ms
- CLS0.02goodcumulative layout shiftgood ≤ 0.10 · poor ≥ 0.25
- FCP1.5sgoodfirst contentful paintgood ≤ 1.8s · poor ≥ 3.0s
- TBT210msneeds worktotal blocking timegood ≤ 200ms · poor ≥ 600ms
- TTFB480msgoodtime to first bytegood ≤ 800ms · poor ≥ 1800ms
Read a PR against main, metric by metric.
Every run keeps every metric, so a branch reads straight against your baseline: what it was, what it is now, how far it moved, and whether that counts as a regression.
PR #482 @ 9f3a1c (mobile) vs main @ a20b74
| Metric | Baseline | This run | Δ | Verdict |
|---|---|---|---|---|
| LCP | 2.1s | 1.8s | ▼ 14% | improved |
| INP | 180ms | 240ms | ▲ 33% | regressed |
| CLS | 0.07 | 0.02 | ▼ 71% | improved |
| FCP | 1.6s | 1.5s | ▼ 6% | improved |
| TBT | 190ms | 210ms | ▲ 11% | regressed |
| TTFB | 500ms | 480ms | ▼ 4% | improved |
One glance shows the page-and-metric that moved.
Because history is stored per page and per metric, the deltas since baseline lay out as a heatmap — severe regressions stand out in pink, wins settle to lime.
| Page | LCP | INP | CLS | FCP | TBT | TTFB |
|---|---|---|---|---|---|---|
| Home | -6% | +2% | -1% | -4% | +3% | 0% |
| Pricing | +4% | +18% | +1% | +2% | +9% | -3% |
| Checkout | +11% | +33% | +6% | +8% | +21% | +2% |
| Dashboard | -8% | -4% | -2% | -5% | -6% | -1% |
| Blog | -12% | -2% | -4% | -9% | -3% | -2% |
improved stable minor severe
A single fast pass hides the tail.
Every run is stored, so each vital reads as a distribution across the window: the p75 you report on, and the p50 / p95 / p99 spread that a one-off run can't show.
LCP
2.1sp75
1.9sp50
2.1sp75
2.8sp95
3.4sp99
INP
260msp75
190msp50
260msp75
420msp95
540msp99
CLS
0.04p75
0.02p50
0.04p75
0.09p95
0.14p99
FCP
1.7sp75
1.5sp50
1.7sp75
2.4sp95
2.9sp99
TBT
230msp75
180msp50
230msp75
410msp95
560msp99
TTFB
620msp75
480msp50
620msp75
1.1sp95
1.5sp99
Budgets are the contract
Set a threshold per metric with a comparison operator — lt, lte, gt, gte, or eq — and a severity of warning or failure, scoped to a branch and an environment. Each run rolls up to one verdict: passed, warning, failed, or not evaluated.
Everything a run stores, and how it gets graded.
From Lighthouse JSON to a graded run.
Push the raw report from CI or your machine. It is normalized, priced against your budgets, and stored with the artifact — the same logic every time.
upload or CInormalizegrade + store
- 01
Run Lighthouse
CI or local, mobile or desktop
- 02
Upload JSON
@lubed/performance-uploader
- 03
Normalize
categories, metrics, resources
- 04
Grade + store
against your budgets, kept as history
The one that fails flags itself.
Each vital fills to how much of your budget it spends. A metric over budget flags and pulses; the passing ones settle and stay still.
per-metricpass / failyour thresholds
LCP
1.8s/ 2.5s
largest contentful paint
CLS
0.02/ 0.10
cumulative layout shift
INP
240ms/ 200ms
interaction to next paint
TBT
210ms/ 200ms
total blocking time
See what loaded, and in what order.
Requests reveal staggered left to right in load order, the same way a network panel draws them, so a render-blocking script is easy to spot.
load orderrender-blockingby type
resource waterfall · load order
- documenthtml
- app.cssstylesheet
- main.jsscript
- hero.webpimage
- inter.woff2font
0 msstart of load1.8 s
Not just performance.
Every run records accessibility, best practices, SEO, and PWA alongside performance, each scored 0 to 100.
accessibilitybest practicesseopwa
- Performance88
- Accessibility98
- Best practices96
- SEO100
How much of each budget this run spent.
Each metric budget reads as a gauge against its wall. INP and TBT are over; LCP and CLS have room. The verdict is the roll-up of these.
lt / lte / gt / gte / eqwarn / failper branch + env
LCP ≤ 2.5s72%
1.8s / 2.5s
INP ≤ 200ms120%
240ms / 200ms · over
CLS ≤ 0.1020%
0.02 / 0.10
TBT ≤ 200ms105%
210ms / 200ms · over
The whole run, not just the headline score.
Every run keeps all five categories, all eight timing metrics, the top opportunities, the largest resources, and the element Lighthouse blamed for LCP — with a lab-variance note, because a single run is a sample.
failedfeat/checkout-v29f3a1cmobilepreviewci
88Perf
98A11y
96Best
100SEO
62PWA
LCP1.8s
FCP1.5s
CLS0.02
INP240ms
TBT210ms
TTI3.1s
Speed Index2.4s
TTFB480ms
Top opportunities
- Eliminate render-blocking resources1.2s
- Reduce unused JavaScript480ms
- Properly size images310ms
- Serve images in next-gen formats180ms
Largest resources
- main.jsscript182 KB
- hero.webpimage96 KB
- app.cssstylesheet48 KB
- inter.woff2font34 KB
LCP element · img.hero__image (hero.webp)
Lab runs vary a little between passes — treat a single number as a sample, not a verdict. Read the trend and percentiles, not one run.
What moved, in one read.
A deterministic digest of the graded run against baseline: the verdict, the metric that moved most, the honest wins, and the recent-run roll-up — summarized from the stored numbers, not generated opinion.
failed
INP regressed +33% on /checkout (mobile).
- 01
INP rose to 240ms against a 180ms baseline — past your 200ms budget, so this run fails.
- 02
Not everything got worse: CLS improved 71% and LCP dropped 14% on the same page.
- 03
The largest render-blocking script is the highest-leverage fix; deferring it recovers about 1.2s of blocking time.
9 passed2 warned1 failed12 runs compared
Push one report
The published @lubed/performance-uploader sends upload-lighthouse --target --file --env from CI or your machine, and there's a workflow for authenticated pages: log in inside your CI runner, run Lighthouse, and upload the JSON — lube never needs your app credentials. Runs can also arrive from a GitHub Action.
See what performance sits beside.
Keep every Lighthouse run beside the commit that caused it.
Start free
Push one report and start tracking.