We keep a budget for latency the way other teams keep one for money. It is 200 milliseconds from the moment a slot becomes visible to the moment something is rendered in it, and everything in the path has a line item.
Where the budget goes
| Stage | Budget | Actual (p50) |
|---|---|---|
| Slot detection → request | 15ms | 9ms |
| Edge auction | 60ms | 38ms |
| Creative fetch | 90ms | 71ms |
| Render → first frame | 35ms | 28ms |
The interesting column is the first one. A budget that is never exceeded is not a budget, it is a description. Ours gets exceeded roughly once a quarter, usually by a new bidder, and the exceeding is the point — it is how we find out.
Why 200
Not because it is round. We ran a stepped experiment across our own inventory, holding everything else constant and adding artificial delay in 50ms increments. Completed views held flat to about 180ms and then fell off noticeably. We rounded up once and stopped.
delay completed views (indexed)
0ms 100.0
50ms 99.8
100ms 99.5
150ms 99.1
200ms 97.4
250ms 93.2 ← the cliff
300ms 88.6That cliff between 200 and 250 is the whole argument. Above it, every additional millisecond costs more than any bid it could buy.
Spending it well
Creative fetch is the largest line and the one we have most improved, mostly by refusing creatives that do not meet a size ceiling rather than by getting cleverer about delivering large ones. An advertiser who cannot fit inside the budget does not get a slower slot; they get a rejection and an explanation.
A latency budget only works if something is allowed to fail it.
