Does header bidding slow down your site?

Any vendor who tells you their wrapper is free in performance terms is either not measuring or not telling you. The useful question is not whether header bidding costs something — it does — but which metrics it touches and how much of the cost is avoidable.

What it costs, metric by metric

• LCP (Largest Contentful Paint) — affected indirectly. Ad requests compete with your hero image and fonts for bandwidth and connections. If your LCP element is content rather than an ad, the fix is prioritisation, not removing the auction.
• CLS (Cumulative Layout Shift) — the big one, and almost entirely avoidable. Reserve space for every slot with explicit dimensions or aspect-ratio before anything loads. An ad that appears in unreserved space pushes content down and CLS is unforgiving about it.
• INP / TBT — affected by the wrapper bundle and every bidder adapter you add, which all parse and execute on the main thread. This is the cost that scales with bidder count.
• FCP — mostly unaffected if the auction is asynchronous and does not block rendering. If FCP moves when you install a wrapper, something is blocking that should not be.

What actually helps

1. 1 Reserve slot space. Non-negotiable, costs nothing, and eliminates most ad-driven CLS on its own.
2. 2 Lazy-load below-the-fold placements. Do not request an ad the user may never reach.
3. 3 Defer the whole auction until the first user interaction or scroll on pages where that is acceptable. The content path gets the network to itself during the critical window.
4. 4 Cut bidders that do not earn. Every adapter is bytes downloaded, parsed and executed for every user, including the ones who never see an ad.
5. 5 Use adaptive timeouts so slow devices are not punished with a wait they cannot afford.
6. 6 Preconnect to the domains that will definitely be used, so the TLS handshake is not on the critical path.
7. 7 Serve the tag from a CDN edge, compiled and minified, as one file rather than a chain of dependent script loads.

What deferral is worth

On ssm.codes, deferring the auction until the first scroll typically moves FCP by roughly 50–200 ms, LCP by 100–300 ms and TBT by 30–100 ms, depending on how heavy the page already is. Those are meaningful numbers if you are close to a Core Web Vitals threshold.

The trade-off is real and you should hear it plainly: users who bounce without scrolling never trigger an auction, so you lose those impressions. On article pages where nearly everyone scrolls, that is a good trade. On a single-screen landing page, it is not.

Related questions