Why are Header Bidding timeouts still a thing?


here seems to be a significant amount of misinformation in the Header Bidding space that has proliferated around several “feared” buzzwords and was primarily spread by some self-serving exchanges early in the header bidding battle. There is a laundry list of these, however, this blog post is going to focus on a relic that’ still widely reflected upon – Header Bidding Timeouts

Async vs Sync

Back a few years ago, there was panic in the header bidding space. Header bidding was making lots of money, but was destroying page loads and ruining user experience. Every header bidding sales person at every exchange was ready with some technically unsound answer to “but what will your header bidding tech do to my page?” – some of them good solutions and some of them less so – but this initial period has defined how lots of publishers think about header bidding and user experience to this day.

Back then, these user experience concerns were perfectly reasonable. In the beginning header bidding was what’s called synchronous. To understand why this was an issue, we first need to have a little web development lesson – Synchronous versus Asynchronous.

Synchronous, or blocking, means that the page loads in a specific order, and each component in that order can theoretically block everything after it from loading. There’s a great metaphor here in the electrical engineering world – Parallel Circuits vs Series Circuits. In a Parallel circuit, like old Christmas lights, if one light goes out all the lights after it go out – similarly, for code that loads synchronously on the page, if one resource gets hung up it can block the rest of the page from loading.

Timeouts do need to exist, but they should play the role of “last resort” if we think a bidder may never respond, rather than some sort of optimization tool for the page itself.

Asynchronous, on the other hand, means that technically all the resources on the page load independently of one another. This corresponds to a Series Circuit, wherein a single light can go out and the rest of the string continues to light up. Asynchonrous also, however, means that the order that things load on the page is somewhat more unpredictable.

In the original world of header bidding, all header bidding was synchronous – this is because header bidding had to load before the GPT resource (the Google DFP Publisher Tag Library). This meant that if header bidding took a long time, it was blocking the entire page from loading!

Enter the timeout – the timeout was invented as a shield against this existential threat to the web page, this header bidding that might destroy user experience as we know it. The timeout meant that after a certain period, the synchronous JavaScript resource monopolizing the header of the page would cut off, fire GPT, and let the rest of the page load – regardless of whether the header bidders had responded. It was a relatively clean system, and while high risk, it worked.

Now that we know the genesis, we should also know that header bidding has evolved since it was first instantiated a few years ago. The majority of header bidding is now asynchronous, or it should be (if yours isn’t please email one of our sales people), which means that header bidding is no longer blocking the page from loading. Asynchronous header bidding has almost completely obviated the need for a timeout, because the entire page loads regardless of whether your ads have loaded – the worst thing that can possibly happen in asynchronous header bidding is that your ads load a little bit slowly and maybe your performance suffers a bit – maybe.

But we’re still discussing header bidding as a latency inducing technology that must be hamstrung by restrictive timeouts. Timeouts do need to exist, but they should play the role of “last resort” if we think a bidder may never respond, rather than some sort of optimization tool for the page itself.

In actuality any performance related issues in ad-serving tend to surface more from poor site configuration or improper wrapper setup than the actual header bidding technology. In fact one of the primary reasons our customers use our wrapper solution is because we invest a significant amount of time in performance and compatibility which is something that is difficult to achieve by simply trying to assemble your own open-source solution.