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, sempre observo 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 sua imagem Largest Contentful Paint já está devidamente otimizada?

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

Se a sua imagem LCP estiver no HTML (não injetada por JavaScript), não tiver lazy load e tiver fetchpriority="high", o navegador irá priorizá-la, independentemente de qualquer outra coisa para a qual você use preconnect. Nesse caso, usar o preconnect para a origem da sua rede de anúncios principal é seguro e pode realmente gerar lucro ao exibir anúncios alguns milissegundos mais rápido.

O que um preconnect realmente faz

Uma hint de preconnect informa 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 web.dev, isso pode economizar de 100 a 500ms para origens críticas.

A pegadinha: 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 à toa.

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 o 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 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 largura de banda da imagem 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 do seu script de anúncio principal não tem problema. Aqui está a lista de verificação:

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

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

Em sites monitorados pelo CoreDash, um preconnect para uma única origem de 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 LCP já estiver devidamente priorizada. Mas esses poucos milissegundos podem ser importantes para as taxas de preenchimento de anúncios.

Tenha extremo cuidado

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

1. Use preconnect apenas para uma origem: o domínio do seu script de anúncio principal. Não use preconnect para 15 domínios de parceiros de demanda de header bidding. Você não sabe quais deles vencerão o leilão.
2. Apenas use preconnect se o script ainda não for detectável. Se você carrega o seu script de anúncio com uma tag <script async src="https://adnetwork.ext/script.js"> normal, 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úncio já estiver no cache do navegador (comum para visitantes recorrentes em sites com muitos anúncios), o handshake de TCP + TLS com preconnect fica sem uso e é pura sobrecarga.
4. Corrija seu LCP primeiro. Se você ainda não está passando do limite do LCP, não adicione preconnects de anúncios. Faça o preload da sua imagem LCP, defina fetchpriority="high" e certifique-se de que ela não possua lazy load. Depois, revise os preconnects de anúncios.

Se você não tem certeza se o seu LCP está otimizado de forma adequada, verifique os seus dados de campo no CoreDash ou no CrUX antes de adicionar preconnects.

Se você ainda quiser usar uma 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 quer o custo total de largura de banda de um preconnect, use dns-prefetch em vez disso. Ele resolve apenas o DNS (20 a 120ms), ignora o TCP e o TLS inteiramente, 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 de DNS sem o risco de disputa de largura de banda durante a janela de renderização crítica.

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ê deva usar preconnect. Significa apenas que 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 mobile passam no LCP. Isso significa que uma grande parte da web está usando preconnect para origens de terceiros enquanto falha na métrica exata que esses preconnects podem prejudicar.

Os mesmos dados mostram que 17,3% das páginas mobile agora usam fetchpriority="high" em suas imagens LCP. Se você está nesses 17,3%, sua imagem LCP vence a corrida de prioridade e é improvável que um único preconnect de anúncio cause problemas. Se você não está, comece por aí.