Reducing Header Bidding Latency: A Publisher Guide

Header bidding raises revenue by running a competitive auction before the primary ad server call, and it adds time to every page load. More demand partners means more bid requests, more JavaScript, and a longer wait before the page renders its content. Some of that latency is unavoidable. Much of it is not.

Audits of typical Prebid.js configurations regularly find timeouts set far higher than any winning bid ever needs, adapters bundled for bidders that rarely win, scripts loaded synchronously, and no lazy loading for below-fold placements. The latency cost of each issue is real and measurable. Which one matters most depends on the setup.

---

Table of Contents

1. Where Header Bidding Latency Comes From
2. How to Measure It
3. Timeout Configuration
4. Bidder Selection
5. Script Loading and Execution
6. Lazy Loading Ad Slots
7. Server-Side Auctions
8. Where to Start

---

Where Header Bidding Latency Comes From

Before the page can show an ad, several things have to happen in sequence, and each one takes time.

The browser starts by downloading Prebid.js and its bidder adapters. Adapters are the small scripts that connect Prebid to each individual demand partner. A typical setup with ten to fifteen bidders weighs between 150KB and 350KB. On a fast connection this takes tens of milliseconds; on a slower mobile connection, or on a first visit before anything is cached, it can take several hundred.

Once Prebid.js runs, each adapter goes through a startup routine: checking for user IDs, reading consent status, and opening a connection to its bidder's servers. When a publisher has a long list of adapters and they run their startup routines one after another rather than simultaneously, this step alone can add noticeable delay before the auction even begins.

The auction runs from the moment bid requests go out until either all responses arrive or the timeout window closes. The timeout is the maximum wait, not the average. If three of your eight bidders respond in 400ms and the other five take longer, you are waiting on whichever of those five hits the cutoff. Bidders that routinely miss the timeout window are adding page load time without adding revenue.

After the auction closes, Prebid.js sends the winning bids to your ad server, which picks the right ad, fetches the creative file, and displays it. Slow creative delivery, extra redirects, and sluggish content delivery networks can add another 200 to 500ms at this stage, and most publishers never connect that delay to header bidding.

How to Measure It

Three numbers matter most: total auction duration, how often each bidder misses the timeout, and how the auction is affecting page speed scores.

Prebid.js records timing data for every auction. Most analytics setups can capture how long each auction took and which bidders timed out. A bidder missing the deadline on more than 10 to 15 percent of auctions is worth investigating; above 20 percent, it is almost certainly costing more in page delay than it returns in revenue. If you do not have a reporting setup for this yet, BiddingStack's Header Bidding Inspector shows per-bidder timing directly in the browser without any instrumentation required.

For page speed, the relevant metrics are Largest Contentful Paint (LCP) and Interaction to Next Paint (INP). Both are available in Google Search Console and the Chrome User Experience Report, broken down by page type.

Timeout Configuration

The Prebid.js default bidder timeout is 3,000 milliseconds, and many publishers leave it there. Prebid's own documentation recommends 1,000ms or less; most demand partners need far less time than 3,000ms, and leaving the timeout that high keeps the page waiting long after the last useful bid has arrived.

Advertisers set their own internal deadlines shorter than whatever the publisher allows. Most will respond within 300 to 600ms if they plan to bid at all. A response that arrives at 2,800ms on a 3,000ms timeout is almost never a strong bid; the buyer used the full window because it had low confidence in the impression and was waiting for better signals that never came.

For most publishers, a timeout of 800 to 1,500ms captures nearly all winning bids. Cutting to 1,000ms removes the slow stragglers that rarely win, shortens the average auction, and gives the page more time to load its visible content before users see it. Fill rate may slip slightly at first, but effective CPM tends to hold or rise because a faster page keeps more visitors from leaving before they see an ad.

If you want a data-driven number rather than a rule of thumb, look at the response times of your actual winning bids over the past month. Whatever time covers 95 percent of them is your practical ceiling. There is little revenue in waiting beyond it.

Bidder Selection

