Lesson 5 of 30

Setting Performance Budgets

Q: Your team wants to stop performance from regressing over time as new features ship. How would you go about setting performance budgets, and how would you decide what the actual numbers should be?

A strong answer covers: Defines a performance budget as a concrete, measurable limit treated as a hard constraint, not an aspiration; Insists budget numbers be tied to a specific, real reason (a business or user-experience consequence) rather than an arbitrary round number, and explains why that's what makes a budget hold up under pressure; Distinguishes build-time budgets (e.g. bundle size, enforced in CI) from runtime budgets (e.g. LCP/INP, observed via RUM/field data), and recognizes both are needed since they catch different problems; Doesn't conflate 'setting a sane number' with 'having the tooling to enforce it' — recognizes these as related but separate problems.

A performance budget is only real if it's tied to a specific consequence someone cares about. An arbitrary round number is advice; a budget backed by a reason is a constraint the team will actually defend under deadline pressure.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

Which of these is most likely to survive being overridden under deadline pressure?

"LCP under 2.5s, because that's the Core Web Vitals 'good' threshold and affects search ranking""Let's just try to keep the page fast""LCP under 2 seconds, because that's a nice round number"

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Setting Performance Budgets

What interviewers actually ask about this, and what a strong answer has to cover.

Your team wants to stop performance from regressing over time as new features ship. How would you go about setting performance budgets, and how would you decide what the actual numbers should be?

A strong answer covers

Defines a performance budget as a concrete, measurable limit treated as a hard constraint, not an aspiration
Insists budget numbers be tied to a specific, real reason (a business or user-experience consequence) rather than an arbitrary round number, and explains why that's what makes a budget hold up under pressure
Distinguishes build-time budgets (e.g. bundle size, enforced in CI) from runtime budgets (e.g. LCP/INP, observed via RUM/field data), and recognizes both are needed since they catch different problems
Doesn't conflate 'setting a sane number' with 'having the tooling to enforce it' — recognizes these as related but separate problems

Likely follow-ups

Someone proposes a bundle-size budget of exactly 100KB because it's a round number. How would you push back on that, and what would you ask for instead?
A build-time bundle-size budget passes but the runtime LCP budget still fails in the field. What does that combination tell you, and what would you investigate next?

The plain-language idea

A performance budget is a concrete, agreed-upon limit on a measurable quantity, treated as a hard constraint rather than an aspiration. Examples of what gets budgeted: total JavaScript bundle size, LCP time, number of network requests on first load, total page weight. The word "budget" is deliberate: the same discipline that applies to a financial budget applies here, a number the team commits to not exceeding, not a vague direction to move in.

The part that actually matters is why the number was chosen. "LCP under 2.5 seconds, because that's the Core Web Vitals 'good' threshold and it directly affects search ranking" is a budget that survives contact with a deadline, because breaking it has a named, specific consequence. "Let's just try to keep things fast" isn't a budget at all — it has no number, and more importantly, no one can point to what breaking it actually costs. When a budget is arbitrary (a round number picked because it sounded reasonable), it's the first thing that gets waived when a feature needs to ship, precisely because no one can say what waiving it actually loses.

Budgets also apply at different points in the pipeline, and it matters which point you're constraining:

Build-time budgets — enforced when code is built, before it ships. A bundle-size limit checked in CI is the clearest example: the build literally fails if a new dependency pushes the JS bundle over the limit.
Runtime budgets — observed from real usage after code ships, via RUM. An LCP or INP budget is inherently runtime, because those metrics only exist once a real page actually loads and a real user interacts with it.

See it in a real thing: two budgets for the same page

Bundle size budget (build-time): main JS bundle ≤ 170KB gzipped
  Reason: this repo's own measurements showed bundles past this size
  pushed Time to Interactive past 3s on a mid-tier Android device.
  Enforced: build fails in CI if exceeded.

LCP budget (runtime): LCP ≤ 2.5s for the 75th percentile of real visits
  Reason: 2.5s is the Core Web Vitals "good" threshold; missing it
  affects search ranking and is Google's own stated cutoff.
  Enforced: watched via field data (CrUX / RUM), not a build check.

These are two different kinds of constraint on two different quantities, checked at two different points, and each one is written with a reason a stakeholder outside the frontend team could actually understand and defend. That's what makes them enforceable rather than aspirational.

What people usually miss

Watch out

A budget without an enforcement point is just a preference. "We try to keep the bundle small" isn't a budget; "the build fails past 170KB" is — the difference is whether breaking it has an automatic, immediate consequence.
Build-time and runtime budgets fail differently, and both matter. A bundle-size budget can pass in CI while the runtime LCP budget still fails in the field, because build-time budgets can't see network conditions, device diversity, or third-party scripts loaded outside the build.
The reason behind a number is what makes it defensible, not the number's precision. A budget of "2.5s because that's the industry-standard 'good' threshold" holds up in a conversation with product or leadership in a way that "2.5s because it felt right" doesn't.
Setting a budget and enforcing it are two different problems. This lesson is about choosing a sane, defensible number — the tooling that actually catches a budget violation before it ships (CI checks, bundle analyzers, alerting on RUM data) is worth its own dedicated attention.

Why this matters in interviews

"How would you prevent this app's performance from regressing over time as more features get added?" is a common systems-thinking question, and naming specific, reasoned budgets tied to real thresholds (rather than a general "keep an eye on it") is what separates a process-minded answer from a vague one.