Performance Budget: The Financial Discipline of Frontend
Performance Budget: Set page weight and timing limits like a financial budget. Learn to measure with Lighthouse, automate checks in CI/CD, and make conscious decisions about every KB you add.
Thiago Saraiva

Performance Budget: The Financial Discipline of Frontend
Let's talk about budgets.
No, not the project budget. Your page's budget.
The Problem: "Just One More Script"
It starts like this:
- "I'll just add this analytics..."
- "This carousel is pretty light..."
- "Custom font? It's only 50KB..."
- "Chat widget? Everyone has one..."
And suddenly your page is 5MB and takes 12 seconds to load on 3G.
The Financial Analogy
Financial budgeting works like this:
- You have income (limit)
- You define how much you can spend per category
- When one category goes over, you cut from another
- Or you earn more money (not that easy)
Performance budget works the same way:
- You set limits (page weight, load time)
- Each feature "costs" something
- When you go over, something has to go
- Or you optimize what you have
"Just like fiscal discipline, UX discipline and a performance budget can help us achieve our ultimate goals."
Defining Your Budget
Method 1: Competitive Baseline
Compare with your competitors:
- List 3-5 direct competitors
- Measure key metrics for each
- Set your target as 20% better than them
Why 20%? It's the minimum perceptible difference for users to compare two experiences.
| Metric | Competitor A | Competitor B | Average | Your Target (20% better) |
|---|---|---|---|---|
| Load Time | 4.2s | 3.8s | 4.0s | 3.2s |
| Page Weight | 2.5MB | 3.1MB | 2.8MB | 2.2MB |
| Requests | 85 | 112 | 98 | 78 |
Method 2: Industry Baseline
Use aggregated data as reference. HTTP Archive monitors millions of sites:
| Metric | Median (2024) | Your target (better than 75%) |
|---|---|---|
| Page Weight (desktop) | ~2.5MB | < 1.5MB |
| Page Weight (mobile) | ~2.2MB | < 1.2MB |
| Requests | ~70 | < 50 |
| LCP | ~2.5s | < 2.0s |
Method 3: User-Centric
Define based on user experience:
- Typical user: 4G connection, mid-range phone
- Time target: Interactive in < 3 seconds
- Work backwards: How much can it weigh to achieve this?
The Metrics That Matter
Raw Metrics
Page Weight Total bytes transferred. Easy to measure, easy to understand.
Example budget:
- HTML: 50KB
- CSS: 100KB
- JavaScript: 300KB
- Images: 500KB
- Fonts: 100KB
- Total: 1.05MB
Number of Requests Each request has overhead. Even small files add latency.
Example budget:
- Documents: 1
- Stylesheets: 2
- Scripts: 5
- Images: 20
- Fonts: 4
- Total: 32 requests
Timing Metrics
Time to First Byte (TTFB) Time until the first byte arrives. Indicates server performance.
First Contentful Paint (FCP) Time until first content appears.
Largest Contentful Paint (LCP) Time until the largest visible element loads. Core Web Vital.
Time to Interactive (TTI) Time until the page responds to interactions.
Hybrid Metrics
Core Web Vitals (Google)
- LCP: < 2.5s (good), < 4.0s (needs improvement)
- FID/INP: < 100ms (good), < 300ms (needs improvement)
- CLS: < 0.1 (good), < 0.25 (needs improvement)
Lighthouse Score Score from 0-100 based on various metrics.
Speed Index How quickly content is visually populated.
Measurement Tools
During Development
In CI/CD
Lighthouse CI:
Budget file:
Continuous Monitoring
- SpeedCurve — Paid monitoring, very comprehensive
- Calibre — Core Web Vitals focus
- WebPageTest — Free, very detailed
- Google Search Console — Real Core Web Vitals
When the Budget Bursts
Inevitably, someone will want to add something that bursts the budget. Options:
1. Optimize What Exists
- Compress images better
- Code split JavaScript
- Remove unused CSS
- Lazy load below the fold
2. Remove Something
- That widget nobody uses
- Extra font that could be system font
- Duplicate analytics
- Unnecessary polyfills
3. Negotiate
- "We can add it, but we need to remove X"
- "We can add it, but it only loads on demand"
- "This feature costs Y ms of load time. Is it worth it?"
4. Increase the Budget (Rarely)
If the business really needs it, revise the budget. But document the decision and the trade-off.
Performance Culture
Performance isn't one person's responsibility. It's team culture:
- Code review includes bundle size verification
- Large PRs need performance analysis
- Dashboards show real-time metrics
- Alerts fire when budget bursts
Questions for Every PR:
- Does this add JavaScript? How much?
- Does it add new dependencies? What's the size?
- Does it add images? Are they optimized?
- Does it affect LCP or CLS?
Performance Budget - Project X
Page Weight
| Resource | Budget | Current | Status |
|---|---|---|---|
| HTML | 50KB | 32KB | ✅ |
| CSS | 100KB | 87KB | ✅ |
| JS (own) | 200KB | 178KB | ✅ |
| JS (vendors) | 150KB | 142KB | ✅ |
| Images | 500KB | 612KB | ❌ |
| Fonts | 100KB | 96KB | ✅ |
| Total | 1.1MB | 1.15MB | ⚠️ |
Timing
| Metric | Budget | Current | Status |
|---|---|---|---|
| LCP | < 2.5s | 2.1s | ✅ |
| FCP | < 1.8s | 1.4s | ✅ |
| TTI | < 3.5s | 3.2s | ✅ |
| CLS | < 0.1 | 0.08 | ✅ |
Action Needed
- Optimize hero image (currently 280KB, target 150KB)
- Consider WebP/AVIF with fallback
Conclusion
Performance budget isn't about restriction — it's about conscious decisions.
Every KB added is a decision. Every third-party script is a decision. Every custom font is a decision.
With a budget, these decisions go from "whatever" to "is this worth 50KB of our limit?"
And just like financial budgeting, you can "spend" guilt-free when you know you're within the limit.