What Is a Web Performance Budget?
Learn what a performance budget is, how to set data-driven limits, and how to enforce them automatically in CI.
Expected Interview Answer
A performance budget is a set of measurable limits — such as maximum bundle size, request count, or a target Time to Interactive — that a team agrees not to exceed, enforced automatically in CI so regressions are caught before they ship rather than discovered by users.
Budgets are typically defined per metric type: quantity-based budgets cap total JavaScript, CSS, or image weight in kilobytes; timing-based budgets cap milestones like First Contentful Paint or Time to Interactive on a throttled connection profile; and rule-based budgets cap counts, such as the number of HTTP requests or third-party scripts. Teams pick budgets from real user data (often the 75th percentile of field measurements) rather than arbitrary numbers, so the target reflects what actually matters to real users on real devices. The budget is then wired into the build pipeline — tools like Lighthouse CI or bundlesize fail the pull request if a change pushes any metric over its limit, turning performance into a gate rather than an afterthought. Without automated enforcement, budgets decay into aspirational documentation that nobody checks until the site is already slow.
- Turns performance into an enforced CI gate instead of a best-effort goal
- Forces explicit tradeoff conversations when a new feature would bust the budget
- Anchors targets in real user data rather than arbitrary internal opinions
- Catches regressions at the pull-request stage, before they reach production
AI Mentor Explanation
A performance budget is like a team management setting a hard cap on total overs a bowler can send down in a tournament before the workload risks injury. Coaches track the running total after every match, and if a captain wants to bowl him one more over, they must first drop someone else from the attack to stay under the cap. The cap was set from real fitness data, not a guess, and breaching it triggers an automatic conversation before the next match, not after an injury happens. That measured-limit-enforced-before-the-fact discipline is exactly how a web performance budget works.
Step-by-Step Explanation
Step 1
Gather real user data
Pull field metrics (e.g. 75th percentile FCP, TTI, bundle size) from real users on representative devices and networks.
Step 2
Set budgets per metric
Define explicit limits for JS/CSS/image weight, request counts, and key timing milestones based on that data.
Step 3
Wire budgets into CI
Configure a tool like Lighthouse CI or bundlesize to measure every pull request against the budgets automatically.
Step 4
Fail builds on violation
A budget breach fails the CI check, forcing a deliberate tradeoff (optimize or cut something) before merge.
What Interviewer Expects
- Understanding that budgets must be automated in CI, not just documented
- Knowledge of budget types: quantity-based, timing-based, rule-based
- Awareness that budgets should be derived from real user/field data
- Ability to name concrete enforcement tools (Lighthouse CI, bundlesize, webpack-bundle-analyzer)
Common Mistakes
- Treating a performance budget as a one-time audit rather than a continuously enforced gate
- Picking arbitrary budget numbers instead of grounding them in real user data
- Only budgeting JavaScript size while ignoring timing metrics like TTI or TBT
- Not accounting for third-party scripts, which often blow past internal budgets unnoticed
Best Answer (HR Friendly)
“A performance budget is basically an agreed-upon speed limit for the site — a max bundle size, max load time, or max number of requests — that gets checked automatically every time someone submits new code. If a change would make the site too slow, the build fails and the team has to fix it before it ever reaches users.”
Code Example
// lighthouserc.js
module.exports = {
ci: {
collect: { numberOfRuns: 3, url: ['https://example.com/'] },
assert: {
assertions: {
'resource-summary:script:size': ['error', { maxNumericValue: 300000 }],
'resource-summary:total:size': ['error', { maxNumericValue: 1600000 }],
'interactive': ['error', { maxNumericValue: 5000 }],
'first-contentful-paint': ['warn', { maxNumericValue: 2000 }],
},
},
upload: { target: 'temporary-public-storage' },
},
}Follow-up Questions
- How would you decide the actual numeric target for a bundle-size budget?
- What do you do when a legitimate new feature needs to exceed the current budget?
- How do performance budgets differ for mobile versus desktop users?
- How would you budget for third-party scripts you do not directly control?
MCQ Practice
1. What makes a performance budget effective rather than aspirational?
Budgets only work when a pipeline mechanically blocks regressions before merge.
2. Where should performance budget targets ideally come from?
Grounding budgets in field data ensures targets reflect real user conditions, not best-case dev environments.
3. Which of these is a rule-based performance budget?
Rule-based budgets cap counts (requests, third-party scripts); quantity-based caps weight; timing-based caps milestones.
Flash Cards
What is a performance budget? — A measurable limit on metrics like bundle size or TTI, enforced automatically in CI.
Where should budget numbers come from? — Real user field data, often the 75th percentile, not arbitrary guesses.
Name a budget enforcement tool. — Lighthouse CI or bundlesize, wired into the pull-request pipeline.
What happens without automated enforcement? — Budgets decay into ignored documentation instead of an actual gate.