Performance budgets: making speed a requirement, not a hope
Every project we ship has a performance budget agreed at the start: maximum JavaScript per route, a target Largest Contentful Paint, and a ceiling for layout shift. The budget lives in the repository and is checked on every pull request.
What we budget
- JavaScript shipped per route (compressed)
- LCP under 2.0s on a mid-range phone over 4G
- CLS under 0.05
- Interaction to Next Paint under 200ms
When a change breaks the budget, the build fails, and the conversation happens in code review rather than after launch. Most of the time the fix is small: a lazy-loaded component, a smaller dependency, or a server component instead of a client one.
Speed compounds. Faster pages convert better, rank better and cost less to serve. Treating it as a requirement is the cheapest way to keep it.