Prebid.js é gratuito?

Sim. O Prebid.js é uma biblioteca open source, mantida pela comunidade Prebid.org, e seu uso é gratuito. Os custos envolvidos são os de implementação, otimização e, eventualmente, de um parceiro que opere o header bidding para você.

Header bidding deixa o site mais lento?

Pode deixar, se mal configurado. Como o leilão acontece no navegador antes de chamar o anúncio, um timeout alto ou muitos bidders adicionam latência. Com timeout equilibrado, curadoria de parceiros e lazy loading, dá para ganhar receita sem prejudicar os Core Web Vitals.

Qual a diferença entre Prebid e a cascata (waterfall)?

Na cascata, as demandas são consultadas em sequência, e a primeira que aceita leva a impressão, mesmo que outra pagasse mais. Com o Prebid (header bidding), todas competem em paralelo e a que paga mais ganha — o que tende a aumentar o eCPM.

Prebid.js explicado para publishers (header bidding)

Prebid.js é a biblioteca open source mais usada para fazer header bidding no navegador. Em vez de oferecer o seu inventário a uma demanda de cada vez (como na velha cascata), o Prebid coloca várias SSPs para dar lances ao mesmo tempo, antes de chamar o ad server. O resultado é mais competição por impressão — e, em geral, mais receita.

Por ser aberto e neutro (mantido pela comunidade Prebid.org), ele não favorece nenhuma exchange: você controla quem participa.

O problema que o Prebid resolve

No modelo antigo (waterfall), as demandas eram consultadas em sequência, por ordem de prioridade. A primeira que aceitasse levava a impressão — mesmo que uma demanda mais abaixo pagasse mais. Isso deixava dinheiro na mesa.

O header bidding inverte a lógica: todas as demandas competem em paralelo, e a que paga mais ganha. O Prebid.js é a ferramenta que orquestra essa competição no lado do cliente (no navegador do usuário).

Como o leilão do Prebid funciona

A página carrega e o Prebid dispara uma requisição de lances para vários bidders (SSPs/parceiros) ao mesmo tempo;
Cada bidder responde com um lance dentro de um timeout definido;
O Prebid escolhe o maior lance e o envia ao ad server (geralmente o Google Ad Manager) como um key-value;
O ad server compara esse lance com as outras demandas (AdX, vendas diretas) e decide o vencedor final;
O criativo vencedor é renderizado.

Tudo isso acontece em milissegundos, antes do anúncio aparecer.

Os parâmetros que mais importam

Timeout: quanto tempo o Prebid espera pelos lances. Curto demais perde demanda; longo demais atrasa a página. Valores típicos ficam na casa das centenas de milissegundos — é um ajuste de equilíbrio entre receita e performance.
Bidders (parceiros): quais SSPs participam. Mais bidders aumentam a competição, mas também o peso e a latência — escolha por desempenho, não por quantidade.
Floors (preços mínimos): o lance mínimo aceito, idealmente dinâmico.
User sync / consentimento: sincronização de identificadores, respeitando privacidade e consentimento (LGPD/GDPR).

Boas práticas

Equilibre timeout e performance: meça o impacto no carregamento e nos Core Web Vitals;
Curadoria de bidders: poucos parceiros bons rendem mais que muitos medianos;
Use lazy loading para casar header bidding com viewability e velocidade;
Acompanhe o win rate de cada bidder e remova os que só adicionam latência;
Monitore erros e timeouts: bidder que nunca responde a tempo é peso morto.

Prebid e o Google Ad Manager juntos

Na arquitetura mais comum, o Prebid roda no navegador e alimenta o Google Ad Manager com o melhor lance do header bidding. Lá dentro, esse lance disputa com a demanda do Google e com vendas diretas. É a combinação que dá ao publisher o melhor dos dois mundos: a competição aberta do Prebid e o controle do ad server.

Dominar o Prebid.js — timeout, bidders e floors — é um dos passos que mais movem o ponteiro da receita programática de um publisher. Vale o investimento de configurar e otimizar com método.