Timeout Optimization for Header Bidding on Gaming Sites

A single number controls the tradeoff between ad revenue and player experience on your gaming site: the header bidding timeout. Set it too short, you lose bids. Set it too long, you lose players. For a gaming site doing 10 million monthly pageviews, getting this wrong in either direction can easily cost thousands of dollars a month, as the worked example at the end of this post shows.

What the Timeout Actually Does

When Prebid.js fires an auction, it sends bid requests to all configured demand partners simultaneously. Partners respond at different speeds: some in 80 ms, some in 900 ms. The timeout is the hard cutoff: once it fires, any bids not yet received are discarded and the auction runs with whatever bids are in hand.

Prebid.js ships with a default bidderTimeout of 3000 ms (Prebid.js setConfig reference), and many content-site setups settle somewhere around 1000–1500 ms. Those values are calibrated for pages where a second or more of ad latency is acceptable. On gaming sites, they are usually the wrong number.

Why Gaming Sites Are Timeout-Sensitive

Three factors make gaming sites more sensitive to timeout settings than typical publishers:

1. Game Assets Compete for Bandwidth

A gaming page often loads several megabytes of assets: game engines, sprites, audio, scripts. The auction's network requests and JavaScript run alongside those assets, competing for bandwidth and main-thread time, especially on slower devices and connections.

The bigger cost shows up when something the player waits for sits behind the auction. If a preroll or pre-game ad must render before the game starts, or the game's start is tied to the ad call, the auction's duration is added directly to the player's wait. The auction only runs all the way to the timeout when at least one bidder is slow, but on a busy gaming page that is common. In that worst case, every 100 ms of timeout is up to 100 ms more before the player can play.

How much of this reaches your players depends on how your page is built, so measure it: log your game's own "ready" event with the timeout at its current value and at a lower one, and compare the distributions.

2. Players Tolerate Less Delay Than Readers

A news reader arrives in "reading mode": patient, linear, prepared to wait a moment. A gaming player arrives in "play mode" and wants the game running immediately. In our experience, gaming visitors abandon slow loads faster than readers do.

This means the revenue cost of a slow timeout is amplified on gaming sites. You are not just losing the ad revenue from the bounced pageview; you are losing every later pageview in what would have been a multi-game session.

3. Mobile Gaming Connections Vary Widely

A large share of gaming traffic, often half or more, comes from mobile devices. Mobile connections range from fast LTE/5G in urban areas to congested 3G in developing markets. A 1000 ms timeout that works fine on a 50 Mbps connection becomes a chokepoint on a 2 Mbps connection where bid requests and game assets are both fighting for limited bandwidth.

This variance means a single global timeout is always a compromise. It is too long for fast connections (where most bids arrive in a few hundred milliseconds anyway) and too short for slow connections (where bids may need well over a second over a constrained link).

Optimal Timeout Ranges for Gaming Sites

Across the gaming sites we work with, these are the starting ranges we use to balance bid coverage and page performance. Treat them as a place to begin testing, not as final answers.

Client-Side Timeouts

• Aggressive: below 800 ms. You will lose a noticeable share of bids from slower partners, but page impact is minimal. Consider it only if your game load is extremely latency-sensitive (real-time multiplayer, competitive games), and test it carefully.
• Typical range: 800–1200 ms. This is where most gaming sites should land. Start near 800–1000 ms and move up only if your data supports it.
• Upper end: around 1200 ms. Only justify this if your bid arrival data shows a meaningful cluster of high-value bids arriving between 1000 and 1200 ms.

Server-Side Timeouts

Prebid Server auctions have their own timeout, set in Prebid.js's s2sConfig, separate from the client-side bidderTimeout. Prebid's documentation recommends setting it roughly 200–300 ms below your client-side timeout so server-side bids have time to travel back to the browser before the client auction closes (Prebid Server module docs).

If a server-side partner routinely cannot answer inside that window, the problem is on their end. Escalate to their technical team or move them out of your stack.

Hybrid Timeouts

If you run a hybrid setup (some bidders client-side, some server-side), the client-side bidderTimeout still decides when the whole auction closes, so keep it in the same 800–1200 ms range and set the s2sConfig timeout a few hundred milliseconds below it.

How to Test Timeout Changes

Do not change your timeout based on this article alone. Test it on your traffic.

Step 1: Establish Baselines

Before changing anything, measure:

