Você deve usar preconnect para redes de anúncios? Depende do seu LCP

A resposta curta: depende do seu LCP

Sempre que audito um site, analiso as estratégias de resource hints. Às vezes, os clientes usam preconnect para redes de anúncios, na esperança de acelerar os anúncios e aumentar a receita. Se isso ajuda ou prejudica depende inteiramente de uma coisa: a imagem do seu Largest Contentful Paint já está devidamente otimizada?

Última revisão por Arjen Karel em março de 2026

Se a imagem do seu LCP estiver no HTML (não injetada por JavaScript), não tiver lazy load e tiver fetchpriority="high", o navegador a priorizará, independentemente de qualquer outro preconnect que você fizer. Nesse caso, usar preconnect para a origem principal da sua rede de anúncios é seguro e pode, de fato, gerar lucro ao exibir anúncios alguns milissegundos mais rápido.

Mas se o seu LCP não estiver otimizado, cada preconnect que você adicionar competirá por largura de banda e ciclos de CPU no pior momento possível. Já vi isso dar errado em sites com 5.000 a 15 milhões de visualizações de página diárias.

O que um preconnect realmente faz

Um hint de preconnect diz ao navegador para abrir uma conexão (DNS + TCP + TLS) com um servidor externo antes que ele realmente precise de um arquivo de lá. Quando o arquivo é finalmente solicitado, a conexão já está aquecida e o download começa imediatamente. De acordo com o web.dev, isso pode economizar de 100 a 500 ms para origens críticas.

O problema: o Chrome fecha qualquer preconnect que não seja usado em 10 segundos. Se a conexão não for utilizada, você pagou o custo total de TCP + TLS por nada.

Como funcionam as redes de anúncios modernas

Você inclui um script, esse script executa um leilão (geralmente com vários parceiros de demanda via header bidding através de algo como o Prebid.js), e o anúncio vencedor carrega recursos de servidores dos quais você nunca ouviu falar. A cadeia pode ter cinco ou mais domínios de profundidade. Isso é importante porque você não pode usar preconnect para domínios que não conhece no momento da análise do HTML.

Quando usar preconnect para redes de anúncios prejudica a performance

Se o seu LCP não estiver otimizado, usar preconnect para redes de anúncios piorará as coisas. Toda conexão antecipada compete por largura de banda em um momento em que seus recursos mais importantes (a imagem do LCP, folhas de estilo, fontes) ainda não foram baixados.

Dê uma olhada neste exemplo da vida real. O cliente tinha um LCP não otimizado e estava usando preconnect para vários domínios de anúncios. Depois que removi os preconnects de anúncios, eles passaram de 1,8 milhão de páginas boas para 6,24 milhões de páginas boas em apenas 3 meses.

Os preconnects estavam roubando a largura de banda da imagem do LCP. Remova a concorrência e o navegador poderá gastar seu tempo inicial de rede no que realmente importa.

Quando usar preconnect para redes de anúncios faz sentido

Se o seu LCP já for rápido, usar preconnect para a origem principal do script de anúncios não tem problema. Aqui está o checklist:

1. A imagem do seu LCP está no HTML (não injetada por JavaScript ou carregada do CSS)
2. A imagem do seu LCP não tem lazy load
3. A imagem do seu LCP possui fetchpriority="high"
4. A imagem do seu LCP é detectável pelo preload scanner do navegador

Quando todas as quatro opções forem verdadeiras, o navegador buscará a imagem do seu LCP com a prioridade mais alta, independentemente dos preconnects. O pequeno custo de largura de banda de um handshake TCP + TLS extra não afetará seu LCP. E anúncios mais rápidos significam mais impressões, pontuações de visibilidade mais altas e mais receita.

Em sites monitorados pelo CoreDash, um preconnect para a origem de uma única rede de anúncios economiza apenas alguns milissegundos de tempo de conexão. Isso não é suficiente para afetar o seu LCP se a imagem do LCP já estiver devidamente priorizada. Mas esses poucos milissegundos podem ser importantes para as taxas de preenchimento de anúncios.

Tenha muito cuidado

Isso não é um cheque em branco para usar preconnect em todos os domínios de anúncios que você encontrar. As regras:

