Q229: Performance Budgets, CI and Regression Automation

What Interviewers Want To Evaluate

Interviewers want to know whether you can prevent performance regressions, not only fix them after users complain.

They check budget types, CI automation, bundle analysis, route-level thresholds, lab vs field data, ownership, exceptions, dashboards, and rollout policy.

Short Interview Answer

Performance budgets are agreed limits for metrics like route JavaScript size, LCP, INP, CLS, image weight, third-party cost, or long tasks. I enforce fast deterministic checks in CI where possible, monitor field metrics after deployment, and require owners for exceptions. Budgets should be route-specific and tied to user experience, not just arbitrary global numbers.

Detailed Interview Answer

Performance has to be protected continuously.

Otherwise every feature adds a little cost.

Eventually the product feels slow.

Budgets turn performance into an engineering contract.

Types Of Budgets

Common budgets:

JavaScript per route
CSS per route
image weight
font weight
third-party script cost
LCP in lab
INP in field
CLS in lab and field
long task count
server response time
hydration cost

Not every budget belongs in CI.

Some require field monitoring.

Route-Level Budgets

Global budgets can hide route problems.

Better:

homepage JS <= 170KB
question reader JS <= 140KB
practice console JS <= 260KB
batch page JS <= 150KB

Different routes have different jobs.

A practice console may legitimately ship more JavaScript than a static chapter.

CI Checks

CI is good for deterministic checks.

Examples:

typecheck
production build
bundle size report
asset size limits
Lighthouse smoke checks
static analysis for third-party additions
dependency size warnings

CI should fail on clear regressions and warn on noisy signals.

Field Monitoring

Field data catches real user conditions.

Use field monitoring for:

Core Web Vitals
device class segmentation
browser segmentation
geography
release comparison
flag comparison
route-level experience

Field metrics move slower than CI but represent real users.

Exception Process

Budgets need an exception policy.

An exception should include:

owner
reason
affected route
expected user value
duration
mitigation
follow-up issue
approval

Without this, budgets become either ignored or hostile.

Bundle Regression Example

Suppose a question page suddenly imports a chart library.

Investigation:

check route bundle report
trace import chain
identify client boundary
move chart to lazy interaction
or render chart on server
or split into optional route
add budget guardrail

The goal is to keep static reading routes light.

Third-Party Governance

Third-party scripts need budgets too.

Track:

network cost
main-thread cost
load timing
owner
business purpose
consent requirement
fallback behavior

Vendor scripts often regress INP without changing your application code.

Budget Review Rhythm

Budgets should be reviewed.

Cadence:

weekly dashboard review
release comparison
incident review after regression
quarterly threshold adjustment
cleanup stale exceptions
audit third-party scripts

Budgets are living constraints.

Common Mistakes

Common mistakes include:

using one global JS budget
failing CI on noisy lab metrics
not tracking field data
allowing permanent exceptions
ignoring third-party scripts
not assigning owners
choosing budgets unrelated to user experience

Budgets should guide decisions, not create theater.

Senior Trade-Offs

Too strict:

slows delivery
creates budget fatigue
encourages workarounds

Too loose:

regressions accumulate
users suffer
cleanup becomes expensive

The senior move is route-level budgets with sensible escalation.

Interview Framing

In an interview, say:

I use CI for deterministic budget checks and field monitoring for real user outcomes. Budgets are route-specific, owned, and tied to user impact, with an exception process for deliberate trade-offs.

Revision Notes

• Budgets prevent slow performance drift.
• Route-level budgets are better than one global number.
• CI is best for deterministic checks.
• Field data proves real user impact.
• Exceptions need owner, reason, and expiry.
• Third-party scripts need budget governance.

Follow-Up Questions

• What should be included in a performance budget?
• Why are route-level budgets useful?
• What performance checks belong in CI?
• How do field metrics complement lab checks?
• What should a budget exception include?

How I Would Answer This In A Real Interview

I would say performance budgets are how teams prevent regressions from accumulating. I would set route-specific budgets for JavaScript, assets, third-party cost, and key metrics, enforce deterministic checks in CI, and monitor Core Web Vitals in the field. I would also define an exception process with ownership and expiry so budgets support delivery without becoming ignored.