Performance Budgets
A performance budget is a product constraint that sets explicit limits on speed, weight, responsiveness, and cost before implementation choices sprawl.
Core idea
Performance is not a polish pass. It is a budget. If a product must feel instant, the architecture, dependency choices, animation choices, model calls, and agent topology have to fit inside a number.
Google's web guidance treats budgets as guardrails for metrics such as bundle weight, render timing, and Core Web Vitals. The same model applies to agents: set budgets for end-to-end latency, p95 run time, model cost, tool-call count, and human wait states. Source: web.dev performance budgets, https://web.dev/articles/performance-budgets-101, 2026-06-19; Core Web Vitals, https://web.dev/articles/vitals, 2026-06-19
Budget types
| Budget | Example | Why it matters |
|---|---|---|
| Load | LCP under target, JS bundle under cap | The user decides whether the app feels heavy before using the feature. |
| Interaction | INP under target, command palette opens in ~100ms | Interfaces for repeated work must feel immediate. |
| Animation | no layout-shift choreography, reduced-motion support | Motion should clarify state, not steal frame budget. |
| Agent loop | useful progress within 2s, full p95 under task-specific target | Agent UX is wall-clock, not single-call speed. |
| Tool count | max sequential tool calls for interactive tasks | Each tool call adds latency and failure surface. |
| Cost | max model/machine spend per run | Services-as-software only works if unit economics close. |
Budget before architecture
| Requirement | Likely architecture |
|---|---|
| Sub-100ms local interaction | Client state, cached data, no network on critical path |
| 300ms autocomplete | small model or local index, no multi-agent fanout |
| 5s answer with provenance | retrieval + streaming + bounded tool calls |
| 60s research brief | parallel search agents, cached prefixes, visible progress |
| Overnight autonomous work | durable runtime, checkpoints, notification, cost cap |
This is why Latency Budgets for Agents is a product-design page, not only an ops page. A multi-agent topology that is brilliant at 15x token spend may be unusable inside a chat-like interaction.
Brotzky's "make the entire app fast" bookmark is a compact frontend version of the same invariant: speed usually comes from architectural simplification, key-data prefetching, correct Suspense boundaries, and loading states that explain genuine latency. The lesson is not to add a spinner after the fact; it is to make speed the first shipped improvement and measure whether the surface still feels immediate. Source: X/@brotzky, 2026-03-12
Enforcement
- Measure p50/p95/p99, not vibes.
- Put budgets in CI where possible: bundle size, Lighthouse, Web Vitals, smoke timings.
- For agents, log model calls, tool calls, wall time, queue time, sandbox time, and cost.
- Treat regressions as product bugs.
- Make the UI expose real progress when the budget is long by design.
Kevin defaults
- UI interactions should resolve in about 100ms when local.
- Agent surfaces must show last real event during long runs.
- No decorative animation should compromise scanning or input latency.
- If a model/tool choice blows the budget, route differently before adding spinners.
- Expensive autonomous work needs a cost ceiling and an artifact worth the spend.
Timeline
- 2026-07-04 | Added Brotzky's app-speed row as a frontend budget checklist: simplify architecture, prefetch key data, fix Suspense boundaries, and use loading states for real waits rather than as a substitute for speed. Source: X/@brotzky, 2026-03-12
- 2026-06-19 | Created to connect frontend performance, agent latency, product UX, and observability into one budget concept. Source: whole-wiki concept review, 2026-06-19
- 2026-06-19 | Linked Agent Unit Economics and Prompt-Caching Economics as the cost-side extension of performance budgeting. Source: whole-wiki concept review, 2026-06-19