1. Use preconnect apenas para uma origem: o domínio principal do seu script de anúncios. Não use preconnect para 15 domínios de parceiros de demanda do header bidding. Você não sabe quais deles vencerão o leilão.
2. Use preconnect apenas se o script ainda não for detectável. Se você carregar o script do seu anúncio com uma tag normal <script async src="https://adnetwork.ext/script.js">, o preload scanner do navegador já o encontra. Um preconnect além disso não acrescenta nada.
3. Scripts em cache tornam os preconnects inúteis. Se o script de anúncios já estiver no cache do navegador (comum para visitantes recorrentes em sites com muitos anúncios), o handshake TCP + TLS pré-conectado não será usado e é puro overhead.
4. Corrija seu LCP primeiro. Se você ainda não está passando no limite do LCP, não adicione preconnects de anúncios. Faça o preload da imagem do seu LCP, defina fetchpriority="high" e certifique-se de que ela não tenha lazy load. Em seguida, reavalie os preconnects de anúncios.

Se não tiver certeza de que seu LCP está devidamente otimizado, verifique seus dados de campo no CoreDash ou no CrUX antes de adicionar preconnects.

Se você ainda quiser usar um hint, use dns-prefetch em vez disso

Se você quiser alguma forma de hint de conexão antecipada para servidores de anúncios, mas não quiser o custo total de largura de banda de um preconnect, use dns-prefetch. Ele resolve apenas o DNS (20 a 120 ms), ignora totalmente o TCP e o TLS, e não cria uma conexão ociosa competindo por largura de banda.

<link rel="dns-prefetch" href="//securepubads.g.doubleclick.net">
<link rel="dns-prefetch" href="//pagead2.googlesyndication.com">

Este é um meio-termo mais seguro: você reduz o tempo de pesquisa do DNS sem o risco de disputa por largura de banda durante a janela crítica de renderização.

Quais redes de anúncios eu testei?

Estes são todos os preconnects que testei no ano passado. Se a sua rede de anúncios não estiver na lista, isso não significa que você deve usar preconnect. Apenas significa que eu não a testei para você. Configure um teste A/B com Real User Monitoring e teste o que funciona melhor para o seu site.

<link rel="preconnect" href="//securepubads.g.doubleclick.net">
<link rel="preconnect" href="//www.google.com">
<link rel="preconnect" href="//adservice.google.com">
<link rel="preconnect" href="//tpc.googlesyndication.com">
<link rel="preconnect" href="//pagead2.googlesyndication.com">
<link rel="preconnect" href="//www.gstatic.com">
<link rel="preconnect" href="https://s0.2mdn.net">
<link rel="preconnect" href="https://googleads.g.doubleclick.net">
<link rel="preconnect" href="https://www.googleadservices.com">
<link rel="preconnect" href="https://dis.criteo.com">
<link rel="preconnect" href="https://c1.adform.net">
<link rel="preconnect" href="https://snap.licdn.com">
<link rel="preconnect" href="https://visitor.omnitagjs.com">
<link rel="preconnect" href="https://secure.adnxs.com">
<link rel="preconnect" href="https://cdn.brandmetrics.com">
<link rel="preconnect" href="https://p.adsymptotic.com">
<link rel="preconnect" href="https://bidder.criteo.com">
<link rel="preconnect" href="https://gum.criteo.com">
<link rel="preconnect" href="https://sslwidget.criteo.com">
<link rel="preconnect" href="https://static.criteo.net">

Os números por trás disso

De acordo com o Web Almanac de 2025, 22% das páginas usam hints de preconnect e apenas 62% das origens em dispositivos móveis passam no LCP. Isso significa que uma grande parte da web está usando preconnect para origens de terceiros enquanto falha na exata métrica que esses preconnects podem prejudicar.

Os mesmos dados mostram que 17,3% das páginas em dispositivos móveis agora usam fetchpriority="high" em sua imagem do LCP. Se você estiver nesses 17,3%, sua imagem do LCP vence a corrida de prioridade e um único preconnect de anúncio provavelmente não causará problemas. Se você não estiver, comece por aí.