¿Deberías usar preconnect para las redes publicitarias?
Usar preconnect para las redes publicitarias puede parecer una gran idea para servir anuncios rápidamente, pero normalmente esto solo ralentizará la entrega de anuncios junto con otras métricas importantes
¿Deberías usar preconnect para las redes publicitarias?
Siempre que audito un sitio, reviso las estrategias de resource hints. A veces los clientes usan preconnect hacia redes publicitarias y eso es una elección interesante. La idea es bastante obvia: al usar preconnect hacia las redes publicitarias, esperan acelerar los anuncios y por lo tanto aumentar los ingresos.
Hay una desventaja en esta estrategia. Todo lo que haces al inicio de la carga de la página lleva tiempo (en forma de ciclos de CPU y uso de red). Ese es un tiempo valioso que, si se usa incorrectamente, puede ralentizar otros recursos más importantes.
En este artículo analizo más a fondo el uso de preconnect hacia las redes publicitarias.
Table of Contents!
Contexto: qué es preconnect
Un preconnect es una indicación para los navegadores de que el usuario probablemente necesitará recursos del origen del recurso objetivo, y por lo tanto el navegador puede mejorar la user experience iniciando preventivamente una conexión a ese origen
Contexto: ¿Cómo funcionan las redes publicitarias?
Las redes publicitarias son plataformas que conectan anunciantes y editores, facilitando el proceso de mostrar anuncios en diversos sitios web, aplicaciones u otras plataformas digitales. Funcionan reuniendo a dos actores clave: los anunciantes que quieren promocionar sus productos o servicios y los editores que tienen espacio publicitario disponible en sus plataformas.
¿Es más rápido usar preconnect hacia las redes publicitarias?
Respuesta corta: No, en cada prueba para cada cliente (desde 5.000 hasta 15 millones de páginas vistas diarias) para los que he trabajado, las métricas de Real User Metrics han demostrado que usar preconnect hacia servidores de anuncios solo ralentiza el Largest Contentful Paint. En la mayoría de los casos, liberar recursos incluso llevó a una visualización más rápida de los anuncios.
Solo mira este ejemplo real. ¡El cliente pasó de 1,8 millones de páginas buenas a 6,24 millones de páginas buenas en solo 3 meses después de que eliminé los preconnects de anuncios!

Respuesta larga: probablemente no. Las redes publicitarias generalmente funcionan cargando un solo script. Este script puede activar la descarga de algunos scripts más (¡alojados en diferentes hosts!). Luego las cosas se complican, pero básicamente la red publicitaria intenta llenar tus espacios publicitarios. Para cada espacio publicitario necesitará descargar nuevos recursos (HTML, imágenes, CSS, fuentes, nuevos scripts, etc.) desde diferentes servidores.
Así que desglosémoslo
El problema con preconnect en general
Preconnect abrirá una conexión a un servidor externo en las primeras etapas del proceso de renderizado. El objetivo del preconnect es tener una conexión ya abierta a ese servidor una vez que se necesiten los archivos. Eso puede ahorrar tiempo valioso, pero tiene un coste.
En primer lugar, las conexiones de red tempranas competirán con otros recursos de red muy al inicio del proceso de renderizado. En este momento, los recursos más importantes como la imagen LCP, las hojas de estilo y las fuentes aún no se han descargado. ¡Así que no es un buen momento para competir por recursos!
En segundo lugar, no tenemos forma de saber si realmente necesitaremos esa conexión de red. Quizás el script ya
está en la caché del navegador y la conexión abierta no se utilizará por esa razón. En ese caso, incluso si
preconnect hubiera sido más rápido, debido al caché del lado del cliente, ¡solo estamos añadiendo una nueva conexión inútil
para cada visita repetida!
Como regla general, generalmente es mejor usar
preconnect solo hacia los dominios de recursos más importantes (como tu CDN principal)
¿Deberías usar preconnect hacia el script principal de anuncios?
Usar preconnect hacia el script principal de anuncios solo acelerará los anuncios si el script de anuncios por alguna razón no es detectable por el preload scanner
Si quieres priorizar tus anuncios y por alguna razón no estás usando una etiqueta de script externo normal
<script async src="https://adnetwork.ext/script.js"> y el script de anuncios no es
cacheable por el navegador, entonces (¡y solo entonces!) usar preconnect podría ser una buena idea. En todos los demás casos es mejor
no usar preconnect.
¿Deberías usar preconnect hacia los dominios que las redes publicitarias usarán después?
¿Qué redes publicitarias probé?
¿Te interesa saber si este artículo aplica a tu red publicitaria? Estas son todas las preconnects que he probado en el último año. Si tu red publicitaria no está en la lista, no significa que debas usar preconnect. Solo significa que no lo he probado para ti. ¡Deberías configurar una prueba A/B y probar qué funciona mejor para ti!
<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"
/>
Your dev team is busy.
Delegate the performance architecture to a specialist. I handle the optimization track while your team ships the product.
- Parallel Workflows
- Specialized Expertise
- Faster Delivery