How to Optimize Header Bidding Timeouts for Revenue and Page Speed

Header bidding timeout is the difference between a 10% revenue lift and a 20% revenue lift, and the difference between passing Core Web Vitals and failing LCP. Set it right and you capture nearly every bid without slowing your page. Set it wrong and you either lose high-value bids or lose search rankings. This guide covers the revenue-to-speed trade-off, per-bidder configuration, adaptive timeouts, and a step-by-step testing framework to find the optimal value for your site.

What Is a Bidding Timeout and Why Does It Matter?

The bidding timeout is the maximum time Prebid.js waits for demand sources to return bids before closing the auction and sending the ad request to Google Ad Manager. Any bid arriving after the timeout is discarded.

This single configuration value controls a direct trade-off. Longer timeouts capture more bids (higher CPM potential) but delay page rendering (worse Core Web Vitals). Shorter timeouts speed up rendering but lose bids from slower demand sources. Every millisecond you add or remove shifts revenue and page speed in opposite directions.

The timeout decision sits at the center of header bidding performance. Price floors, adapter selection, and bid shading all matter. Timeout configuration determines whether those optimizations even get a chance to work.

How Does Timeout Length Affect Your Revenue?

Longer timeouts capture more bids, but with diminishing returns. Most demand sources respond fast. The last few percent of bids take disproportionately long to arrive.

Typical bid capture rates: 400ms captures ~82% of bids (fast SSPs like AppNexus/Xandr and PubMatic respond, slower partners miss), 800ms captures ~95% (nearly all standard SSPs), 1,200ms captures ~98% (the additional 3% carry lower average eCPM from slower-processing SSPs).

How Does Timeout Length Affect Page Speed?

Every millisecond of timeout directly delays your first ad render, which impacts Largest Contentful Paint (LCP) if ads are above the fold. A 1,000ms timeout doesn't add exactly 1,000ms to page load, but it prevents GAM's ad call from firing until the timeout expires or all bids return, whichever comes first.

On a page with a 2.2-second baseline LCP, adding an 800ms Prebid timeout pushes LCP to roughly 2.8 to 3.0 seconds. Google's "Good" LCP threshold is 2.5 seconds. That 800ms timeout just pushed you from passing to failing.

Mobile is worse. Slower processors mean Prebid's JavaScript takes longer to execute, and network latency on 4G adds 50 to 150ms per bid request. An 800ms timeout on desktop may behave like a 1,000ms timeout on mobile.

What Are the Default Timeout Values Across Platforms?

Prebid.js defaults to 1,000ms for bidderTimeout on initial page load. This is conservative by design and captures 95%+ of bids but often overshoots for publishers with fast demand partners.

Open Bidding's 300ms is achievable because it runs server-to-server with low-latency connections between Google's servers and participating SSPs. Client-side Prebid can't match that speed because bids travel through the user's browser and public internet, underscoring the client vs server header bidding debate.

How Do Per-Bidder Timeouts Help?

Per-bidder timeouts set different wait times for each demand source. Fast bidders get short windows. Slow bidders get longer ones. The auction closes when the last per-bidder timeout expires rather than holding everything for one global maximum.

AppNexus/Xandr consistently responds in 150 to 300ms. Give it 400ms. Magnite takes 400 to 700ms. Give it 800ms. A slow regional exchange might need 1,000ms. Your fast bidders no longer force you to wait for the slowest.

Check each bidder's average response time using Prebid analytics. Set per-bidder timeouts at their 90th percentile response time plus a 100ms buffer.

What Are Adaptive Timeouts?

Adaptive timeouts automatically adjust duration based on historical bid response data. Instead of a static 800ms, the system learns that your bidder mix returns 95% of bids within 620ms on desktop and 780ms on mobile, and sets accordingly.

Prebid.js doesn't natively support adaptive timeouts. Third-party wrappers (Assertive Yield, PubStack) and managed networks build the logic into their implementations. The approach outperforms static timeouts because it responds to real conditions: if a bidder slows in Q4, the timeout extends. If they speed up, it contracts.

How Do You Test Your Timeout and Find the Optimal Value?

Start at 800ms. Run for one week. Measure three metrics: bid capture rate, effective eCPM, and LCP. Then adjust.

1. Step 1: Set bidderTimeout: 800 in your Prebid config. Record your baseline bid rate, average winning CPM, and LCP from Google Search Console or Lighthouse.
2. Step 2: After one week, reduce to 600ms. Run another week. Compare: expect 3 to 8% fewer bids against 150 to 250ms faster LCP.
3. Step 3: Calculate revenue impact. If 600ms drops eCPM by $0.30 but gains 5% more pageviews from lower bounce rates, run both scenarios through the CPM calculator: (old pageviews × old eCPM) vs (new pageviews × new eCPM).
4. Step 4: Try 700ms as a middle ground if the 600ms eCPM drop exceeded the pageview gain. The optimal value is where the next 100ms of timeout adds less revenue than it costs in page speed.

Most publishers land between 600ms and 900ms. Below 600ms loses too many bids. Above 900ms adds latency with diminishing bid capture returns. If your audience is primarily mobile on slower connections, lean toward 700 to 800ms. Desktop-heavy sites can often run 600ms without meaningful bid loss.

Compare your optimized eCPM against CPM benchmarks by format and geo to confirm your timeout isn't capping your yield below market rates.

Common Timeout Mistakes and How to Avoid Them

Setting the default and never testing. Prebid's 1,000ms default is a safe starting point, not an optimized one. Most publishers can drop 200 to 400ms without meaningful bid loss. Run the test.

Using one timeout for all bidders. Response times vary by 500ms+ across demand sources. A global 1,000ms timeout wastes 600ms waiting for fast bidders that responded in 200ms. Per-bidder timeouts close the auction earlier.

Optimizing for bid rate instead of net revenue. Capturing 98% of bids at 1,200ms sounds better than 93% at 700ms. But if the extra 5% of bids average $1.50 CPM while the page speed cost loses you 3% of pageviews, net revenue drops. Always measure total revenue, not bid capture percentage.

Ignoring mobile. Mobile LCP budgets are tighter than desktop. If 70% of your traffic is mobile, your timeout needs to fit mobile's LCP ceiling, not desktop's.