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. Timeout tuning is a product decision, not a one-line config.

Abstract view of bid paths racing against a timeout
Timeout is a product decision: user wait versus demand that still arrives.

Prebid.js revolutionized publisher monetization by letting many demand partners bid in parallel before the ad server chooses a winner. But every adapter added to the wrapper is another network call, another script, another chance to miss the auction deadline. Set the timeout too high and users wait — Core Web Vitals suffer and bounce rates rise. Set it too low and good demand never responds.

This article explains how Prebid timeouts work on client and server, how to measure timeout rate per bidder, when to move partners to Prebid Server, and how to fail open without leaving money on the table.

What Prebid is doing during the timeout window

When a page loads (or an ad slot refreshes), Prebid:

  1. Builds ad units and consent signals
  2. Fires bid requests to each configured bidder adapter in parallel
  3. Collects responses until bidderTimeout expires
  4. Passes targeting keys to GPT, Ad Manager, or your ad server
  5. Ad server runs its auction including line items keyed on Prebid bids

The timeout clock starts when Prebid requests bids — not when the ad server renders. Anything that delays consent, CMP, or adapter init eats into the same budget.

Client-side Prebid: default traps

A single 2000ms client timeout hides adapter problems and delays first paint. Many sites should start lower in the browser — often 800–1200ms for display — then move long-tail demand to Prebid Server where the auction is not sitting on the user’s device.

Signs your client timeout is wrong:

  • Largest Contentful Paint (LCP) spikes when ads are enabled
  • One adapter accounts for >30% of timeouts but <5% of revenue
  • Users on mobile networks see blank ad slots while desktop fills fine
  • Ad server reports “no Prebid targeting” on a large share of impressions

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.

Sample review table (weekly)

  • Bidder A — 120ms median, 2% timeout, 18% win share → keep client
  • Bidder B — 890ms median, 34% timeout, 3% win share → move S2S or drop
  • Bidder C — 400ms median, 8% timeout, 11% win share → keep, watch IN geo

Client versus Prebid 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 via Prebid Server or direct OpenRTB
  • Revisit the split when a partner’s latency changes, not once a year

Prebid Server timeout can often be 200–400ms longer than client because the user is not waiting on every hop in the browser — but total ad delivery SLA still caps how high you can go.

Consent, CMP, and TCF delays

GDPR and TCF v2 flows add latency before Prebid can call bid adapters. If consent resolves at 400ms, a 1000ms bidder timeout effectively leaves 600ms for bidding. Account for CMP time in your planning — or use consent management modules that integrate with Prebid’s consent callbacks so auctions start only when allowed.

Fail open to the ad server

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.

Patterns that work:

  • House line item or programmatic guaranteed backfill when Prebid returns no bids in time
  • Single retry on refresh slots only — not on first paint above the fold
  • Alert when timeout rate crosses a threshold for any bidder two days in a row

Prebid and OpenRTB together

Prebid is not the only S2S path. Many publishers run Prebid for web wrapper demand and OpenRTB directly for app or high-QPS placements. Amli Media’s Prebid adapter (amliMedia) and OpenRTB endpoint hit the same auction — so you can shift traffic without splitting demand across duplicate seats. See Prebid integration and OpenRTB vs Prebid for gaming.

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.

FAQ

What is a good Prebid timeout for news sites?

Often 1000–1500ms client-side after CMP, with top bidders on client and long tail on Prebid Server. Measure LCP and revenue together.

Should gaming apps use Prebid in the WebView?

Only if the game already loads a WebView ad shell. Native games usually monetize via mediation and OpenRTB S2S instead.

← All posts · Prebid integration · What is Prebid?