Performance · 5 min

A latency budget you can actually use

June 18, 2026

“Fast” is not an engineering target. A budget turns it into a set of smaller promises that can be measured independently.

Start at the boundary

Choose the experience that matters: first useful paint, a completed search, or an API response. Set a percentile and a time window. A target such as “95% of searches finish within 600 ms over ten minutes” is concrete enough to test and broad enough to survive normal variance.

Allocate, then reserve

Divide the target among connection setup, application work, storage, and the return path. Keep a margin for queueing and retries. If every component consumes its theoretical maximum, the whole request has already failed its budget.

600 ms total · 90 ms network + TLS · 260 ms application · 110 ms storage · 60 ms response · 80 ms reserve

Measure the seams

End-to-end timing tells you that users are waiting. Boundary timing tells you where. Record the handoff between the edge and the app, the app and its store, and the last byte back to the client.

A budget is useful when it changes a decision: rejecting an extra dependency, caching one expensive lookup, or setting a timeout before an upstream can spend the entire request.