Day 21 of 60
·
E2E, UI, accessibility
Performance budgets / Lighthouse CI
Frontend bloat is a creep, not a crash. A budget is a guardrail against a regression nobody else will notice for months.
ProblemFrontend bloat creeps in; LCP, TTI, and bundle size regress without a guardrail.
How it works
Set hard budgets per route. Run Lighthouse on every PR. Block the merge if a budget is exceeded.
What it catches
Performance regressions, accidental bloat, unoptimised images, unminified JS. Especially valuable for SEO-sensitive sites.
Tools
Lighthouse CI · OSS WebPageTest · OSS SpeedCurve · SaaS
Verdict by project size
Small
Skip
Medium
Rec
Large
Must
Extra-large
Must
Cost
| Project size | Setup | Maint / mo | Tool / mo | CI / run |
|---|---|---|---|---|
| Small <10k LOC | 4h | 1h | $0 | +1m |
| Medium 10–100k LOC | 2d | 5h | $0 | +3m |
| Large 100k–1M LOC | 8d | 20h | $500 | +8m |
| Extra-large >1M LOC | 25d | 60h | $5k | +15m |
Setup = engineer-days to first useful run ·
Maint = engineer-hours / month at steady state ·
Tool = out-of-pocket $ / month ·
CI = minutes added (or saved) per pipeline run
Lifecycle & ownership
When in lifecycle
Test Release
Per release · Runs before promotion to production.
Who owns it
QA / Test Engineer
Strategy, exploratory, eval design
Collaborates with: Developer
Reference implementations
-
Lighthouse CI recipes
Performance-budget checks wired into CI for web applications.
-
web.dev performance budgets
Practical budget-setting guidance for page weight and user-centric metrics.
-
Sitespeed.io examples
Performance regression examples with browser metrics and budgets.
Quick check
Performance budgets work because they…
One question. Pick the best answer. Your streak is saved locally on this device.
Save the lesson
Download SVG ↓
Screenshot for a 1:1, drop it in Slack, or download the SVG.