Server-Side vs Client-Side Header Bidding: A Gaming Publisher's Guide

Your header bidding setup is either costing you page speed or costing you revenue. Possibly both. The choice between client-side and server-side header bidding is one of the most consequential technical decisions a gaming publisher makes, and the standard advice gets it wrong for gaming sites.

How Client-Side Header Bidding Works

In a client-side implementation, the Prebid.js library runs in the player's browser. When a page loads, it sends bid requests directly from the browser to each demand partner's endpoint. Bids come back to the browser, the auction runs locally, and the winning bid is passed to your ad server.

Advantages for gaming publishers:

• Higher cookie match rates. Because bids originate from the browser, demand partners can read their own cookies (where the browser allows it) and recognize the user. Match rates are typically much higher than server-side.
• Better bid density. When more bidders can identify the user, more of them bid.
• Higher CPMs. When bidders know who the user is, they usually pay more for the same impression.

Disadvantages for gaming publishers:

• Page load penalty. Bid requests go out in parallel, so latency does not simply add up bidder by bidder: the auction lasts as long as the slowest bidder you wait for, capped by your timeout. But every client-side bidder adds its own adapter code, a network request and response parsing in the browser, and every extra bidder raises the odds that one slow partner holds the auction open until the timeout.
• Bandwidth competition. Bid requests and responses consume bandwidth that gaming sites need for game assets. On mobile connections, this competition is measurable.
• Device strain. Client-side auctions run JavaScript on the player's device. Lower-end mobile devices, common in gaming audiences, can experience frame drops and jank during auction execution.

How Server-Side Header Bidding Works

In a server-side implementation (often called S2S or server-to-server), the browser sends a single request to a server-side auction endpoint (like Prebid Server). That server then fans out bid requests to all demand partners, collects bids, runs the auction, and returns the winning bid to the browser.

Advantages for gaming publishers:

• Lighter page load. The browser makes one request to the auction server instead of one per bidder. How long the auction takes still depends on the server-side timeout and the partners it waits for, but the browser does far less work.
• Less device strain. Most auction logic runs on the server, not the player's phone, so the impact on game performance is much smaller.
• Cheaper to add partners. An additional server-side partner costs the browser very little. It still has to earn its place: more partners means diminishing returns. We vet every demand partner on revenue and page impact before adding it, and drop those that hurt user experience or page speed.

Disadvantages for gaming publishers:

• Lower cookie match rates. Server-side bid requests originate from a server, not the browser. Demand partners cannot directly read their cookies and depend on cookie syncing to recognize the user, so match rates are lower.
• Lower CPMs. Without user identification, more bids are based on context rather than audience, so CPMs for the same impression are usually lower than client-side.
• Reduced transparency. Debugging server-side auctions is harder. You have less visibility into individual bid responses and timeout behavior.

The Trade-off in Numbers: An Illustrative Example

The example below uses assumed inputs to show how the trade-off works. It is not measured data, and your own numbers will differ. Page RPM is revenue per 1,000 pageviews; session RPM is revenue per 1,000 sessions, which is page RPM × pageviews per session.

Pure client-side earns more per pageview but loses some session depth because players leave slower pages. Pure server-side keeps players longer but earns less per pageview. In this example the per-pageview gap (27%) is much larger than the per-session gap (about 13%), which is why session RPM is the number to watch.

But neither pure approach is optimal.

The Hybrid Approach: Why Gaming Sites Need Both

The right architecture for gaming sites is a hybrid: run your top-performing demand partners client-side for the CPM advantage, and move the rest server-side for the performance advantage.

Here is the decision framework:

Run client-side (a small group, often 3–5 partners):

• Partners with the highest win rates on your gaming inventory
• Partners with gaming-endemic demand (gaming ad networks, gaming-focused DSPs)
• Partners with fast response times (p95 under 300 ms)
• Partners where cookie match rates directly impact bid value (audience-focused DSPs)

Run server-side (remaining partners):

• General programmatic exchanges with moderate win rates
• Partners with slow response times (p95 over 500 ms)
• Regional or niche partners that add fill rate coverage
• Any partner where you want to test before committing client-side resources

Skip entirely:

• Partners with less than 1% win rate after 30 days of testing
• Partners whose p95 latency exceeds your timeout threshold
• Partners that consistently bid below your floor prices

Hybrid: Extending the Example

Continuing the same illustrative example, a hybrid keeps most of the client-side CPM advantage and most of the server-side session depth:

With these assumptions, hybrid session RPM is about 7% higher than pure client-side and about 23% higher than pure server-side. The exact figures depend on your partners, traffic and page weight; the mechanism is what carries over.

Implementation Details

Prebid.js Configuration

In a hybrid setup, your Prebid.js config specifies which bidders run client-side and which run via Prebid Server:

• Client-side bidders are registered as standard Prebid adapters. They execute in the browser on every auction.
• Server-side bidders are listed in s2sConfig (part of the Prebid Server adapter). They route through your own Prebid Server instance or a hosted Prebid Server provider.
• Each path has its own timeout. The client-side bidderTimeout decides when the whole auction closes; s2sConfig has a separate timeout for the Prebid Server auction. Prebid's documentation recommends setting the server-side timeout roughly 200–300 ms below the client-side one so server-side bids get back to the browser in time (Prebid Server module docs).

Timeout Strategy for Hybrid

Set your client-side timeout to 800–1200 ms and your s2sConfig timeout a few hundred milliseconds below it. If a server-side partner consistently misses the server-side timeout, it is adding no value: remove it or investigate.

The key: your timeout should be governed by your client-side partners, not your server-side ones. Server-side is the fast path; never let it become the bottleneck. For how to find your own values, see our timeout optimization guide.

Cookie Syncing

The cookie match rate gap between client-side and server-side can be partially closed with cookie syncing. For server-side bidders, Prebid.js calls your Prebid Server's cookie-sync endpoint (syncEndpoint in s2sConfig), which returns sync pixels for the partners that need them. Client-side bidders sync through Prebid.js's own userSync settings.

Best practices for gaming sites:

• Run cookie syncs after the game has loaded, not during initial page load. Prebid.js's userSync.syncDelay controls how long after the auction syncs fire; the aim is to avoid competing with game assets for network priority.
• Cap how many server-side partners sync per page with userSyncLimit in s2sConfig, to limit bandwidth impact.
• Use userSync.filterSettings to control which client-side bidders may sync, and with which method (image or iframe).

Good cookie syncing narrows the match rate gap, and with it part of the CPM gap. It does not close it completely.

When to Revisit Your Split

The hybrid split is not static. Review it quarterly based on:

• Win rate changes. A server-side partner whose win rate jumps above 10% may deserve a client-side promotion.
• Latency shifts. A client-side partner whose p95 latency creeps above 400 ms is degrading your page experience.
• New partners. Start new partners server-side, with one exception: a partner that is already a top earner (for example, one with strong win rates on comparable gaming inventory) can start client-side. Promote the others to client-side only after 30 days of performance data confirm they earn their slot.
• Privacy changes. Safari and Firefox already block or partition third-party cookies by default, and consent requirements keep evolving. Where browsers limit cookies, the client-side match rate advantage shrinks, tilting the balance further toward server-side.

What to Do Next

For gaming sites, the client-side vs server-side debate is a false binary. The answer is both: a carefully tuned hybrid where your highest-value partners run in the browser and the rest run on the server. The performance cost of getting this wrong is not abstract, because on gaming sites every lost pageview is a lost impression, and slow pages lose pageviews.

If your setup is all client-side or all server-side, start by measuring session RPM rather than CPM, then move partners one at a time. For the timeout side of the setup, read our guide to timeout optimization for header bidding, or see publisher results.