Header bidding raises publisher revenue because it makes every demand partner bid on the same impression at the same time instead of taking turns. It costs page speed, engineering time, and supply-chain exposure. The publishers who get the most from it are not the ones with the most bidders; they are the ones who measure each bidder and tune the wrapper on a schedule.
This guide explains what header bidding changed, the real pros and cons in 2026, client-side versus server-side, and the six settings that decide whether your wrapper earns or leaks.
What is header bidding?
Header bidding is an auction that runs in the reader's browser (or on a server acting for it) before the ad server is called. A wrapper such as Prebid.js sends the impression to your supply-side platforms (SSPs) at once, collects their bids, and passes the best ones into Google Ad Manager as key-values. GAM then lets those bids compete with Ad Exchange, Open Bidding, and your direct campaigns through dynamic allocation, and the highest eligible price wins.
It replaced the waterfall, in which demand partners were called one after another in a fixed order and the first to clear a floor got the impression, whether or not someone further down would have paid more.
The pros: what header bidding actually adds
- True price discovery. Every partner sees the impression, so the winning price reflects what the market will pay rather than where a partner sat in the order. For most publishers the switch from waterfall to header bidding was the largest single revenue step of the last decade.
- Fewer passbacks and empty slots. Bids arrive before the ad server call, so the ad server can fill with the best of them rather than cascading through passbacks.
- Bid-level data. Because the auction runs where you can observe it, you see every bid, not just the winners: which SSP values which section, which device, which geo, and by how much. This is the data floor management and partner negotiation run on.
- Negotiating power with partners. When every SSP sees every impression, an underperforming one can be removed without losing coverage.
The cons: what it costs
- Latency. Each bidder is a network request from the reader's device. The wrapper waits up to your bidder timeout before calling GAM, so a slow wrapper delays every ad on the page and can hurt Largest Contentful Paint and Interaction to Next Paint on ad-heavy templates.
- Maintenance. Prebid ships new versions monthly. Adapters change, privacy modules change, and a configuration nobody has touched in a year is usually costing money somewhere.
- Complexity in GAM. Header bids are trafficked as price-priority line items in granular price buckets. The line-item setup, key-values, and creative sizes have to stay in step with the wrapper, or bids above your top bucket are silently capped.
- Supply-chain exposure. More partners means more entries in ads.txt and sellers.json and more resellers you have to vouch for.
- Cookie matching. Each SSP needs to recognise the user to bid well. On browsers that block third-party cookies, some partners bid less or not at all; user-ID modules help but add their own scripts.
To see what a specific page's wrapper is actually doing, which bidders responded, who timed out, and what won, the free Optimon Ad Inspector Chrome extension shows the live picture without touching your code.
Client-side vs server-side header bidding
Server-side header bidding moves the auction off the reader's device: the page makes one request to a server (Prebid Server, Amazon's Transparent Ad Marketplace, or Google Open Bidding inside GAM), which fans it out to demand partners and returns the result.
| Aspect | Client-side (Prebid.js) | Server-side |
|---|---|---|
| Page latency | Higher; grows with bidder count | Lower; one request |
| Cookie match rates | Best; SSP sees the browser | Lower; many partners bid less |
| Bid transparency | Full; every bid visible on page | Depends on the server operator's reporting |
| Fees | None beyond SSP fees | Operator fee or revenue share (Open Bidding, TAM) |
| Control | Yours, including timeouts and modules | Shared with the operator |
In practice most publishers run a hybrid: a lean client-side wrapper with the partners that bid best when they can see the browser, plus a server-side path for the rest and for Open Bidding demand. The mistake is treating the choice as ideological. It is a per-partner decision, and it should be revisited when match rates or fees change.
Six settings that decide whether your wrapper earns or leaks
- Bidder timeout. Too short and good bidders miss the auction; too long and every page waits for the slowest one. Look at each bidder's response-time distribution and timeout rate rather than picking a round number. A partner that times out on 20% of mobile auctions is either misconfigured or should be server-side.
- Bidder count per ad unit. Revenue per added bidder falls quickly after the first several. Rank partners by revenue per thousand auctions on each unit and device, and remove the ones that add latency without adding wins.
- Price granularity. Your line-item buckets cap what GAM can see. If your top bucket is $20 and a bidder returns $28, the bid competes as $20. Check the top of your bid distribution against the bucket ceiling twice a year.
- Floors. Prebid's Price Floors module and your GAM Unified Pricing Rules must agree on the same inventory. This guide covers how to reconcile them.
- Lazy loading and refresh. Below-the-fold units should be requested when they are about to be seen, not on page load, and in-view refresh should be declared to partners. Both raise viewability, which raises what partners bid.
- ads.txt and sellers.json hygiene. Every partner you call must be authorized, and every reseller line you carry must earn its place. Audit the file when you add or drop a partner, and at least quarterly regardless.
Where Optimon fits
Header bidding data and ad server data usually live in different tools, which is why bidder problems go unnoticed for weeks. Optimon reads your Prebid and Google Ad Manager data together, so each partner's timeouts, win rate, and response times sit next to the revenue it produced. When a bidder goes quiet on one device or geo, or a floor stops matching what the wrapper is bidding, the morning briefing says so with the numbers attached. The decisions about who to keep, throttle, or move server-side stay with your team.
FAQ
Does header bidding still increase revenue in 2026?
Yes, relative to a waterfall or to Ad Exchange alone, because more buyers compete on each impression. The size of the gain now depends on tuning: timeouts, bidder selection, floors, and viewability decide whether the added competition turns into revenue or into latency.
How many header bidding partners should a publisher run?
As many as earn their place on a given ad unit and device, which for most publishers is fewer than they currently run. Measure revenue per thousand auctions and timeout rate per bidder, and cut the ones that add delay without wins.
Is server-side header bidding better than client-side?
Neither is better in general. Server-side is faster and simpler for the page; client-side gives better cookie matching, full bid transparency, and more control. Most publishers run both, choosing per partner.
What is a header bidding wrapper?
The wrapper is the JavaScript (Prebid.js is the open-source standard) that runs the header auction: it calls the bidders, applies timeouts and floors, picks the winning bids, and passes them to the ad server as key-values on the ad request.
