Header bidding is the mechanism that allows publishers to run a real-time auction across multiple demand sources before deciding which ad to serve. It replaced the older "waterfall" model and significantly increased publisher revenue across the industry. But header bidding comes in two architectures — client-side and server-side — and the difference matters for page performance, revenue, and maintainability.
Before header bidding: the waterfall
Before header bidding existed, publishers used a sequential waterfall. An ad request would first go to the premium network. If no bid came back above a floor price, it would fall through to the next network, then the next, until something filled the slot or a house ad ran. Each step added latency, and lower-priority networks never got a fair shot at winning impressions they might have valued highly.
The result was predictably bad for publishers: many high-value impressions were sold to whichever network happened to be first in the waterfall rather than whichever was willing to pay the most.
What is header bidding?
Header bidding asks all demand sources to bid simultaneously before the page renders. Instead of sequential fallthrough, every connected SSP gets to see the impression and submit a bid at the same time. The highest bid above the floor wins. Publishers gained two things: higher CPMs because of genuine competition, and a fairer auction that let niche demand sources compete on equal terms with the dominant networks.
Client-side header bidding
The original implementation runs entirely in the browser. A JavaScript library — most commonly Prebid.js — loads on the page, fires bid requests to each SSP in parallel, collects the responses, and then passes the winning bid to the ad server. All of this happens before the first ad renders.
Client-side header bidding improved publisher revenue substantially when it emerged. The problem is the browser cost. A typical Prebid.js setup with 8–12 SSP adapters adds 200–600ms of latency to every page load, plus meaningful JavaScript execution time on lower-end devices. Each SSP adapter is its own script with its own HTTP requests, cookie lookups, and compute overhead.
For publishers focused on page speed and Core Web Vitals, client-side header bidding creates a direct conflict between ad revenue and site performance.
Page speed and ad revenue compete in client-side setups
Server-side header bidding
Server-side header bidding moves the auction off the browser and onto a server. Instead of the user's browser firing requests to each SSP directly, a single lightweight request goes from the page to an auction server. That server communicates with all the SSPs simultaneously, runs the auction, and returns a single winning creative to the browser.
From the browser's perspective, an ad impression is a single HTTP request and response — regardless of how many SSPs participated in the auction behind the scenes.
Latency impact
The latency improvement is significant. Instead of 8–12 outbound requests from the browser, you get one. The auction server has persistent connections to SSP endpoints, runs the bidding logic in a low-latency environment, and can be placed in a region close to the publisher's primary audience. End-to-end auction latency for a server-side setup is typically under 150ms.
The trade-off: identity
Server-side header bidding has one genuine limitation: cookie-based identity matching. When bid requests go from a user's browser directly to an SSP, the SSP can read its own cookies and match the user to its advertiser audiences. Server-side requests don't carry browser cookies, which means the SSP gets less audience data and may bid lower — or not at all — for some impressions.
In practice, this effect is diminishing. Third-party cookies are being deprecated across major browsers anyway, and SSPs have been building cookie-independent identity solutions using cohort signals, first-party data, and contextual targeting. The CPM gap between client-side and server-side has narrowed considerably as the industry moves away from third-party cookie reliance.
Which architecture should you use?
For most publishers today, server-side header bidding is the better default. The page speed benefits are concrete and immediate. The identity trade-off is real but shrinking, and the operational overhead of maintaining a client-side Prebid.js setup — keeping adapters updated, debugging race conditions, managing JavaScript bundle size — is significant.
- Server-sideis best if page speed is a priority, your audience is on mobile, or you don't have an engineering team to maintain a Prebid.js setup.
- Client-side may still outperform for premium audiences where SSP cookie matching provides a meaningful CPM lift — typically finance, B2B, or high-income demographics.
- Hybrid setups are also possible: run server-side for the bulk of demand and add a small client-side layer for identity-sensitive demand sources.
Server-side header bidding is the direction the industry has been moving for several years, and the remaining arguments for client-side are becoming less compelling as identity solutions evolve and Core Web Vitals become a ranking factor. If you're starting a new programmatic setup, server-side is the cleaner, more sustainable architecture.