Prebid.js vs. Server-to-Server Header Bidding: Finding the Latency Sweet Spot

A peer-reviewed measurement study of roughly 393,400 client-side auctions across 5,362 sites put hard numbers on the header bidding latency debate: the median auction lasts 600 milliseconds, 87 percent of bids and 90 percent of total CPM arrive within one second, and the authors found no fundamental latency problem with client-side header bidding. About 10 percent of auctions still run past two seconds. That tail, plus the connection cost of one parallel request per bidder, supplies most of the force behind server-side migration pitches. The pitch is not wrong, but the decision it sells is narrower than it sounds, because it trades measured latency for a cost the pitch rarely itemizes: cookie access.

Publishers above one million monthly pageviews face three separate decisions, not one. Which bidders stay in the browser, which run behind a single server endpoint, and where to set the four nested deadlines that govern a hybrid auction. The measurement record, Prebid's timeout rules and the economics of first-price auctions all point to the same answer: a measured hybrid, deadlines tuned to the bid arrival curve, and the client-side versus server-side split decided per bidder rather than per site.

Two architectures, one auction

Prebid.js runs the auction in the user's browser. The wrapper fires one request per bidder in parallel, collects responses under a deadline, and passes the winning line items to the ad server as key-values. Each bidder sees page context directly, and each bidder can set and read its own third-party cookies on the user's device.

Server-side header bidding moves the fan-out step off the page. The browser opens one connection to a server endpoint, that server translates the request into OpenRTB 2.6, calls each demand partner from its own infrastructure, and returns a single payload to the wrapper. The page pays for one round trip instead of one per bidder. For a shorter plain-language treatment of the same trade-off, AdExchanger's client-side versus server-side comparison covers the architectural basics.

Both paths converge on the same decision point. The ad server receives merged key-values and runs its own selection, so from the ad server's perspective the only difference between a client-side bid and a server-side bid is the road it traveled. That convergence makes per-bidder migration safe to test: line items, targeting and floors stay in place while a bidder changes lanes.

Almost no large publisher runs one architecture or the other. The hybrid model keeps some bidders in the browser and sends the rest through the server, and Prebid configures that split through s2sConfig. Hybrid holds as the steady state for most large publishers because the two paths fail differently: the browser path spends connections and milliseconds, the server path spends user recognition.

The four clocks that govern a hybrid auction

A hybrid auction runs on four nested deadlines, and misconfiguring any one of them wastes demand silently.

The first clock is the overall failsafe timeout. Prebid's recommended best practice sets its starting point at 3,000 milliseconds or less: when it expires, the wrapper proceeds to the ad server with whatever bids it holds. The second clock is the internal auction timeout, the window the wrapper gives browser bidders to respond. Prebid's recommended starting point for that clock sits at 1,000 milliseconds or less. Prebid.js documents no default bidder timeout; the 3000 value in the reference examples is an example configuration, not a default, and treating it as one leaves two seconds of slot latency on the table for no measured gain.

The third clock belongs to Prebid Server. The s2sConfig timeout defaults to 75 percent of the Prebid.js timeout, per Prebid's timeout documentation, and Prebid's rule of thumb tightens it further: set the Prebid Server timeout 200 to 300 milliseconds below the Prebid.js bid timeout. A Prebid Server bid that misses the Prebid.js deadline never reaches the ad server at all, so the offset buys headroom for the extra network hop. Prebid's server-side overview spells out both the hybrid model and this offset rule.

The two rules agree more often than publishers expect. Seventy-five percent of a 1,000 millisecond Prebid.js timeout is 750, which lands inside the 700 to 800 band that the 200 to 300 millisecond offset produces. The default only turns hostile when the JS timeout moves and the server timeout fails to follow it, so any change on one side demands a check on the other.

The fourth clock runs inside the server. In OpenRTB, the tmax field defines how long Prebid Server has to process the request before the client stops waiting. Hosts cap tmax at a configured maximum, and the server subtracts safety buffers before it calls each bidder, so the window a server-side bidder actually sees is smaller than the tmax you send. A publisher who offsets the server clock perfectly can still lose bids at this layer, to a host cap the publisher never sees.

Verification belongs in the analytics, not in config comments. Prebid analytics adapters capture per-bidder response events, which turn the four clocks from doctrine into measurement: pull the response distribution for each bidder, compare it against the active deadlines, and you can see which bidders actually need the milliseconds you are giving away.

What the measurements actually show

The PAM 2020 study "Untangling Header Bidding Lore" measured roughly 393,400 client-side auctions across 5,362 sites. Publishers in the sample set deadlines anywhere from 500 to 3,000 milliseconds, a spread that says nobody in the field agrees on the right number. The auctions finished fast regardless: 600 milliseconds at the median, with about 10 percent exceeding two seconds. Bid arrival concentrated early, with 87 percent of bids and 90 percent of total CPM landing within one second. The authors concluded that client-side header bidding has no fundamental latency problem.

As a tuning input, those numbers reframe the deadline decision. A publisher who stretches the internal auction timeout from 1,000 to 3,000 milliseconds buys roughly the last 13 percent of bids, which carry about 10 percent of total CPM, and pays with up to two extra seconds of slot latency on every impression that waits for them. Sometimes that trade wins, on high-value pages with patient users and bidders whose responses cluster late. More often, viewability loss and layout shift quietly eat the gain before finance ever registers it.

The deadline belongs where marginal CPM from the tail stops paying for marginal latency, and the arrival curve puts that point near one second for most inventory. The study's deadline spread, 500 to 3,000 milliseconds, is a benchmark rather than a menu: if your own bids reach 87 percent inside 700 milliseconds, you have room to tighten, and if they do not, the milliseconds past one second at least buy something. That conclusion caps what the server side can win on latency grounds alone, because the browser auction it replaces is already fast at the median. The stronger arguments for the server are architectural: fewer connections, access to OpenRTB-only partners, and formats the browser handles badly.

The cookie cost of the server side

Latency is only half of the migration decision. The other half follows from where cookies live. Client-side bidders operate inside the user's browser, so they set and access third-party cookies directly. Server-side bidders receive a forwarded request and, in most cases, cannot. Prebid's documentation states the consequence plainly: moving a bidder server-side will often cause it to bid less often, or at lower CPMs, than the same bidder bid from the browser. Publishers run mixed client-side and server-side auctions precisely because of that asymmetry.

Cookie loss shows up in bid rate before it shows up in CPM. A bidder that stops recognizing users submits fewer bids, and every missing bid thins the auction. Thinning then compounds through the clearing mechanism. In a first-price auction with bid shading, buyers shade harder when they cannot read the competitive field, so the clearing price drops even on impressions that still receive bids. We break down expected-value ranking, first-price bid shading and reserve prices in our programmatic auction mechanics write-up, because timeout tuning and auction design turn out to be one problem wearing two hats.

The size of the cookie tax depends on the buyer. A context-driven buyer loses little when it loses cookies; a retargeting buyer loses almost everything it bids on. That is why the split belongs per bidder: sort buyers by how much of their bid depends on recognizing the user, keep the recognition-dependent ones in the browser, and send the context-dependent ones wherever the latency math says. Measure the tax directly when the call is close: run the bidder client-side on a holdout slice and server-side everywhere else, then compare bid rates, because the gap between the two rates states the cookie cost in the only currency that matters.

Where the server side earns its place

The case for the server is strongest where the browser is weakest. Mobile web and in-app inventory multiplies the cost of every client-side call, through slower radios, costlier connections and formats like interstitials and rewarded video that move heavy creative payloads. Our pages on mobile web and in-app formats cover that inventory, including the device-level reporting that makes a migration visible placement by placement. Format decides more than fashion here: video and in-app demand pay for the server hop, while cookie-dependent display buyers usually pay best from the browser.

Server-side video carries one extra mechanical cost. The creative travels through a cache before the ad server can act on the bid, and that hop belongs inside the timeout math like any other. Teams that forget it set a server timeout that works for display and starves video.

The second case is demand that cannot run client-side at all. Some partners expose no browser endpoint and accept traffic only as OpenRTB seats, which makes the server the only road to their budgets. The third case is roster size. Every client-side bidder adds a connection, a script and a participant in the timeout, and past some roster count the page pays more for the fan-out than a server would. The threshold depends on the bidder mix, which is why the playbook below measures instead of guessing.

