Performance conversations often happen too late, after a screen already feels expensive and the team is guessing where the problem started.
A better approach is to define a small performance budget before the UI gets dense.
What a useful budget looks like
Not every team needs formal numbers for everything. A lean budget is enough:
- Keep initial route rendering predictable on mid-range devices.
- Avoid image-heavy lists without virtualization strategy.
- Limit repeated network waterfalls during navigation.
- Track JS thread spikes when adding animations or complex forms.
Measure the things users notice first
Developers often jump to micro-optimizations while the visible problems are simpler:
- Long skeleton states
- Scroll hitching on real devices
- Navigation transitions that stall
- Slow list filtering after local state changes
A table for quick team alignment
| Concern | Budget question |
|---|---|
| Initial screen | Does it feel ready quickly on a mid-range phone? |
| Lists | Is virtualization in place before the list gets large? |
| Images | Are sizes and caching strategy defined? |
| Animations | Do they stay smooth when network work is happening? |
Final thought
The best performance budget is not the most precise one. It is the one the team actually revisits before every new feature increases the cost of the screen.