Engineering · 11 Aug 2026
Prebid timeouts that still let demand compete
Header bidding only works if slow partners do not block the page — and fast partners still get a bid in.
A single 2000ms client timeout hides adapter problems and delays first paint. Most sites should start lower in the browser, then move long-tail demand to Prebid Server where the auction is not sitting on the user’s device.
Timeout rate per bidder, not just overall fill
If one adapter times out constantly, dropping it from the client wrapper often raises the rest of the auction. Keep that partner on server-to-server if the demand is still worth the hop. A bidder that is slow on web can still be useful in-app or on S2S with a budget that matches the extra latency.
Log timeout share, median response time, and win rate on the same adapter. A partner that is slow but wins at a high CPM may stay. A partner that is slow and rarely wins should not occupy the client timeout budget.
Client versus server
Client-side Prebid competes in the browser. Every extra adapter is another script, another connection, another chance to miss the auction. Prebid Server moves that work off the page. You still set a timeout — it just no longer blocks rendering for the same duration.
A practical split: keep two or three high-value client bidders that consistently return under your page timeout. Send the rest S2S. Revisit the split when a partner’s latency changes, not once a year.
Fail open
Fail open to your ad server with a cached line item so users never wait on a hung bid. Document the timeout next to the adapter list so ops and engineering are not guessing. If you change the timeout, say so in the same ticket as the adapter change — the two are one system.
Amli Media’s Prebid adapter is built to return inside a tight window. If we cannot, we would rather miss the auction than hold the page.