Front-end performance budgets

WHAT THIS TESTS: Whether you can institutionalize front-end performance with enforced limits, not a one-time clean-up that decays.

A GOOD ANSWER COVERS: A performance budget is a set of explicit, agreed thresholds on metrics that shape user-perceived speed, treated as a constraint the team must not exceed. Define both quantity-based limits, total JavaScript bytes, image weight, number of requests, and fonts, and timing or quality limits like the Core Web Vitals: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability, plus time-to-interactive. Enforce it automatically in continuous integration: tools such as Lighthouse CI or a bundle-size check run on each pull request and fail the build when a change pushes a tracked metric past its budget, so regressions are caught before merge. Complement lab tests with real-user monitoring to watch field performance across devices and networks, since lab numbers do not capture real conditions.

COMMON WRONG ANSWERS: Treating a performance budget as a single Lighthouse audit, defining budgets with no CI gate so nothing enforces them, or tracking only lab data and ignoring real users.

LIKELY FOLLOW-UPS: How do you set the initial budget numbers? What do you do when a feature legitimately needs to exceed it? How do lab and field metrics differ? How do you budget for third-party scripts?

ONE CONCRETE EXAMPLE: The team agrees that the main bundle must stay under one hundred seventy kilobytes gzipped and LCP must stay under two and a half seconds on a mid-tier mobile profile. A bundle-size check and Lighthouse CI run on every pull request. When a developer adds a heavy charting library that pushes the bundle to two hundred ten kilobytes, the CI check fails and blocks the merge, prompting them to lazy-load the library instead. The budget thus prevents the slow, invisible bloat that accumulates when no automated gate exists.