Header bidding runs an auction among several demand sources simultaneously before the ad server decides, which raises competition. It adds scripts and latency, so the question is whether the revenue gain exceeds what the delay costs.

What it replaced

The older arrangement offered inventory to demand sources in a fixed order. The first was given the chance to buy at a price, and only if it declined did the next get a look.

That order was set on estimates of what each source usually paid. Which means a source further down the sequence, willing to pay more for this particular impression, never got asked.

The result was systematically leaving money on the table, invisibly, because you cannot see a bid that was never solicited.

What it does instead

Asks several demand sources at once, before the ad server makes its decision, and passes their bids in so the highest can compete.

Every participating source sees every impression and can bid its true value. Competition rises, and rates rise with it.

The name comes from the code originally sitting in the page header, running before the rest of the page continued.

That placement is also where the cost comes from.

The cost, stated plainly

Every bidder is a network request. Several bidders are several requests, made in parallel, and the auction cannot conclude until they respond or time out.

Which means the page waits. On a fast connection that wait is small. On a mobile connection at the edge of coverage it is not, and it delays what the visitor came for.

Three consequences follow.

Perceived speed drops, which affects whether people stay.

Core performance measurements degrade, which matters beyond advertising.

Later ads may not render at all, if a visitor leaves before the auction resolves, which quietly reduces the impressions you thought you were selling.

So the honest framing is a trade rather than an upgrade: more competition per impression, fewer impressions served and a slower page.

The settings that decide the trade

Timeout

How long the auction waits for bids. Short timeouts protect the page and exclude slower bidders, sometimes the ones paying most. Long timeouts capture more bids and hurt the experience.

This is the single most consequential number and it is worth testing rather than accepting a default.

Number of bidders

Each additional one adds latency and diminishing competitive benefit. Beyond a modest number, most add cost without adding a winning bid.

Reviewing which bidders actually win, and removing those that never do, is the highest-return maintenance task here.

Asynchronous loading

Whether the auction blocks the page or runs alongside it. Blocking is simpler and worse for the visitor.

Lazy initialisation

Running the auction for lower slots only when they approach the viewport, rather than all at once on load. Reduces upfront cost substantially.

Whether it suits a small publisher

Honestly, sometimes not.

It suits a site with enough traffic that a rate improvement is worth real money, a technical route to implement and maintain it, and content people stay on long enough for the extra latency not to cost more than it earns.

It suits less well a small site where the absolute revenue gain is modest, where nobody can maintain it, and where the audience arrives on phones with poor connections.

A managed implementation through a partner is the middle path, and it trades some of the gain for not having to run it yourself.

Measuring whether it worked

The test that settles it, and it is rarely run.

Compare a period before and after on session RPM rather than CPM, since CPM will rise regardless and says nothing about the net effect.

Watch pages per session and time on page over the same window, since a slower site loses depth, and depth is where session RPM comes from.

And watch the proportion of slots that actually render, since impressions lost to visitors leaving mid-auction are the cost that does not appear in any rate.

If session RPM improved and depth held, it worked. If CPM improved and session RPM did not, it did not, whatever the dashboard says.

The underlying tension is the one set out in core web vitals vs ad revenue: the actual tradeoff.

Frequently asked questions

What did header bidding replace?

A sequential arrangement offering inventory to demand sources in a fixed order, so a source further down willing to pay more was never asked.

What does it do?

Asks several demand sources simultaneously before the ad server decides, so every participant can bid its true value and competition rises.

What does it cost?

Latency. Every bidder is a network request and the auction must resolve before the page continues, which slows the page and can lose later impressions entirely.

Which setting matters most?

The timeout. Short protects the page and excludes slower bidders who sometimes pay most; long captures more bids and hurts the experience. Test rather than accept a default.

How many bidders should I run?

Fewer than most setups have. Each adds latency with diminishing benefit, so review which ones actually win and remove those that never do.

How do I know whether it worked?

Compare session RPM before and after, not CPM, and watch pages per session. CPM will rise regardless and says nothing about the net effect.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Running eight bidders and unsure which earn their place?

We look at which ones actually win, which usually shortens the list and speeds up the page.

Start a Conversation