Why Page latency Happens in Header Bidding and How to Tackle it

Header bidding was created to solve one of the biggest publisher challenges: improving the low yield associated with the inefficient waterfall method of serving ads.

In a report, Adzerk found that nearly 79% top publishers use header bidding. Moreover, in a study that we conducted on Alexa top 50 global publisher websites, we also found that 76% of them were using header bidding technology.

Clearly, header bidding is a hit with publishers. As of now, a larger share of publishers uses client-side header bidding. However, it has its downsides. Many publishers have reported high page latency on their websites, presumably caused by it.

But is it true? If yes, how can publishers reduce page latency associated with client-side header bidding? Let’s start with understanding the background.

What causes high page latency

Client-side header bidding requires publishers to add a piece of JS code into the header section of their website. Adding additional code to the website increases execution time. Several ad requests are also sent to solicit bids from demand partners, which also consumes browser resources, hence adding to page latency.

As a solution to these problems, header bidding wrappers were created. A wrapper allows multiple partners to reside together instead of adding multiple codes to the header that solves the page latency problem, to an extent at least.

However, in order to achieve a good revenue lift, it’s common for publishers to use more than one demand partner; which again has its downsides. Adding too many partners in the wrapper can cause high page latency.

Challenges publishers face

Badly configured header bidding setup creates both immediate and long-term challenges for publishers.

Immediate challenges:

Increases the overall page load time

Slows down ad rendering, which leads to loss of impressions

Leads to page timeouts, which reduces fill rates

Long-term challenges:

Hampers UX by keeping users waiting

Increases bounce rate as users tend to leave pages that load slow

Reduces overall revenue

Ways to tackle page latency

Watch the timeout

Publishers sometimes set the smallest timeouts to ensure a better user experience. But this means that they may lose out on bids from at least some demand partners. To avoid this, publishers should test and set optimal timeouts to maintain a balance between both.

Although there is no magic number here, typically, most publishers start with a timeout of around 500 milliseconds (0.5 seconds), though it may vary for different sites. Also, to maximize yield, all header bidders should be given the same amount of time to respond.

Check partner-level latency

Adding multiple demand partners increases bid competition and therefore revenue, though the downside of this should also be known.

To counter this, publishers must find out that no partner is causing a delay in the auctions. Tools, for example, the HeaderBid Expert Chrome extension, shows a partner-wise breakdown of bid response times. This information may help publishers retain high-performance demand partners and drop those who hold up the auction with slow bid response times.

Use asynchronous auctions

Synchronous auctions bring in bids from each partner or ad exchange one by one, which increases page latency. As a solution, it is recommended to switch to asynchronous auctions. The asynchronous setting allows all the bids to come in at the same time and solves the latency problem to some extent.

Moreover, asynchronous auctions help prevent page and content blocking, blocking other header bidders during the auction, or block the ad server from loading.

Balance off partners and page load time

Publishers often ask: how many header bidding partners should they have? Anecdotally, we can say that up to 10 header bidding partners. This is considered to be a good number. But instead of considering this as a rule of thumb, publishers should dive deep to examine how the number of partners affects their load time and revenue.

For instance, a publisher who adds 4 new bidders may see a 30% increase in CPM, but a 15% reduction in page load speed. Conversely, moving from 9 to 5 bidders may bring the CPM down by 25%, but increase page load speed by 18%. For many publishers, a marginal increase in latency is an acceptable tradeoff in exchange for higher CPMs.

From client-side to server-side to EBDA

The high page latency issue has prompted the evolution of header bidding. As the challenges associated with client-side technology became apparent, the industry moved to server-side header bidding.

Client-side header bidding, which consumes browser resources by executing the header bidding code on-page, was replaced by server-side header bidding, which moves the code execution to a dedicated server.

Shortly after server-side header bidding was launched, Google launched its own version of it called open bidding (previously called EBDA, short for Exchange Bidding Dynamic Allocation). Being an application of S2S, open bidding is considerably faster than the client-side header bidding technology that it replaces.

Open bidding is currently available via select Google AdX resellers. Another USP of open bidding is that since it is managed by Google, less legwork is required on the part of publishers in terms of setup, configuration, and payment consolidation.

Though unlike client-side header bidding, open bidding and similar S2S implementations are less transparent when it comes to publisher access to bid-level data.

Are there other downsides apart from latency?

Increased infrastructure costä¸Â€SSPs send out simultaneous ad calls to DSPs on ad impressions that often add up to these costs.

Compatibility with browsersä¸Â€client-side header bidding requires to first check its compatibility with different browsers used by users.

Duplication of bidsä¸Â€in working with multiple bidders, publishers may put up the same inventory for auction resulting in duplicate bids.

Final word

Making any decision around header bidding first requires some questions to be answered: Is the client-side better or server-side? What timeouts should you set? How many demand partners should you use?

It is advisable to test both the implementations on your own website. The final choice should be based on factors like inventory type, demand sources, page latency, average bid price, technical implications, and revenue generated.

Other than the measures mentioned above to tackle page latency, publishers can check if the content on their page is loading before the ads in order to maintain user experience. Also, it should be checked whether delayed partner response is causing ad call timeouts.