Q084: Frontend Performance Budgets

What Interviewers Want To Evaluate

This question tests whether you can make performance a repeatable engineering practice. Interviewers want budget types, measurement strategy, CI checks, field data, ownership, rollout, exceptions, and how performance connects to product outcomes.

Senior frontend engineers should not only fix slow pages after complaints. They should create systems that prevent regressions.

Short Interview Answer

Frontend performance budgets define acceptable limits for user-facing metrics and technical contributors such as LCP, INP, CLS, JavaScript size, image size, route load time, long tasks, and render cost. I would set budgets from real user data and product goals, enforce critical budgets in CI where possible, monitor field data in production, assign ownership, and allow documented exceptions with follow-up plans. Budgets should guide decisions, not become arbitrary numbers.

Detailed Interview Answer

A performance budget is a constraint that protects user experience. Without budgets, every team can add a little JavaScript, one more image, one more third-party script, and one more expensive interaction until the product feels slow.

Start by defining what matters:

Which routes are business critical?
Which users and devices matter most?
What metrics map to user experience?
What technical signals predict regressions?
Where can we enforce automatically?
Who owns exceptions?
How do we review trends?

Budget Types

Useful budgets include:

LCP target per route
INP target for key interactions
CLS threshold
JavaScript bundle size
route-level client component cost
image weight
third-party script count
long task count
table row render cost
hydration error rate

Not every budget belongs in CI. Some metrics need field data.

Lab and Field Data

Lab data is controlled and repeatable. It is useful for CI and local debugging. Field data shows real users, devices, networks, geographies, and browsers.

Senior engineers should use both. Lab checks catch regressions early. Field data tells whether users actually improved.

CI Enforcement

CI can check bundle size, route build output, Lighthouse thresholds, static asset size, dependency changes, and sometimes performance traces.

CI should block severe regressions but avoid noisy flaky checks. If a budget is too unstable, it may be better as a warning or dashboard until measurement improves.

Ownership

Budgets need owners. A route owner should know when their page exceeds a budget. A platform team might own shared tooling, dashboards, and regression alerts.

Without ownership, alerts become background noise.

Exceptions

Sometimes a product choice intentionally exceeds a budget. For example, a rich editor may require more JavaScript than a static page.

Exceptions should be documented with reason, scope, expiration or review date, and mitigation plan.

Common Mistakes

A common mistake is setting budgets from ideal numbers rather than real context. Another is measuring only homepage performance while logged-in product routes are slow.

Another mistake is focusing only on bundle size while ignoring interaction latency and render cost.

Senior Trade-Offs

Strict budgets protect performance but can slow delivery if applied without judgment. Loose budgets are easier to satisfy but may fail to prevent regressions.

The senior approach is to set budgets by route importance, device reality, and user impact.

Code or Design Example

A route performance budget can be represented as configuration.

type RoutePerformanceBudget = {
  route: string;
  lcpP75Ms: number;
  inpP75Ms: number;
  clsP75: number;
  maxClientJsKb: number;
  owner: string;
  exceptionUntil?: string;
};

const dashboardBudget: RoutePerformanceBudget = {
  route: "/dashboard",
  lcpP75Ms: 2500,
  inpP75Ms: 200,
  clsP75: 0.1,
  maxClientJsKb: 220,
  owner: "analytics-ui",
};

The numbers should come from product context and real measurements.

Production Example

Suppose a dashboard grows from 180KB to 420KB of client JavaScript after adding chart libraries and a rich table. CI warns on bundle increase, field data shows worse INP, and session traces show long tasks during filter changes.

The fix may involve route-level code splitting, lazy loading charts, virtualizing the table, moving transforms to the server or worker, and removing unused dependencies.

Review Process

Performance budgets should be reviewed regularly. Look at trends, not only failures. A slow gradual decline is still a problem.

Reviews can happen monthly or around major launches. Bring route owners, platform engineers, and product partners when user impact is significant.

Lead Engineer Perspective

A lead engineer should make performance visible and actionable. That means dashboards, alerts, ownership, review rituals, and shared guidelines.

The goal is to make performance part of normal delivery, not a late-stage emergency.

Revision Notes

Performance budgets connect product goals, user metrics, technical limits, CI checks, field monitoring, ownership, and exceptions.

Key Takeaways

Budgets prevent performance from eroding one small change at a time.

Follow-Up Questions

1. What metrics belong in a performance budget?
2. What should CI enforce?
3. How do lab and field data differ?
4. How do you set budgets by route?
5. How do you handle exceptions?
6. How do third-party scripts affect budgets?
7. How do you assign ownership?
8. How do you avoid noisy alerts?
9. How do budgets influence design decisions?
10. How do you prove performance improved?

How I Would Answer This In A Real Interview

I would explain that budgets make performance repeatable. I would define route-level user metrics and technical limits, use CI for stable checks, monitor field data, assign ownership, document exceptions, and review trends with product impact in mind.