Back to roadmap
Module 2 · Scale, Latency, CapacityDay 01825 min

Performance Budgets

Every component on a path gets a slice of the latency budget.

← PreviousNext →
Day 018

Performance Budgets

TLS
edge
CDN
edge
App
service
DB
datastore
Render
client
Signal path
Latency budget per hop
TLS
edge
flow
CDN
edge
CDN
edge
flow
App
service
App
service
flow
DB
datastore
Memory hook

Performance Budgets: every component on a path gets a slice of the latency budget

Mental model

make the invisible limits visible

Design lens

Caching trades freshness for budget.

Recall anchors
SetEnforceRenegotiate

Why it matters

A performance budget is a per-component slice of the user-facing target. Total p95 page load 1s? TLS 50ms, edge 30ms, app 200ms, DB 50ms, render 200ms, etc. Add a row when you add a hop. Budgets stop death-by-a-thousand-features.

Deep dive

Decompose top-down. Pick the user-visible target, list every hop, allocate ms based on prior data.

Enforce. Synthetic tests in CI, p95 alerts in production. A regression in one row blocks deploys.

Renegotiate, don't ignore. New feature wants 50ms? Either someone gives up budget, or the page-level target rises.

Demo / scenario

Page p95 target 1s. Currently at 1.4s.

  1. Profile: CDN 80ms (good), TLS 60ms (good), app 600ms (over), DB 150ms (over), JS render 500ms (over).
  2. App over — add caching layer, save 300ms.
  3. DB over — add composite index, save 80ms.
  4. JS over — code-split, save 200ms.
  5. New total ≈ 0.91s.

Tradeoffs

  • Caching trades freshness for budget.
  • Code-splitting adds chunk requests; mostly worth it.
  • Index adds write cost; usually small for read-heavy paths.

Diagram

TLS
60 ms
CDN
80 ms
App
300 ms
DB
70 ms
Render
300 ms
Latency budget per hop.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →