Why performance degrades
Every fast website has the same origin story: someone cared about performance. And every slow website has the same decline: no one noticed when it stopped being fast. A new analytics script here, a carousel library there, an unoptimised image that slipped through review. Each addition is small. The cumulative effect is not.
Performance budgets exist to make this degradation visible before it becomes a problem. They turn speed from an aspiration into a measurable, enforceable requirement.
What to measure
A good performance budget focuses on metrics that correlate with user experience, not vanity numbers. We recommend starting with three:
- Largest Contentful Paint (LCP) — how quickly the main content becomes visible. Budget: under 2.5 seconds.
- Total blocking time (TBT) — how long the main thread is unresponsive. Budget: under 200 milliseconds.
- Total transfer size — the weight of everything downloaded. Budget: under 500 KB for initial load.
How to enforce them
A budget that only lives in a document is not a budget. It needs to be automated. The most effective approach is integrating performance checks into your CI pipeline so that builds fail — or at least warn — when a budget is exceeded.
Tools like Lighthouse CI, bundlesize, and webpack-bundle-analyzer make this straightforward. The goal is not to block every deployment but to surface regressions early enough to address them before they ship.
A performance budget is not a ceiling you occasionally hit. It is a constraint that shapes every decision.
Setting realistic budgets
Start with your current metrics, not an ideal target. If your LCP is currently 4 seconds, a budget of 1.5 seconds will be ignored because it is unachievable without a rewrite. Set the budget slightly below your current baseline and tighten it over time as you improve.
The point is not perfection. It is preventing regression and creating accountability for the decisions that affect your users most directly.