Performance
Designing Frontend Performance Budgets That Teams Actually Use
Performance budgets fail when they are disconnected from release workflow. This guide shows how to set thresholds teams can enforce without friction.
Most teams do not have a tooling problem with performance budgets. They have a product-prioritization problem.
A budget only works if it can block bad change at the same speed your team ships.
Pick metrics that map to user pain
Start with metrics users notice:
- Largest Contentful Paint (LCP)
- Interaction to Next Paint (INP)
- Cumulative Layout Shift (CLS)
Then map those to a concrete budget per route type.
| Route type | LCP (p75) | INP (p75) | JS budget |
|---|---|---|---|
| Marketing pages | <= 2.2s | <= 180ms | <= 170KB |
| Product dashboard | <= 2.8s | <= 220ms | <= 260KB |
| Auth routes | <= 2.0s | <= 150ms | <= 140KB |
Enforce at pull request time
If budgets only run in monthly reports, no one acts on them.
Add a CI step that compares current branch against the baseline and fails when thresholds regress.
npm run build
npm run perf:ciCallout: A budget with no enforcement is a dashboard, not a guardrail.
Budget by critical path
Not every kilobyte is equally expensive. Identify and protect:
- render-blocking CSS
- hydration-critical JavaScript
- third-party scripts on first view
This keeps the conversation focused on user impact instead of raw bundle size.
Publish budget ownership
Attach every budget to an owner and a review cadence.
- owner: team or individual
- rollback policy: what happens on breach
- review schedule: monthly or per release train
Performance quality improves fastest when ownership is explicit.