Header Bidding Timeouts: How to Find the Number That Actually Pays

Why timeouts still matter

The header bidding timeout is the number of milliseconds your wrapper waits for bids before handing the auction to the ad server. It is one setting, but it trades off three things at once: how many bids arrive, how quickly ads render, and how many impressions happen at all. Set it too short and slower partners with strong bids never compete. Set it too long and users scroll past slots before they fill, viewability drops, and some pages close before any ad renders.

Many sites set the timeout once, during implementation, and never touch it again. Meanwhile bidders change, pages get heavier, traffic shifts to mobile, and server-side bidding changes the latency picture. A timeout that was right two years ago is probably wrong today.

How the timeout works in Prebid.js

In Prebid.js the global value is set with bidderTimeout in setConfig, and it can also be passed per auction in requestBids. A few related settings matter:

• Secondary bidders. The auctionOptions setting lets you list bidders the auction will not wait for before completing. Their bids still count if they arrive in time, but a slow secondary partner cannot hold up the auction.
• Requests per origin. Prebid defaults to a maximum of 4 concurrent requests per origin, a guard against browser connection limits that can queue requests and add latency on busy pages.
• Late bids. Browser timers are not perfectly precise, so bids that land just after the threshold may still be included. Do not read too much into single-digit millisecond differences.

The Prebid setConfig reference documents these options in detail.

A data-first method

Step 1: collect bid latency by partner

Use a Prebid analytics adapter or your own logging to capture, for each bidder, the response time distribution and whether each bid arrived before or after the timeout. Averages hide the problem; look at the median, the 90th percentile and the share of bids that timed out.

Step 2: split by the dimensions that matter

Latency varies by device, connection, geography and page type. Mobile users on cellular connections see slower responses than desktop users on office networks. International traffic may be far from a bidder's servers. Article pages with heavy media behave differently from lightweight home pages. Break the data out at least by device and top countries.

Step 3: look at the value of late bids

For each partner, compare the CPM of bids that arrived in time with those that timed out. If late bids from a partner are rarely competitive, lengthening the timeout for them buys little. If a partner's late bids often would have won, you are losing money by cutting them off, and you should investigate why they are slow before you simply wait longer.

Step 4: test, don't guess

Run a controlled test with users randomly assigned to two or three timeout values, for example your current setting and one shorter and one longer. Run it long enough to cover weekday and weekend patterns, and compare:

• Revenue per page view and per session, not just CPM.
• Ad impressions per page view, which captures slots lost to slow fills.
• Viewability and time to first ad render.
• Core Web Vitals on the pages tested.

The winner is the setting with the highest revenue per session that does not harm user experience metrics. It is frequently not the one with the highest CPM.

Step 5: set values per segment

One global number is a compromise. Where your stack allows it, use different timeouts for desktop and mobile, and consider shorter timeouts for refresh or infinite-scroll auctions, where the page is already loaded and users are engaged, than for the first auction on page load.

Fix latency at the source

Changing the timeout treats the symptom. Several changes reduce latency for everyone:

• Load the wrapper early. Start the auction as early in the page lifecycle as possible, and avoid waiting on unrelated scripts.
• Trim the bidder list. Each extra adapter adds requests, parsing and competition for the network. Partners that rarely win and add latency are costing you more than they bring in.
• Move some partners server-side. Prebid Server consolidates many bidder calls into one request from the browser. It can reduce client-side load, though with trade-offs in cookie match rates you should measure.
• Watch consent and identity modules. Waiting for a consent platform or identity lookup before the auction adds time. Configure sensible timeouts for those steps as well.
• Keep Prebid current. Performance improvements and adapter fixes arrive regularly. Running a very old build means missing them.

Common mistakes

• Raising the timeout to rescue one partner. Every user waits for the slowest bidder you choose to wait for. Mark a slow but valuable partner as secondary or ask it to fix its latency.
• Testing on the office network. Your team's fast desktop connections are not your audience. Use field data from real users.
• Forgetting the ad server. The timeout covers bidding only. Ad server response and creative rendering add more time before an ad is visible, so the total is always longer than the setting suggests.

Vertical notes

News and finance sites often see their heaviest traffic in short bursts around breaking events and market moves, largely on mobile. Those are the moments when a too-long timeout costs the most impressions, so test mobile settings with burst traffic in mind. Travel sites, with high-value but lower-frequency sessions, can often afford to wait slightly longer on key search and listing pages, where each impression is worth more, provided the page stays responsive.

The right timeout is not a number you copy from another site. It is a number your own data tells you, and it changes as your traffic does.

Put a recurring review on the calendar, quarterly at minimum and after any major bidder or template change. If a partner manages your wrapper, ask to see the latency distributions behind the setting they chose.