• Bid coverage — What percentage of auctions receive at least one bid? What percentage receive bids from your top 3 partners?
• Bid arrival distribution — At what millisecond mark does each partner's bid typically arrive? Plot a histogram.
• Page load metrics — Largest Contentful Paint, Interaction to Next Paint, and your game-specific "ready" event.
• Session metrics: Bounce rate, session depth, session RPM.

Step 2: Run A/B Tests in 100 ms Increments

Split your traffic 50/50. Test your current timeout against a 100 ms reduction. Run the test for 7 days minimum to capture weekly traffic patterns. Measure all four baseline categories.

If the 100 ms reduction costs less than 2% bid coverage and improves session RPM (by increasing session depth), adopt it and test another 100 ms reduction.

If the reduction costs more than 5% bid coverage, you have found your floor. Step back up 100 ms and test in the other direction.

Step 3: Find the Cliff

On most gaming sites we have worked with, there is a specific timeout value where a small reduction causes a disproportionate drop in bid coverage. This is the cliff: the point where a meaningful cluster of bidders cannot respond in time.

The cliff is usually defined by your slowest high-value partner. If your top gaming-endemic SSP has a p95 response time of 850 ms, your cliff is around 850 ms. Dropping below that starts costing you a meaningful share of their bids.

The optimal timeout usually sits 100–150 ms above your cliff. This gives your slowest critical partner a buffer for network variance while keeping your total auction time as tight as possible.

Geo-Specific Timeouts

A global timeout is a compromise. Connections from Stockholm to an SSP endpoint in New York take longer than connections from Chicago. Setting a single timeout means players in slow regions wait longer than necessary and players in fast regions are already done bidding before the timeout fires.

Geo-specific timeouts address this. The values below are illustrative starting points to test, all within the typical 800–1200 ms range:

Implementation requires detecting the user's geo (typically from a geo-IP header or a lightweight API call) and setting the Prebid timeout dynamically before the auction fires.

The mechanism is straightforward: fast-region players get faster pages (more session depth), and slow-region players get better bid coverage (higher CPMs). Whether that adds up to a meaningful session RPM gain depends on your geographic mix, so A/B test it against your global setting before rolling it out.

Timeout Interaction with Other Settings

Timeouts do not exist in isolation. They interact with:

• Refresh intervals. If you refresh viewable ads every 30 seconds with a 1000 ms timeout, up to 3.3% of each refresh cycle can be spent waiting for bids; at 800 ms, up to 2.7%. The current creative usually stays on screen while the next auction runs, so this matters less than the initial-load timeout, but over a long session (for example, 15 minutes, which allows up to 30 refreshes per slot) it adds up.
• Bid caching. If you cache unused bids, a shorter timeout is less costly because a cached bid from a partner that answered earlier can still compete in the next auction. It does not set a floor, but it does soften the loss when a slow partner misses the cutoff.
• Number of client-side bidders. More client-side bidders increase the chance that at least one will be slow. If you have 8+ client-side partners, your timeout sensitivity is higher than with 3–4.

The Math: What Timeout Gets Wrong

Here is an illustrative example. The inputs are assumptions chosen to show the mechanics, not measured results. Take a gaming site doing 10 million monthly pageviews at a $7 page RPM (revenue per 1,000 pageviews, a global blended figure) with a 1200 ms timeout, and assume:

• Reducing to 900 ms lifts session depth by 8% through fewer early exits, adding 800,000 pageviews
• The 300 ms reduction loses enough late bids to cut page RPM by 3%, from $7.00 to $6.79

Then:

• Before: 10,000,000 pageviews × $7.00 / 1,000 = $70,000/month
• After: 10,800,000 pageviews × $6.79 / 1,000 = $73,332/month
• Net change: +$3,332/month

Flip the assumptions (a small session-depth gain and a large bid loss) and the same change loses money. That is why you test on your own traffic rather than copy someone else's number.

What To Do Now

Pull your bid arrival distribution data from your Prebid analytics. Identify your cliff. Set your timeout 100–150 ms above it. Implement geo-specific adjustments if you have significant non-US traffic. Test in 100 ms increments and measure session RPM, not just CPM.

Timeout tuning is one of the cheapest changes you can make, but it only pays when it is measured against session revenue rather than bid counts. For more on how the pieces of a Prebid setup fit together, read our guide to header bidding configuration for gaming sites, or see publisher results.