The case against mirrors all three. On desktop web where third-party cookies still resolve, a recognition-dependent bidder moved server-side usually bids less often and pays less, and the latency saved on a 600 millisecond median auction is thin to begin with. Treat the server as a tool for formats and partners, not as a wholesale replacement for the browser auction.

How this runs in our stack

We are an ad network, an SSP and an agency in one company, and we work with thousands of publishers, each above one million monthly pageviews. We integrate OpenRTB 2.6 seats and Prebid for header and server-side demand. On the sell side, OnlyMedia runs one unified auction per impression: AdX demand through MCM, Prebid demand from both sides of the hybrid, OpenRTB seats for partners without browser endpoints, and managed floors on inventory that needs them.

Managed floors earn their keep in exactly this setup. When a bidder changes lanes and its win rate shifts, a floor held at the seat level keeps the clearing price sane while the migration is measured, instead of letting the buyer's shaded bids reprice the inventory in real time.

Payout terms matter to this work for a boring operational reason. Hybrid tuning shifts revenue between demand sources week to week, and a publisher judging a migration needs a baseline that holds still. We pay publishers Net 30, CPM based. No chasing, no sliding terms. The same conditions run across our curated programmatic demand network.

The tuning playbook

This sequence takes a stack from either pure configuration to a measured hybrid. Budget an afternoon of analytics work per iteration and hold a control group throughout.

1. Set the outer clocks first. Hold the overall failsafe timeout at 3,000 milliseconds or less and the internal auction timeout at 1,000 milliseconds or less, Prebid's recommended starting points, then tune against your own bid arrival data instead of anyone's example config.

2. Offset the server clock. Set the Prebid Server timeout 200 to 300 milliseconds below the Prebid.js timeout. Remember that s2sConfig defaults to 75 percent of the JS timeout: that equals 750 at a 1,000 millisecond JS timeout, inside the 700 to 800 offset band, and correct only until the JS timeout moves again.

3. Profile every bidder before moving it. Pull latency distributions, bid rate and CPM per bidder from Prebid analytics. A bidder whose median response lands around 600 milliseconds is not a latency problem; a bidder whose slow tail blows past the deadline is.

4. Migrate one bidder at a time and read bid rate first. Cookie loss appears as fewer bids before it appears as lower CPM. If bid rate drops materially after a move, that bidder belongs in the browser regardless of what the latency profile says.

5. Sort demand by recognition dependence, then by format. Retargeting-heavy display buyers stay client-side; video, in-app and interstitial demand justify the server hop; context-driven buyers follow the latency math.

6. Audit for double inclusion. A partner reachable both as a browser adapter and as an OpenRTB seat can bid on both sides of one auction, which inflates request counts and corrupts every per-bidder measurement downstream.

7. Test against a holdout. Split by geography or by template, run the new configuration against the old, and judge results on revenue per thousand sessions rather than CPM alone, because timeout changes move win rates and fill in ways a CPM readout hides.

Two failure modes account for most broken hybrid setups. Teams set the Prebid Server timeout above the Prebid.js timeout, then wonder why server bids never surface, when the offset rule exists precisely because late server bids never reach the ad server. Teams also migrate recognition-dependent buyers wholesale, watch bid rate fall, and blame the market instead of the architecture. Both are configuration errors, not demand problems, and both show up in the analytics before they show up in the invoice.

Where the sweet spot lands

The measured record supports a specific posture. Client-side header bidding has no fundamental latency problem: the median auction finishes in 600 milliseconds and 90 percent of total CPM arrives within one second. The server side earns its place for mobile and in-app formats, for OpenRTB-only partners, and for rosters whose connection cost outweighs their recognition value. Deadlines should follow the arrival curve, with the internal auction timeout at or under 1,000 milliseconds, the failsafe at or under 3,000, and the server clock offset 200 to 300 milliseconds below the browser clock.

That configuration is not a compromise between two architectures. It is what the data supports: hold the auction open long enough to capture the 87 percent of bids that arrive within one second, use the server to reach demand the browser cannot reach cheaply, and let per-bidder measurement decide the rest. Revisit the split on a fixed schedule, because formats, cookie coverage and arrival curves all drift, and a hybrid tuned in January is a hypothesis by June.