¿Deberías usar preconnect para las redes publicitarias? Depende de tu LCP

La respuesta corta: depende de tu LCP

Siempre que audito un sitio analizo las estrategias de resource hints. A veces, los clientes usan preconnect para las redes publicitarias, con la esperanza de acelerar los anuncios y aumentar los ingresos. Si esto ayuda o perjudica depende por completo de una cosa: ¿está tu imagen Largest Contentful Paint correctamente optimizada?

Última revisión por Arjen Karel en marzo de 2026

Si tu imagen LCP está en el HTML (no inyectada por JavaScript), no tiene carga diferida (lazy loaded) y tiene fetchpriority="high", el navegador la priorizará independientemente de a qué otra cosa le hagas preconnect. En ese caso, usar preconnect para el origen principal de tu red publicitaria es seguro y, de hecho, puede hacerte ganar dinero al servir anuncios unos milisegundos más rápido.

Pero si tu LCP no está optimizado, cada preconnect que añadas competirá por el ancho de banda y los ciclos de CPU en el peor momento posible. He visto que esto sale mal en sitios con entre 5.000 y 15 millones de páginas vistas diarias.

Qué hace realmente un preconnect

Un resource hint de preconnect le dice al navegador que abra una conexión (DNS + TCP + TLS) a un servidor externo antes de que realmente necesite un archivo de allí. Cuando finalmente se solicita el archivo, la conexión ya está activa y la descarga comienza de inmediato. Según web.dev, esto puede ahorrar de 100 a 500 ms para orígenes críticos.

El problema: Chrome cierra cualquier preconnect que no se utilice en 10 segundos. Si la conexión no se usa, pagaste el coste total de TCP + TLS para nada.

Cómo funcionan las redes publicitarias modernas

Incluyes un script, ese script ejecuta una subasta (a menudo con múltiples socios de demanda a través de header bidding mediante algo como Prebid.js), y el anuncio ganador carga recursos de servidores de los que nunca has oído hablar. La cadena puede tener una profundidad de cinco o más dominios. Esto es importante porque no puedes usar preconnect en dominios que no conoces en el momento de analizar el HTML.

Cuándo usar preconnect en redes publicitarias perjudica el rendimiento

Si tu LCP no está optimizado, usar preconnect para las redes publicitarias empeorará las cosas. Cada conexión temprana compite por el ancho de banda en un momento en que tus recursos más importantes (la imagen LCP, las hojas de estilo, las fuentes) aún no se han descargado.

Echa un vistazo a este ejemplo de la vida real. El cliente tenía un LCP sin optimizar y estaba usando preconnect para múltiples dominios publicitarios. Después de eliminar los preconnects de anuncios, pasaron de 1,8 millones de páginas buenas a 6,24 millones de páginas buenas en solo 3 meses.

Los preconnects estaban robando ancho de banda a la imagen LCP. Elimina la competencia y el navegador podrá invertir su tiempo de red inicial en lo que realmente importa.

Cuándo tiene sentido usar preconnect en redes publicitarias

Si tu LCP ya es rápido, usar preconnect para el origen de tu script principal de anuncios está bien. Aquí tienes la lista de verificación:

1. Tu imagen LCP está en el HTML (no inyectada por JavaScript ni cargada desde CSS)
2. Tu imagen LCP no tiene carga diferida (lazy loaded)
3. Tu imagen LCP tiene fetchpriority="high"
4. Tu imagen LCP es descubrible por el preload scanner del navegador

Cuando las cuatro son verdaderas, el navegador obtendrá tu imagen LCP con la máxima prioridad, independientemente de los preconnects. El pequeño coste de ancho de banda de un handshake TCP + TLS adicional no afectará tu LCP. Y anuncios más rápidos significan más impresiones, mejores puntuaciones de visibilidad y más ingresos.

En los sitios monitorizados por CoreDash, un preconnect a un único origen de red publicitaria ahorra solo unos pocos milisegundos de tiempo de conexión. Eso no es suficiente para afectar tu LCP si la imagen LCP ya está correctamente priorizada. Pero esos pocos milisegundos pueden ser importantes para las tasas de completado (fill rates) de anuncios.

Ten mucho cuidado

Esto no es un cheque en blanco para usar preconnect en todos los dominios de anuncios que encuentres. Las reglas:

1. Usa preconnect solo para un origen: el dominio principal de tu script de anuncios. No uses preconnect en 15 dominios de socios de demanda del header bidding. No sabes cuáles ganarán la subasta.
2. Solo usa preconnect si el script no es ya descubrible. Si cargas tu script de anuncios con una etiqueta normal <script async src="https://adnetwork.ext/script.js">, el preload scanner del navegador ya lo encuentra. Un preconnect además de eso no aporta nada.
3. Los scripts cacheados hacen que los preconnects sean inútiles. Si el script de anuncios ya está en la caché del navegador (algo común en visitantes recurrentes en sitios con muchos anuncios), el handshake TCP + TLS preconectado no se usa y es puro desperdicio.
4. Arregla tu LCP primero. Si aún no estás superando el umbral de LCP, no añadas preconnects de anuncios. Usa preload para tu imagen LCP, configura fetchpriority="high" y asegúrate de que no tenga carga diferida. Luego vuelve a revisar los preconnects de anuncios.

Si no estás seguro de si tu LCP está optimizado correctamente, verifica tus datos de campo en CoreDash o CrUX antes de añadir preconnects.

Si aún deseas usar hints, usa dns-prefetch en su lugar

Si quieres algún tipo de conexión temprana mediante hints para los servidores de anuncios pero no quieres el coste total de ancho de banda de un preconnect, usa dns-prefetch en su lugar. Solo resuelve el DNS (20 a 120 ms), omite por completo el TCP y el TLS, y no crea una conexión inactiva compitiendo por el ancho de banda.

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

Este es un punto medio más seguro: reduces el tiempo de búsqueda DNS sin el riesgo de contención de ancho de banda durante la ventana de renderizado crítica.

¿Qué redes publicitarias he probado?

Estos son todos los preconnects que he probado en el último año. Si tu red publicitaria no está en la lista, eso no significa que debas usar preconnect. Solo significa que no la he probado por ti. Configura un test A/B con Real User Monitoring y prueba qué funciona mejor para tu sitio.

<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">

Los números detrás de esto

Según el Web Almanac de 2025, el 22% de las páginas utilizan hints de preconnect y solo el 62% de los orígenes móviles aprueban el LCP. Eso significa que una gran parte de la web está usando preconnect hacia orígenes de terceros mientras suspende la misma métrica a la que esos preconnects pueden perjudicar.

Los mismos datos muestran que el 17,3% de las páginas móviles ahora usan fetchpriority="high" en su imagen LCP. Si estás en ese 17,3%, tu imagen LCP gana la carrera de prioridad y es poco probable que un solo preconnect de anuncios cause problemas. Si no lo estás, empieza por ahí.