Every adapter in your Prebid.js setup runs its startup code on every page load, whether it wins a bid or not. That code runs on the browser's main thread, which is the single processor the browser uses for everything: rendering the page, running scripts, and responding to user input. When many adapters are running simultaneously, they compete for that thread, slowing everything down.

The revenue contribution of individual adapters is often not what publishers expect. In most setups, three to five demand partners account for 80 percent or more of header bidding revenue. The rest add page weight and slow the browser without contributing meaningful incremental demand.

Pull three months of data: revenue by bidder, win rate by bidder, and how often each bidder misses the timeout. Sort by revenue. Any bidder that accounts for less than 1 to 2 percent of header bidding revenue and times out on more than 15 percent of auctions is worth removing. The page speed improvement it delivers is worth more than the demand it brings.

Each adapter you remove also reduces the total size of your Prebid.js file, which means less to download on every page load. Publishers on a managed solution like BiddingStack get this automatically when a bidder is deactivated.

When an SSP asks you to add a new adapter in exchange for demand access, apply the same logic in reverse. An adapter likely to win on 5 percent of auctions adds its startup overhead to every single page load. Make sure the expected revenue contribution justifies it.

Script Loading and Execution

Two changes to how Prebid.js loads produce most of the improvement here.

Loading it asynchronously lets the browser build the page and run the auction at the same time, rather than waiting for the script to finish before rendering anything. The auction still fires early; the difference is that the page content no longer waits behind it. Many setups from a few years ago still load Prebid.js in blocking mode without realising it.

Bundling all adapter code into a single Prebid.js file is the other change. Loading each adapter as a separate file creates an extra round trip to the server per adapter. On fast connections the difference is small; on mobile it adds up quickly. A single bundled file is one download regardless of how many bidders are active.

Lazy Loading Ad Slots

Running header bidding for placements the user may never see is a consistent source of avoidable auction time and main thread load.

Ad slots below the visible area of the page run their auctions immediately on load, competing with everything else the browser is trying to do, even though the visitor may not scroll to them for several seconds or at all. A visitor who reads two paragraphs and leaves has still triggered auctions for every ad slot on the page.

Lazy loading holds the auction for a slot until the visitor is about to scroll to it, typically starting the auction when the slot is 200 to 500 pixels away from coming into view. By then the initial page content has already loaded, so the auction runs against a browser that is no longer trying to do several things at once. The ad is still ready when the slot appears; it just did not compete with the page load to get there.

BiddingStack supports lazy loading per placement, deferring each slot's auction until it approaches the visible area. Enabling it keeps the initial page load focused on above-fold content.

Server-Side Auctions

Every fix described so far reduces how much adapter code runs in the browser. Server-side bidding eliminates it entirely.

With a server-side setup, the browser sends one request to BiddingStack's server. The server contacts all demand partners simultaneously, collects their responses, and sends one answer back. No adapter code runs on the page at all. A publisher with fifteen bidders goes from fifteen sets of startup scripts running in the browser to a single network request.

The latency benefit scales with the number of demand partners and is most visible on mobile. Adding or removing bidders from BiddingStack's Managed Prebid Server changes only the server-side configuration; the page itself is unaffected.

Where to Start

These changes stack. Cutting the timeout from 3,000ms to 1,000ms saves time, and saving more time on top of that by removing slow adapters and deferring below-fold auctions is what produces a real difference in measured Core Web Vitals.

Timeout reduction and async script loading are both configuration changes with no revenue risk, so they are the natural starting point. The adapter audit comes next, since the data to make it is already in your Prebid.js event logs. Lazy loading for below-fold placements is an implementation change but not a large one. The server-side migration is the most impactful structural change and the one that requires the most integration work, but it is the only approach that removes adapter JavaScript from the page entirely rather than reducing how much of it runs.

BiddingStack's Core Web Vitals tools give publishers per-page visibility into how header bidding is affecting LCP, CLS, and INP, with recommendations tied to specific placements and bidders rather than aggregate scores. Sign up to get started, or contact us if you want to talk through what is causing the most latency in your current setup.