Engineering
Performance budgets that actually stick
Uplix Team May 10, 2026 8 min read
Start with user timings, not lab scores
Lighthouse is useful for diagnostics, but the number that matters is how long it takes a real user on a real device to do the thing they came for. We instrument every critical path with web vitals and set budgets based on the 75th percentile of actual sessions.
Make the budget a product rule, not a wish
A performance budget that lives in a wiki will be ignored. A budget that blocks a merge request when a new font pushes the total over 120KB is respected. We encode budgets into CI, not culture decks.
The three budgets we enforce
First paint budget, interaction budget, and total JavaScript budget. Each has an owner, a threshold, and a documented escalation path. If a team wants to exceed one, they must also improve another so the net user experience stays flat or better.
What to do when a budget breaks
When a budget breaks, we don't look for a scapegoat; we look for the slowest asset and either split, defer, or remove it. The fix is usually a conversation about scope, not a clever trick in the bundler.
The takeaway
Speed is a design constraint. Treat it like one from the first wireframe and it becomes a creative advantage instead of a last-minute panic.
