A performance budget is a set of constraints on the metrics that affect user experience: page weight, load time, time to interactive. You define the thresholds before you start building. You enforce them throughout delivery. Without one, every feature addition makes the application a little slower, and nobody notices until users start complaining.
What You Need to Know
- A performance budget sets measurable limits on page weight, load time, and time to interactive before development begins
- Without a budget, enterprise applications degrade incrementally as features accumulate
- The budget should be enforced in the build pipeline, not by manual checking
- NZ-specific considerations matter: variable connection speeds outside major centres, older government-issued devices, and mobile users on cellular networks
Why Budgets Work
Performance problems in enterprise web applications are rarely dramatic. Nobody ships a page that takes thirty seconds to load. The problem is incremental. A 200KB JavaScript library here. An unoptimised image there. A third-party analytics script. A font file. A carousel component that seemed like a good idea in the design phase.
Each addition is individually reasonable. The cumulative effect is an application that loads in eight seconds instead of three. For users on fast connections and new hardware, eight seconds is tolerable. For users on rural broadband, older devices, or mobile networks, it's the difference between usable and unusable.
A performance budget makes the cumulative effect visible. Instead of asking "is this addition fast enough?" you ask "does this addition keep us within budget?" The question changes from subjective to measurable.
Setting the Budget
A performance budget needs specific, measurable thresholds. Here's the baseline we use at IDESIGN for enterprise web applications.
1. Page Weight
Total transferred size for a page load, including HTML, CSS, JavaScript, images, and fonts.
| Metric | Budget |
|---|---|
| Total page weight | Under 1MB (initial load) |
| JavaScript | Under 300KB (compressed) |
| CSS | Under 100KB (compressed) |
| Images per page | Under 500KB total |
| Web fonts | Under 100KB total |
These numbers aren't aspirational. They're achievable with modern tooling and reasonable discipline. The JavaScript budget is the one that requires the most attention, because JavaScript frameworks and their dependencies accumulate fast.
2. Load Time
Measured on a simulated 3G connection with CPU throttling, which approximates a user on a mobile device or slow connection.
| Metric | Budget |
|---|---|
| First contentful paint | Under 2 seconds |
| Time to interactive | Under 5 seconds |
| Speed index | Under 4 seconds |
We measure on simulated 3G rather than a fast office connection because enterprise users aren't always on fast office connections. Field workers, regional offices, mobile users. The budget should reflect the worst reasonable case, not the best.
3. Runtime Performance
For interactive applications with frequent user input.
| Metric | Budget |
|---|---|
| Input latency | Under 100ms |
| Frame rate during interaction | Above 30fps |
| Memory usage growth | Under 50MB over 30 minutes of active use |
The memory metric matters for enterprise applications because users keep them open for hours. A memory leak that adds 5MB per minute means 300MB after an hour. On older machines, that's enough to make the browser sluggish.
Enforcing the Budget
A budget that isn't enforced is a guideline. Guidelines get ignored when deadlines approach. Enforcement means automated checks that fail the build or flag a warning when a threshold is exceeded.
Step 1: Measure During Development
Every developer should be able to check performance locally. The tools are free.
- Lighthouse in Chrome DevTools gives a performance score and specific metrics for any page
- webpack-bundle-analyzer (or equivalent) visualises the JavaScript bundle and shows exactly what's contributing to page weight
- Chrome Performance tab profiles runtime performance and identifies bottlenecks
Set up a script that runs Lighthouse against the development build and reports the metrics. Developers should see the performance impact of their changes before they commit.
Step 2: Automate in the Build Pipeline
Add a performance check to your CI/CD pipeline. When a pull request is submitted, the pipeline builds the application and runs a Lighthouse audit. If any metric exceeds the budget, the check fails.
This is the enforcement mechanism. It catches regressions before they reach production. A developer adds a large library and the build fails with "JavaScript budget exceeded: 340KB / 300KB." The conversation happens at the right time, before the change is merged, not three months later when users complain.
Step 3: Monitor in Production
Budgets set during development need validation in production. Real User Monitoring (RUM) tools collect performance data from actual users on actual devices and connections.
The gap between lab data (Lighthouse) and field data (RUM) is often significant. Lab tests use a controlled environment. Field data includes the user on a 2012 laptop with fifteen browser tabs open. Both are valuable. The budget applies to lab data. Field data validates whether the budget is tight enough.
Common Budget-Breakers
Five things that blow performance budgets on enterprise projects, ranked by frequency.
Unoptimised images. A single hero image saved as a 2MB PNG instead of a compressed WebP can exceed the image budget alone. Use responsive images with srcset, compress aggressively, and consider lazy loading for below-the-fold images.
JavaScript framework overhead. React, Angular, and Vue each add a baseline JavaScript cost. React plus ReactDOM is roughly 40KB compressed. That's fine. React plus a state management library plus a routing library plus a UI component library plus a date library can easily reach 200KB before you've written any application code. Audit your dependencies regularly.
Third-party scripts. Analytics, chat widgets, A/B testing tools, advertising pixels. Each one adds weight and often executes JavaScript that blocks the main thread. Audit third-party scripts quarterly. Load them asynchronously. Remove the ones nobody uses.
Web fonts. A single typeface in four weights is typically 80-120KB. Two typefaces doubles that. Subset fonts to include only the characters you need. Use font-display: swap to prevent invisible text during loading.
Uncontrolled API responses. A page that fetches a list of 500 items when the user can see 20 is transferring 25 times more data than necessary. Paginate API responses. Return only the fields the frontend needs. Compress response payloads.
The NZ Context
Performance budgets matter more in New Zealand than in markets with uniformly fast infrastructure. While Auckland and Wellington have solid broadband and mobile coverage, regional NZ is different. Fibre rollout is ongoing. Rural areas rely on wireless broadband or cellular connections that vary in speed and reliability.
When we test on simulated 3G, we're not being conservative. We're testing for the actual conditions that a significant portion of NZ enterprise users operate in.
John Li
Chief Technology Officer
Government clients in particular serve users across the entire country. A portal that works well in a Wellington office and barely functions in a Gisborne community centre isn't meeting its brief.
Getting Started
If you don't have a performance budget, start with one metric: total page weight under 1MB. Measure it. Enforce it. Then add time to interactive. Then JavaScript budget. Build the discipline incrementally rather than trying to measure everything at once.
The performance budget isn't about achieving a perfect score. It's about preventing the slow degradation that happens when nobody's watching. Set the thresholds. Automate the checks. Review the numbers quarterly. Your users, especially the ones on slower connections, will benefit from the discipline even if they never know it exists.