What’s up everyone? I’m trying to put some real performance guardrails on a small frontend app that’s slowly turning into a “real product”, and right now our budget is basically vibes. If I set strict limits (bundle size, render time, API latency), releases get blocked and people work around it; if I keep it loose, we ship and then the app gets janky, especially on a pixel-art canvas screen.
How do you design budgets and observability so they’re enforced enough to matter without becoming a constant false-alarm factory that the team learns to ignore?
okay so the pixel-art canvas part is the thing to care about first.
I’d gate on stuff users actually feel: frame time, long tasks, input delay on that screen. Bundle size is mostly a watch metric for me unless it’s clearly tied to a real slowdown. We had a similar mess on a little React app at work and the bundle budget turned into background noise fast, but the jank budget got people’s attention because it was tied to one obvious flow.
What’s worked better is keeping the hard gate tiny. One or two flows, measured in CI and in prod, and use delta instead of some sacred absolute number. So yeah, fail a PR when p95 frame time gets worse by more than a small amount, but don’t block a release because someone added 4 KB and the app still feels fine.
are you measuring the canvas in real usage yet, or just in lab runs? That part changes how noisy this gets.
The budgets that don’t get ignored usually have an “owner” in the UI itself, not just in CI. For that canvas screen, I’ve had better luck budgeting a concrete unit like “ms per frame while drawing N tiles” (or “max dropped frames during a 5s paint loop”), then shipping a tiny dev-only overlay that shows it live so people see the regression while they’re working instead of only as a red CI job. One caveat: delta-based CI gates get weird when the machine is noisy, so we ended up pinning the runner (same hardware) and running each perf check three times, taking the median. Not sure what your setup is, but that one change cut our false alarms a lot.
I like the “owner in the UI” idea because it turns perf into something you can feel, not a number you only meet in CI. The only thing I’d watch is the overlay becoming visual noise, so we’ve had better adoption when it’s off by default and only pops when you cross the budget.
