Q195: Performance Budgeting and Regression Prevention
What Interviewers Want To Evaluate
This question checks whether you can keep performance healthy over time. Interviewers want budgets, bundle limits, Core Web Vitals targets, CI checks, monitoring, ownership, third-party governance, regression triage, and trade-off communication.
Senior answers should focus on prevention, not heroic cleanup after every release.
Short Interview Answer
A performance budget defines acceptable limits for metrics like JavaScript size, route load time, LCP, INP, CLS, image weight, third-party scripts, and critical workflow latency. Budgets should be visible in CI and production monitoring. They prevent regressions by making performance a release constraint with owners, alerts, review rules, and exception processes. The best budgets are tied to user impact, not arbitrary numbers.
Detailed Interview Answer
Performance decays when nobody owns it.
Every feature can add:
more JavaScript
more CSS
larger images
more data fetching
more hydration
more third-party scripts
more rendering work
Budgets create boundaries before the product becomes slow.
Budget Types
Useful budgets:
JavaScript per route
CSS size
image weight
font files and variants
third-party script count
LCP target
INP target
CLS target
time to interactive workflow
API payload size
hydration cost
Choose budgets that match the product.
Route-Level Budgets
Global bundle size can hide route problems.
Route-level budgets are better.
home route
question route
practice console route
dashboard route
admin route
Each route has different user expectations and constraints.
CI Checks
CI can catch obvious regressions.
Examples:
bundle size diff
Lighthouse synthetic run
image size lint
dependency size check
TypeScript build
static route generation
performance smoke test
CI should block severe regressions and warn on smaller ones.
Field Monitoring
CI cannot represent all users.
Production monitoring should track:
Core Web Vitals
custom workflow marks
route-level regressions
release-level changes
device and region segments
third-party impact
error spikes
Field monitoring confirms whether users are actually affected.
Exception Process
Sometimes a feature needs more budget.
Good exception process:
explain user value
show measured cost
consider alternatives
define temporary or permanent exception
document owner
add follow-up cleanup if needed
monitor impact after release
This keeps budgets practical rather than dogmatic.
Third-Party Governance
Third-party scripts are frequent budget breakers.
Review:
business owner
loaded routes
async or blocking behavior
data collected
performance impact
privacy impact
fallback behavior
removal process
Every script should have a reason to exist.
Regression Triage
When a budget fails:
identify changed asset or metric
tie to commit or dependency
measure affected route
estimate user impact
offer alternatives
decide block, allow, or exception
track follow-up
Performance review should be calm and evidence-based.
Ownership
Budgets need owners.
Possible owners:
frontend platform
route team
design system
performance working group
release manager
feature owner
Ownership should match who can act.
Common Mistakes
A common mistake is defining budgets nobody sees.
Another mistake is using one global budget for every route.
Another mistake is blocking releases with flaky synthetic tests.
Another mistake is not tracking field recovery.
Another mistake is allowing third-party scripts without owners.
Senior Trade-Offs
Strict budgets protect users but can frustrate teams if they are arbitrary.
Soft budgets create awareness but may be ignored.
The senior approach combines automated checks, field monitoring, documented exceptions, and clear ownership.
Debugging Workflow
When performance budget fails:
read the budget diff
identify route and asset
compare with baseline
profile if runtime metric changed
check third-party changes
review dependency additions
propose smaller alternative
document exception if accepted
monitor production after release
Interview Framing
Define performance budgets, explain route-level budgets, CI and field monitoring, exception handling, third-party governance, and ownership.
Revision Notes
Budgets turn performance from a preference into an engineering contract.
Key Takeaways
Prevent regressions before users become your monitoring system.
Follow-Up Questions
- What is a performance budget?
- What metrics can be budgeted?
- Why are route-level budgets useful?
- What belongs in CI?
- Why is field monitoring still needed?
- How should exceptions work?
- How do you govern third-party scripts?
- Who should own budgets?
- How do you avoid flaky budget checks?
- How do you communicate budget failures?
How I Would Answer This In A Real Interview
I would say performance budgets define acceptable limits for route assets, Core Web Vitals, workflow latency, and third-party cost. I would enforce severe issues in CI, monitor real users by route and release, require owners for exceptions, and use budgets to prevent performance decay over time.