Back to posts

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.

TS
Thiago Saraiva
5 min read

Performance Budget

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:

  1. You have income (limit)
  2. You define how much you can spend per category
  3. When one category goes over, you cut from another
  4. Or you earn more money (not that easy)

Performance budget works the same way:

  1. You set limits (page weight, load time)
  2. Each feature "costs" something
  3. When you go over, something has to go
  4. 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:

  1. List 3-5 direct competitors
  2. Measure key metrics for each
  3. Set your target as 20% better than them

Why 20%? It's the minimum perceptible difference for users to compare two experiences.

MetricCompetitor ACompetitor BAverageYour Target (20% better)
Load Time4.2s3.8s4.0s3.2s
Page Weight2.5MB3.1MB2.8MB2.2MB
Requests851129878

Method 2: Industry Baseline

Use aggregated data as reference. HTTP Archive monitors millions of sites:

MetricMedian (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:

  1. Does this add JavaScript? How much?
  2. Does it add new dependencies? What's the size?
  3. Does it add images? Are they optimized?
  4. Does it affect LCP or CLS?

Performance Budget - Project X

Page Weight

ResourceBudgetCurrentStatus
HTML50KB32KB
CSS100KB87KB
JS (own)200KB178KB
JS (vendors)150KB142KB
Images500KB612KB
Fonts100KB96KB
Total1.1MB1.15MB⚠️

Timing

MetricBudgetCurrentStatus
LCP< 2.5s2.1s
FCP< 1.8s1.4s
TTI< 3.5s3.2s
CLS< 0.10.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.