read whyRequest A Demo
Thank you! Your submission has been received!
Something went wrong while submitting the form
Header BiddingAd SpeedOptimization
June 22, 2016

A Blueprint for Minimizing Header Bidder Latency

The number one concern most people have with header bidding is latency. Many publishers fear that header bidding will slow down their page--damaging the user experience--or delay the creative--lowe...

Chris Cummings

The number one concern most people have with header bidding is latency. Many publishers fear that header bidding will slow down their page--damaging the user experience--or delay the creative--lowering the number of impressions served. These fears are legitimate. Header bidding causes both types of latency. In fact, these issues are so important, header bidding is facing existential questions of its long term relevancy as Google, OpenX, and others pursue server-side bidding solutions.

But in the near term, the overwhelming amount of CPM lift created by header bidding has tipped the scales toward using header bidding, despite the latency concerns. So what can be done to mitigate slow downs caused by header bidding? The short answer is to eliminate 3rd party javascript. The long answer is what we explore in this post.

How Header Bidding Currently Works

The current state of header bidding is a messy, tangled javascript disaster. Each bidder loads its own javascript, elects to drop pixels as it wishes, and handles the function of gathering bids in its own manner. Wrappers have provided some order to the chaos, but most wrappers are currently thin containers that load 3rd party javascript which do the heavy lifting of syncing cookies and gathering bids.

Let’s take a look at how the current header bidding flow typically works and the latency impact of each step:

Current Header Bidding Architecture

The latency caused by header bidding falls into three categories:

  • Bid latency - the impact of bid latency is that it slows down the time to fetch a bid from a bidder, and if auction timeouts are in place, bid latency increases the chances that a winning bidder is excluded from the auction. The primary drivers of bid latency are the time it takes to load the 3rd party javascript, the network requests needed to gather the bids, and the processing time it takes for a bidder to determine the price it will return.
  • Creative latency - the impact of creative latency is that it slows down the time to serve the creative. Creative delays cost money. They lower viewability scores, and decrease the impression transactions fulfilled by a publisher. All the drivers of bid latency also affect creative latency. Additionally, creative latency is affected by the javascript in the creative itself, where factors like tracking code can delay the rendering of the creative.
  • Page latency - the impact of this type of latency is that it degrades the user experience. Page latency slows down the initial content rendering and increases jank, which ultimately leads to fewer page views and less revenue. The culprits of page latency are the network congestion caused by all the 3rd party script requests and 3rd party bid requests, which consume bandwidth and push the max connection limit for many mobile browsers, and the memory and CPU required by the browser to download and execute all the scripts in the creative.

Bid, creative, and page latency are bad for the entire industry. They worsen the experience for users, lower revenue for publishers and SSPs, and reduce the amount of quality inventory available to bidders. Latency is a tax that we are all paying, and it is within our collective control to fix it.

A Faster, Simpler Model for Header Bidding

A big step forward for fixing the current latency problems caused by header bidding would be to eliminate 3rd party javascript. As you can see from the diagram above, all the bids are delayed by the requirement to load 3rd party javascript, increasing bid, creative, and page latency. Even when the 3rd party script is cached, many bidders require that that the script be re-requested to see if it has been modified, minimizing the impact of the caching.

A simpler model would have the wrapper gather the bids directly. It would look something like this:

Proposed Header Bidding Architecture

Bid, creative, and page latency are reduced in this scenario because there are no network requests needed before fetching the bids. The approach also leads to less javascript on the page, and comes with the added benefit that publishers can manage multiple partners without the increased vulnerability of 3rd party javascript introducing bugs or malware, which can happen.

In the near-term, wrappers could start bundling the 3rd party javascript into the wrapper javascript, eliminating the network request. But keeping the bundles up to date across the industry would over time become a synchronization nightmare.

The better approach is to allow the wrappers to directly access the APIs for each header bidder. Every header bidder has already gone to the trouble of creating an API to return bids to a javascript request. Now it’s time for wrappers to access those APIs directly, improving the speed and reliability of header bidding.

One function that the 3rd party javascript currently performs, which would have to be handled by the wrappers, is cookie syncing. This is a problem with many viable solutions. For example, the wrapper could fetch the user ID from a dedicated cookie sync API. Alternatively, the API for requesting bids could respond with the user ID. In either approach, the wrapper could then store the user ID in local storage or a cookie, and submit the ID on subsequent bid requests.

The functions that are currently performed by the 3rd party javascript could be performed by the wrappers and standardized across the header bidders. The result would be less latency across the industry, which leads to increased revenue for all the players involved.

Additional Optimizations

After eliminating 3rd party javascript, there are several additional optimizations that could reduce header bidder latency:

  • Bundled bid requests - the javascript for many header bidders currently makes a unique request for each ad unit on the page. If you have 5 ad units, that means 5 separate requests. Better architected header bidders bundle all these requests into one, and fetch bids for multiple ad units simultaneously. This should be a standard across all header bidders.
  • Un-used bid caching - header bidders currently make new bid requests every time an ad unit refreshes. In the scenario where there are 15 header bidders on the page, this means that on subsequent impressions, the 14 losing bids must be re-requested. In many cases, this is unnecessary. If un-used bids for the same user and ad unit combination could be cached for some duration, say 60 seconds, the number of new requests required on each ad refresh could be cut dramatically.
  • HTTP2 support - HTTP2 supports multiplexing, so only one connection is created for multiple requests to the same domain. HTTP2 would provide a faster, more secure method of communicating back and forth with the bidders.

A Coordinated Innovation Effort

Header bidding arose organically. The differing approaches taken to implementation developed by various header bidders spurred incredible innovation. At this stage in the game, however, the next level of innovation requires coordination.

For wrapper developers, this means laying the groundwork for direct API integrations with clean, universal adapters that bidders can build toward.

For bidders, this means working with wrapper developers on a method for consistent, API-based integrations.

For publishers, this means working with existing partners to convert from 3rd party javascript to API-based implementations, and requiring new partners to follow this approach.

Header Bidding’s Viability Hinges on Lowering Latency

The stakes for lowering the bid, creative, and page latency caused by header bidding could not be higher. Server-bidding is coming. And it’s most important value proposition is lower latency. If header bidding is going to survive, latency must come down.

Follow PubNation Blog

A/B Testing Advertising: A Playbook for Publishers

Six months ago we launched an A/B testing framework for our site,, that has allowed us to make ad ops decisions smarter, faster, and with measurable improvements to revenue. Our fir...

Publishers Fight Back: How The Top 50 Websites Combat Adblock

On our site,, adblock has become a major problem. We lose over 15% of our revenue each year because of adblockers--and the impact is growing larger every month. We are now embarking on