Prebid defaults that hold up.
The five configuration decisions every Prebid publisher makes — timeout, floors, bidder count, bid caching, refresh — with every widely repeated number graded by its actual evidence.
Prebid.js ships with defaults — a 3000ms bidderTimeout, useBidCache off, no floors — and an ecosystem of vendor blogs "optimizing" them. This page grades every widely cited number by its evidence: official spec, measured experiment, vendor claim, or folklore — and shows how to test the defaults on your own traffic.
Last validated July 13, 2026 · Maintained by Evgeny Popov
The most repeated Prebid advice — 1000–2000ms "sweet spots", 20–40% floor lifts, six bidders because browsers allow six sockets — traces to vendor blogs and an HTTP/1.1-era rationale. The only measured findings in the topic are Prebid’s own: revenue plateaus near five bidders, and bids keep landing past one second.
Fast read
- What this is
- An evidence audit of the five Prebid configuration decisions every publisher makes — timeout, price floors, bidder count, bid caching, refresh — with every widely repeated number graded: measured, spec, vendor-claimed, or folklore.
- The grading scale
- MEASURED: published experiment data. SPEC: stated in official Prebid documentation or platform policy. VENDOR: vendor-published, unaudited, with a commercial incentive to inflate. FOLKLORE: widely repeated, no traceable primary source.
- The headline finding
- Only two claims in the entire topic are measured, and both come from Prebid itself: revenue plateaus around five bidders, and real bid volume keeps arriving past 1000ms. Every floor-lift percentage in circulation (15–76%) is vendor-published; Prebid claims no number at all.
- What is not documented
- The industry’s actual config distribution. Prebid Insights publishes version, adapter, and module adoption across hundreds of thousands of sites — but no timeout, floor, or bidder-count distributions. Nobody publicly knows what "everyone else" runs.
- Best for
- Publisher ad-ops, programmatic, and revenue leads deciding whether to trust a vendor "optimization" claim — and how to test it on their own traffic instead, starting with the free skipRate holdout built into the Floors Module.
- Best next read
- Prebid & Header Bidding for the full standards decode; Prebid vs TAM vs Open Bidding for the three-auction decision; Prebid 11 Migration if you are still on 10.x.
The grading scale.
Four grades, applied to every number on this page. The scale is the method: most Prebid "best practice" content collapses because it never says which of these four buckets a claim came from.
- MEASURED
Published experiment data
An A/B test or latency distribution someone actually published. The rarest grade in this topic — two entries, both from Prebid’s own documentation.
- SPEC
Official docs or platform policy
Stated in Prebid documentation (a code default or explicit recommendation) or a platform policy document (Google Ad Manager, AdSense). Verifiable by link.
- VENDOR
Vendor-published, unaudited
A number published by a company selling the optimization it describes. Not necessarily wrong — but carrying a commercial incentive to inflate, and never independently audited.
- FOLKLORE
No traceable primary source
Advice repeated across blogs and forums that no primary document states. Two live specimens below: the six-socket bidder rule and the 60-second "optimal" refresh.
The graded defaults table.
Five settings, five verdicts. "Best evidence" names the strongest grade any claim about that setting reaches — details, links, and the vendor-claim audit per setting below.
| Setting | Ships as | Official guidance | Best evidence | Consensus range | When to deviate |
|---|---|---|---|---|---|
| Timeout | 3000ms bidderTimeout | ≤1000ms auction, ≤3000ms failsafe (FAQ); S2S at 50–75% of auction | Measured publisher latency data on the official timeouts page | ~1000ms anchor; vendor guidance clusters 1000–2000ms | Your latency distribution shows bid volume past the cutoff; heavy mobile mix (vendors claim +200–400ms); distant bidder endpoints |
| Price floors | No floors | Dynamic over static — "static floors are blunt tools" (Floors Module) | Vendor only — Prebid itself publishes no lift number | Dynamic floors with a skipRate holdout; realistic net lift far below headline claims | Thin demand or low-tier inventory where lost fill exceeds the CPM gain; always verify RPM, not CPM |
| Bidder count | Publisher-chosen (no default) | "Approximately 1–5" client-side; more server-side (FAQ) | Measured Prebid’s 5-vs-10 A/B: plateau near five | 5–10 client-side, overflow to Prebid Server | Each marginal bidder earns its slot with measured incremental revenue; per-geo bidder performance differs |
| Bid caching | useBidCache: false (since 2.0) | Enable for refresh, infinite scroll, SPAs (setConfig) | Spec only — revenue impact not publicly documented | None published | Enable when the same ad unit runs repeat auctions within bid TTL; otherwise leave off |
| Refresh | Not a Prebid setting (ad-server decision) | GAM: declared, 30s minimum time/event-based; AdSense: prohibited without user action | Spec platform policy; no primary-sourced lift figures | Viewability-gated, 30s+; "60s optimal" for web is folklore | Short sessions make refresh moot; undeclared or aggressive refresh invites DSP discounting of your whole inventory |
One distribution nobody can show you: what other publishers actually run. Prebid Insights (launched April 2025 with Burt Intelligence) publishes version, adapter, and module adoption across hundreds of thousands of sites — but no timeout, floor, or bidder-count distributions. The industry’s config distribution is not publicly documented.
Prebid timeout best practice: the 1000ms anchor.
Prebid.js ships with a 3000ms bidderTimeout, but Prebid’s own FAQ recommends 1000ms or less for the auction and 3000ms or less for the failsafe. Vendor guidance clusters at 1000–2000ms. Tune against your own bidder latency distribution — not a universal number — because publisher data shows real bid volume landing past one second.
| Claim | Grade | Source |
|---|---|---|
| Code default is 3000ms | Spec | setConfig reference |
| Recommended: auction timeout ≤1000ms, failsafe ≤3000ms | Spec | Prebid FAQ |
| Failsafe "should be much larger" than the auction timeout; s2sConfig.timeout at 50–75% of auction (default 75%) | Spec | Timeouts feature page |
| Real bid volume still arrives past 1000ms: at a 1500ms timeout, one publisher’s distribution shows 18,396 bids landing at 900–1000ms, 14,981 at 1000–1100ms, 12,823 at 1100–1200ms | Measured | Timeouts feature page (publisher data) |
| "Stay between 400–2000ms", sweet spot 1000–2000ms; "longer timeouts can increase ad impressions by 1–2%" (uncited) | Vendor | Setupad |
| "Many publishers set between 1000ms to 2000ms" — no data, no revenue figures cited | Vendor | AdPushup |
| Mobile timeouts should run 200–400ms above desktop | Vendor | Mile |
| Per-user dynamic timeouts by device and connection are officially supported | Spec | Timeout RTD module |
The honest consensus
Start near the official 1000ms anchor and tune upward only if your own latency distribution shows meaningful bid volume past it — Prebid’s published publisher data proves such volume can exist, and Prebid’s bidder experiment proves waiting too long costs revenue through abandonment. A hard "900–1100ms" band appears in no primary document; anyone selling you one is selling. Context that legitimately moves the number: bidder endpoint geography, device mix, and your client-vs-server split.
Prebid price floors: dynamic beats static — audit the lift claims.
Prebid ships with no price floors, and its Floors Module documentation warns against static ones: "Prebid does not recommend setting static floors. They are blunt tools and you’ll forget to update them." Prebid claims no revenue lift from floors — every uplift figure in circulation (15–76%) is vendor-published. The module’s built-in skipRate holdout lets you measure the lift yourself.
| Claim | Grade | Source |
|---|---|---|
| Static floors discouraged; module defaults: enforceJS true, skipRate 0, currency USD, floorMin as the hard minimum | Spec | Floors Module |
| Prebid makes no revenue-lift claim for floors anywhere in the module documentation — the absence is the finding | Spec | Floors Module |
| "Average revenue uplift of 22%" — a floor provider’s marketing line that appears inside the official Floors Module page as a provider listing; the same vendor’s blog headlines "15–40% more RPM" | Vendor | Floors Module (Mile listing) |
| Named case study: dynamic flooring on 80% of impressions at Arkadium → 34% session-RPM lift, 37.8% eCPM lift — vendor-measured, unaudited | Vendor | Aditude |
| 76% RPM lift (sports site during a March Madness demand spike — atypical) and 40% (casual gaming); practitioner-realistic range for tier-1 inventory: 5–15% net RPM after fill effects | Vendor / Folklore | MonetizationGuy |
| Floor-optimization strategies with zero quantified claims — the vendor that declines to publish a number | Vendor (contrast) | Setupad |
The RPM-vs-CPM trap
Floors move price and fill simultaneously, in opposite directions. A floor that lifts CPM while dropping fill can lose money — which is why every headline claim above quotes CPM or cherry-picked RPM windows, and why the only meaningful test metric is session RPM against a holdout. The module ships that holdout for free: skipRate (0–100) skips floor enforcement on a random share of auctions. No vendor pitch mentions it, because it lets you grade the pitch. Also account for the interaction with Google Ad Manager unified pricing rules — a common pattern treats the GAM floor as the safety net and Prebid dynamic floors as the competition driver.
How many bidders should Prebid run?
Prebid’s FAQ suggests roughly 1–5 client-side demand partners, and Prebid’s own A/B test found revenue plateaus around five bidders — more helped only with longer waits. Practitioner consensus runs 5–10 client-side with overflow to Prebid Server. The "6 bidders because browsers allow 6 sockets" rule is HTTP/1.1-era folklore.
| Claim | Grade | Source |
|---|---|---|
| "Approximately 1–5 demand partners" client-side; more via server-side | Spec | Prebid FAQ |
| 5-vs-10-bidder A/B experiment: more bidders produced more revenue only with longer waits; at 0–300ms of wait, "5 bids or 10 bids makes no difference"; revenue plateaus around five and drops when the page waits too long; async requests do not block page content | Measured | How many bidders (Prebid) |
| Dynamic selection of the 6–8 "best" SSPs client-side, 50+ server-side | Vendor | Snigel |
| Most publishers in server-assisted setups run 5–10 partners | Folklore (practitioner survey) | AdExchanger |
| "6 is optimal because browsers limit connections to 6 per host" | Folklore | Widely repeated; no primary source |
The six-socket rule, retired
The most durable number in header bidding folklore — six bidders, because HTTP/1.1 browsers open at most six connections per host — fails twice. Bidder endpoints sit on different hosts, so the per-host limit never binds across bidders; and HTTP/2 multiplexes many requests over one connection anyway. The measured guidance is better and simpler: Prebid’s own experiment shows the marginal bidder past five earns nothing unless you also extend the wait — and extending the wait has its own measured revenue cost. Bidder quality and per-geo performance beat bidder count.
Bid caching (useBidCache): off by default, on for refresh.
useBidCache defaults to false since Prebid.js 2.0: losing bids from one auction are not reused in later auctions on the same page. Official docs describe enabling it for refresh, infinite scroll, and single-page apps, where unrendered bids can win later auctions within their TTL. Revenue impact: not publicly documented.
| Claim | Grade | Source |
|---|---|---|
| Default false since Prebid.js 2.0 (was true by default through 1.x) | Spec | setConfig reference |
| Cache scope: same ad unit, same page view, same user, within TTL; bids expire at TTL minus the 1s ttlBuffer | Spec | setConfig · FAQ |
| When to enable: refresh setups, infinite scroll, SPAs — reuse of unrendered bids across auctions | Spec | setConfig reference |
| Revenue impact of enabling it: not publicly documented — no measured or even vendor-published lift figure found | — | Stated as absent; test it yourself (below) |
Do not conflate this with Prebid Cache — the server-side VAST cache for instream video and AMP. Different mechanism, different config, frequently mixed up in vendor guides. useBidCache is an in-page bid-reuse switch; Prebid Cache is infrastructure.
Ad refresh: the constraint is Google policy, not Prebid.
Prebid has no refresh default — refresh is an ad-server decision. Google Ad Manager sets the real constraint: declared refresh with a 30-second minimum for time-based and event-triggered triggers; AdSense prohibits auto-refresh outright. Consensus implementation gates refresh on viewability. The oft-cited "60 seconds is optimal" has no primary source for web.
| Claim | Grade | Source |
|---|---|---|
| GAM: refreshed inventory must be declared; 30s minimum for time-based and event-triggered refresh (web and apps; 60s recommended for apps); no minimum for user-action refresh | Spec (platform policy) | GAM: Declare refreshing ad inventory |
| AdSense: publishers may not refresh a page or an element of a page without the user requesting it | Spec (platform policy) | AdSense ad placement policies |
| Viewability-gated refresh (the MRC 50%/1s display standard as the gate condition) is the consensus implementation | Vendor (consensus practice, vendor-documented) | Relevant Digital · Clickio |
| "60 seconds is the optimal refresh interval" for web | Folklore | No primary Google document states it for web; the 60s figure in Google’s help is an app recommendation |
| Refresh revenue-lift figures | — | None primary-sourced; most refresh guides publish no number at all |
The buyer sees your refresh
Refresh is the one setting where over-tuning damages the asset: OpenRTB carries refresh signals, and DSPs discount inventory they identify as aggressively refreshed. Undeclared refresh risks worse than discounting under GAM policy. The two context variables that decide whether refresh yields anything: session length (short-session sites have nothing to refresh into) and how honestly the refreshed impressions are declared to buyers.
How to test any of this on your own traffic.
Every consensus range above is a starting point, not an answer — the honest version of "it depends" is a holdout. Six rules that separate a real config test from reading noise. Fair warning: most publisher-scale tests are noisier than the effects they chase, and knowing that is the edge.
- 01
Randomize at the page view
Split traffic randomly per page view (or session), not by day or week — demand seasonality is larger than most config effects. The 76% floor-lift figure in circulation rode a March Madness demand spike; day-based splits inherit exactly that confound.
- 02
Change one variable
Timeout, floors, bidder list, caching, refresh — one at a time. Prebid’s own bidder experiment shows why: bidder count only mattered at longer waits, so a combined change is uninterpretable.
- 03
Measure session RPM, not CPM
The floors trap generalizes: most config changes move price and fill in opposite directions. CPM up with fill down can be a net loss. Revenue per thousand sessions (or page views) is the only metric that nets the two out.
- 04
Use the built-in holdouts
Floors: the module’s skipRate parameter (0–100) skips floor enforcement for a random slice of auctions — a free, always-on control group. Timeouts: set bidderTimeout per page view from a random bucket. Bidder count: split the bidder array the same way.
- 05
Run an A/A test first
Split traffic with no change and watch the two arms diverge anyway. That divergence is your noise floor. If your daily RPM swings ±10%, a real 3% effect needs weeks of traffic to surface — most publisher config tests are underpowered and read noise as signal.
- 06
Re-test on a calendar
Bidder latency, demand mix, and seasonality all drift. A timeout tuned in Q4 is mistuned in January. Prebid’s Timeout RTD module exists precisely because one static number is wrong for some slice of users at all times.
What this buys you: the ability to grade vendor claims in the currency they avoid. When a floor vendor quotes 22%, your skipRate holdout produces your number on your traffic in two weeks — and if the test cannot detect the difference, that is a finding too: the effect is smaller than your noise, and the "optimization" is not worth its complexity.
Frequently asked questions.
What is the default Prebid timeout?
Prebid.js ships with a bidderTimeout of 3000ms in code (the setConfig reference), but the official FAQ recommends 1000ms or less for the internal auction timeout and 3000ms or less for the ad server failsafe. The timeouts feature page adds that the failsafe should be much larger than the auction timeout, and s2sConfig.timeout should run 50–75% of the auction timeout. Vendor guidance clusters at 1000–2000ms; the honest answer is to start near 1000ms and tune against your own bidder latency distribution.
Does Prebid recommend price floors?
Prebid recommends dynamic floors over static ones — the Floors Module documentation states "Prebid does not recommend setting static floors. They are blunt tools and you’ll forget to update them." Notably, Prebid makes no revenue-lift claim for floors at all. Every uplift figure in circulation (15% to 76%) is vendor-published and unaudited. The module ships a built-in A/B holdout, skipRate, that lets publishers measure the lift on their own traffic.
How many bidders should I run in Prebid?
Prebid’s FAQ suggests approximately 1–5 client-side demand partners, with more added server-side. Prebid’s own published A/B experiment (5 vs 10 bidders) found more bidders produced more revenue only with longer waits — at 0–300ms of wait, 5 or 10 bidders made no difference, and revenue plateaued around five. Practitioner consensus runs 5–10 client-side with overflow to Prebid Server. The "6 bidders because browsers allow 6 sockets" rule is HTTP/1.1-era folklore: bidder endpoints sit on different hosts, and HTTP/2 multiplexes anyway.
Should I enable useBidCache?
useBidCache has defaulted to false since Prebid.js 2.0 (it was true in 1.x): losing bids from one auction are not reused in later auctions on the same page. Official docs describe enabling it for refresh setups, infinite scroll, and single-page apps, where an unrendered bid can win a later auction for the same ad unit within its TTL. The revenue impact of enabling it is not publicly documented — no measured or even vendor-published figure exists. Note this is distinct from Prebid Cache, the server-side VAST cache for instream video.
What ad refresh interval is allowed and what actually works?
Refresh is an ad-server decision, not a Prebid default. Google Ad Manager requires refreshed inventory to be declared and sets a 30-second minimum for time-based and event-triggered refresh on web (60 seconds recommended for apps); AdSense prohibits refreshing without a user request. Consensus practice gates refresh on viewability (the MRC 50%/1s display standard as the trigger condition). The widely cited "60 seconds is optimal" for web appears in no primary Google document — treat it as folklore. No primary-sourced revenue-lift figure for refresh exists either.
Tuning a setup worth real money?
The defaults above are starting points; the evidence grades tell you which vendor claims deserve a holdout before they deserve a rollout. The operating work is the test harness: randomized splits, RPM-not-CPM metrics, honest power math, and a re-test calendar.