Performance Budgets: Set Limits to Stay Fast
A performance budget is a hard limit on metrics like bundle size or load time, acting as a guardrail against regressions. It's used in CI/CD to fail builds that exceed size limits or in monitoring to alert when load times degrade.
Why it exists
Performance budgets exist to prevent the slow, gradual degradation of user experience known as "death by a thousand cuts." Without explicit limits, small, seemingly harmless changes accumulate over time, leading to a slow website, frustrated users, and negative impacts on business goals like conversion rates.
The mental model
Think of a performance budget like a financial budget for your website's "weight" and "speed." You have a fixed amount you can "spend" on things like JavaScript size, image data, or load time. Every new feature or library has a cost, and the budget forces your team to have a conversation about whether it's worth it, preventing unintentional performance bloat.
How it works
A budget defines explicit limits for performance metrics. These can be quantity-based (e.g., total JavaScript bundle size must be under 170KB), time-based (e.g., Time to Interactive must be under 5 seconds on a 3G connection), or rule-based (e.g., Lighthouse performance score must not drop below 85). A good budget has two tiers: a "warning" level to signal that you're approaching the limit, allowing for proactive planning, and an "error" level that represents a hard failure, which can block a deployment.
When to use it
Use performance budgets to automate regression prevention. Integrate them into your Continuous Integration (CI) pipeline using tools like bundlesize to check asset sizes on every commit. This provides an early warning system. In production, use budgets in your monitoring tools to track real-user metrics and get alerted when performance goals are missed, helping you correlate slowdowns with business impact.
When not to use it
Don't implement a budget without real-world context. A budget based on a powerful developer machine on a fast office network is useless. If you don't have data on your actual users' devices and connection speeds, your budget will be arbitrary and ineffective. Also, avoid setting a single, rigid "error" threshold without a "warning" level, as this can block development without giving teams a chance to plan for optimization.
One canonical example
A team notices their bounce rate is increasing. After analyzing user data, they find many users are on mid-range Android devices over 3G. They set a performance budget: Time to Interactive (TTI) must be under 5 seconds for this user profile. This time-based budget translates into a quantity-based budget: the total JavaScript payload cannot exceed 170KB. They add a check to their CI pipeline that fails any build where the main JS bundle grows past this limit, forcing a conversation about optimization before the regression is ever deployed.
Interview question
What is the primary problem that performance budgets are designed to solve?
- a.The slow, incremental decline of user experience caused by unmanaged performance regressions.Correct
- b.The inability to automatically optimize website assets for maximum efficiency in the CI/CD pipeline.
- c.The lack of detailed performance metrics available to development teams during the build process.
- d.The difficulty in achieving consistently fast load times across all user devices and networks.
Why? this is the answer
The card explicitly states that performance budgets exist "to prevent the slow, gradual degradation of user experience known as 'death by a thousand cuts'." Option A directly addresses this core problem. Option D describes a general challenge, but budgets specifically tackle preventing *regressions* from an established baseline, rather than just the inherent difficulty of being fast everywhere.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on performance — each one lists the topics its interview covers.
See open roles