Ashley

Up until now, publishers using header bidding have used browser or client-side header bidding. With browser-side header bidding, advertisers bid on the inventory inside of the header of the publisher’s web page. But publishers now have another option – server-side header bidding.

Why switch?

Server-side Header Bidding

The biggest challenge with browser-side header bidding, or client-side header bidding, is that it can slow down the speed of your site. Because advertisers call the header bidding container or wrapper directly, more partners adds additional JavaScript processes running on your web page, it can mean increased ad and page load latency.

Another issue is that each ad partner bidding on the inventory will have a different response speed, so your auction works only as fast as your slowest bidder.

The bottom line? With browser-side header bidding, publishers can be limited by the performance threshold they encounter with whatever solutions they are using. Being dependent upon the speed of their header bidding partners, they may adopt a strategy of using fewer partners to prevent latency. This can go against one of the main benefits of header bidding in the first place: increased demand competition.

What is server-side header bidding?

Server-side Header Bidding

Server-side header bidding allows the auction operations to occur outside of the publisher’s site browser. So rather than facilitate multiple calls to and from the web page, the auction is held after one call is sent to an external server.

How does server-side header bidding fix the latency problem problem?

Because server-side header bidding only requires one call, it dramatically reduces page latency. Unlike browser-side header bidding, server-side header bidding performance isn’t tied to so many multiple integration points.
If you’re interested in beta-testing our server-side header bidding solution, contact us here.

Scroll To Top Opt-Out