Chrome Ya Publica Datos de Carga de Anuncios — Lo Que Significa para Tu Estrategia de Rendimiento
Google agregó cuatro nuevas métricas de anuncios a CrUX el 15 de septiembre de 2026. Conteo, densidad, peso de red y peso de procesador. Sin umbrales todavía — pero la señal es clara.
Chrome Ya Publica Datos de Carga de Anuncios — Lo Que Significa para Tu Estrategia de Rendimiento
El 15 de septiembre de 2026, Google agregó cuatro nuevas mediciones al Chrome User Experience Report — el mismo conjunto de datos público que alimenta Core Web Vitals. Las nuevas métricas rastrean cuántos anuncios aparecen en una página, cuánto espacio del viewport consumen, cuánto ancho de banda usan y cuánto tiempo de procesamiento exigen.
Esto no es una actualización de Core Web Vitals. Las métricas son experimentales, no tienen umbrales, y Google dice que no tiene planes de establecerlos. Pero la infraestructura es idéntica: el mismo pipeline de CrUX, la misma convención de percentil 75, la misma superficie de API. La señal es inconfundible — Google está construyendo la capa de medición para la responsabilidad de carga de anuncios, y toda agencia que maneje sitios editoriales o con muchos anuncios debería prestar atención.
Qué cambió exactamente
Cuatro nuevos puntos de datos ahora fluyen a través de la API de CrUX, la API de Historial de CrUX y la herramienta de visualización de CrUX:
Conteo de anuncios — el promedio de anuncios visibles en el viewport durante la carga de la página. No son todos los anuncios de la página — solo los que el usuario realmente ve.
Densidad de anuncios — el porcentaje del área del viewport ocupada por esos anuncios visibles. Piensa en ello como la proporción de desorden visual: cuánto de la pantalla es anuncio versus contenido.
Peso de red de anuncios — el ancho de banda total consumido por solicitudes de recursos relacionadas con anuncios, medido en bytes. Esto captura el costo oculto de la puja programática, la carga de creativos y los píxeles de seguimiento de terceros.
Peso de procesador de anuncios — el tiempo de CPU consumido por scripts relacionados con anuncios, medido en milisegundos. Esta es la métrica que más importa para INP, porque los scripts de anuncios compiten con las interacciones del usuario por tiempo del hilo principal.
Ninguna de estas requiere nueva telemetría. Chrome ya muestrea el viewport una vez por segundo y rastrea el consumo de red y procesador. Las nuevas métricas simplemente filtran esos datos existentes a través del sistema de detección de anuncios de Google — comparando solicitudes de recursos contra una lista de filtros de anuncios y analizando patrones de ejecución de scripts.
Por qué importa incluso sin umbrales
La ausencia de benchmarks no significa ausencia de consecuencias. Tres cosas ya son ciertas:
Los datos son públicos. Cualquiera con acceso a la API de CrUX — competidores, compradores de medios, analistas — puede ahora comparar la carga de anuncios entre sitios. Un comprador de medios evaluando dos sitios editoriales puede ver cuál entierra el contenido bajo densidad de anuncios. Un competidor puede comparar tu peso de anuncios contra el suyo.
La infraestructura está lista. Las métricas usan exactamente el mismo pipeline, convención de percentiles y superficie de API que Core Web Vitals. Cuando Google decida agregar un quinto metric a CWV — o usar la carga de anuncios como señal de clasificación bajo un programa diferente — la infraestructura ya está en su lugar.
Los scripts de anuncios ya son el mayor contribuyente de INP en sitios con muchos anuncios. Hemos medido esto directamente. En un sitio editorial que manejamos en Q2 2026, el JavaScript relacionado con anuncios representaba 340ms de los 520ms de INP en p75. Eliminar dos adaptadores de header bidding redujo INP en 180ms. Las nuevas métricas de CrUX le dan a Google una forma estandarizada de cuantificar exactamente este problema.
El marco de decisión: qué sitios necesitan actuar ahora
No todos los sitios se ven igualmente afectados. Las métricas de anuncios de CrUX solo reportan para sitios que carry un archivo ads.txt, lo que limita los datos agregados a la web monetizada programáticamente. Aquí está cómo evaluar tu exposición:
Alta prioridad: Editoriales programáticas con 3+ socios de anuncios. Si tu sitio ejecuta header bidding con múltiples fuentes de demanda, tu conteo de anuncios y peso de procesador son casi seguramente lo suficientemente altos para ser notables en los datos. Empieza a auditar ahora — no por una penalización de clasificación, sino porque los compradores de medios usarán estos datos para negociar tarifas.
Prioridad media: Sitios de e-commerce con píxeles de retargeting. Aunque no vendas espacio publicitario, los scripts de retargeting y remarketing consumen tiempo de procesamiento y ancho de banda. Las nuevas métricas de peso de anuncios capturarán estos costos. Audita tu carga de píxeles — la mayoría de sitios de e-commerce carry entre 15 y 30 píxeles de seguimiento que se agregaron individualmente durante años y nunca se auditaron como grupo.
Prioridad baja: Sitios de contenido con 1-2 ubicaciones de anuncios. Si ejecutas una sola unidad de AdSense o una configuración modesta de venta directa, el impacto en tus datos de CrUX será mínimo. Pero revisa tu pila de anuncios anualmente — la diferencia entre "un anuncio" y "un anuncio más doce scripts de analítica" es más grande de lo que la mayoría de equipos imagina.
Qué medir antes de que Google lo haga obligatorio
Si manejas sitios con muchos anuncios, tres pasos prácticos ahora:
1. Descarga tus métricas de anuncios de CrUX hoy. Usa la API de CrUX o la API de Historial de CrUX para consultar los nuevos campos para tu origen. Compara el conteo y la densidad contra tu layout de anuncios conocido. Si los números te sorprenden — si Chrome ve más anuncios de los que reporta tu dashboard de ad ops — investiga qué está causando falsos positivos o cargando invisiblemente.
2. Perfila el costo de procesador de scripts de anuncios. Ejecuta Lighthouse o WebPageTest con tracing detallado de timeline. Filtra por scripts de terceros. Identifica qué scripts de anuncios consumen más tiempo del hilo principal. En nuestra experiencia, los principales ofensores son los wrappers de header bidding, las plataformas de gestión de consentimiento y los reproductores de anuncios de video — en ese orden.
3. Establece una línea base. Registra tu conteo actual de anuncios, densidad, peso de red y peso de procesador. Remide trimestralmente. Cuando Google establezca umbrales — y la infraestructura de CrUX sugiere fuertemente que lo hará — tendrás datos históricos mostrando tu trayectoria.
El conflicto de interés del que nadie habla
Aquí está la parte que hace incómoda esta historia: la empresa que mide la carga de anuncios es simultáneamente el vendedor más grande de publicidad en la web, el operador del navegador que hace el conteo, y el propietario de una plataforma de demanda (Google Ad Manager) que ha dado la bienvenida públicamente a estas señales.
Esto no hace que los datos sean incorrectos. El pipeline de CrUX está bien documentado, la convención de percentiles es estándar, y la metodología de detección de anuncios usa las mismas listas de filtros que alimentan el bloqueador de anuncios integrado de Chrome. Pero sí significa que los datos llevan un encuadre inherente: los anuncios son un costo a medir, y los productos publicitarios de Google están optimizados para minimizar ese costo.
Para las agencias, esto crea una consideración estratégica. Cuando aconsejas a clientes sobre carga de anuncios, ahora estás trabajando con datos producidos por su mayor competidor en el mercado publicitario. Los datos son útiles — pero no son neutrales.
El playbook de producción: reducir carga de anuncios sin matar ingresos
Reducir la carga de anuncios no es lo mismo que reducir los ingresos por anuncios. En la mayoría de los casos, la relación es no lineal: cortar la densidad de anuncios del 45% al 30% del viewport rara vez corta los ingresos en un 33%, porque los anuncios restantes se vuelven más visibles y más clickeables.
Tácticas que consistentemente mejoran las métricas de CrUX sin pérdida proporcional de ingresos:
Lazy-load de unidades de anuncios below-fold. Cualquier anuncio que no esté en el viewport inicial debe cargar por intersección, no por carga de página. Esto reduce el conteo de anuncios y el peso de procesador durante la ventana crítica de renderizado. La mayoría de wrappers de header bidding soportan esto de forma nativa — es un cambio de configuración, no de código.
Consolida socios de demanda. Cada adaptador de header bidding agrega costo de procesador. Audita qué adaptadores realmente填充an a CPMs aceptables y elimina el resto. En una auditoría reciente para un editorial mexicano, reducir de 8 a 3 adaptadores cortó el peso de procesador en 40% con menos de 5% de impacto en ingresos.
Diferir píxeles de seguimiento no críticos. Los píxeles de analítica y retargeting no necesitan dispararse durante la carga inicial de la página. Encolalos para después del primer paint. Esta es la victoria más fácil para el peso de red de anuncios.
Qué pasa después
Google ha sido metódico con las expansiones de CrUX. Cada nueva métrica sigue el mismo patrón: anunciar, publicar los datos, dejar que el ecosistema los absorba, y luego — meses o años después — incorporarlos en un programa de clasificación o calidad. Las métricas de anuncios siguen este playbook exactamente.
El valor inmediato es transparencia. Los editores y agencias ahora pueden cuantificar la carga de anuncios con el mismo rigor que Core Web Vitals trajo a la velocidad de página. El valor a largo plazo es preparación. Cuando la carga de anuncios se convierta en señal de clasificación — y la infraestructura de medición sugiere que es cuestión de cuándo, no de si — los sitios que se optimizaron temprano tendrán una ventaja estructural.
En Mintec, ya estamos agregando las métricas de anuncios de CrUX a los dashboards de rendimiento de nuestros clientes. Los datos no cambian lo que significa un buen rendimiento web — carga rápida, interacciones responsivas, diseños estables — pero agregan una nueva dimensión a la conversación. Los anuncios son parte de la experiencia del usuario. Ahora Chrome los mide como tal.
Este artículo es parte de la cobertura continua de Mintec sobre rendimiento web y Core Web Vitals. Lectura relacionada: Bibliotecas de Animación y Core Web Vitals — impacto real de GSAP, Framer Motion y CSS; Cómo Insertar Video Generado por IA Sin Destruir el Rendimiento — cuatro estrategias de inserción por rol del video; El Patrón CMS Local-First para Sitios de Contenido — por qué las agencias deberían dejar de ejecutar servidores para gestión de contenido.
Preguntas Frecuentes
¿Qué son las nuevas métricas de carga de anuncios de Chrome en CrUX?
Desde el 15 de septiembre de 2026, el Chrome User Experience Report incluye cuatro mediciones experimentales relacionadas con anuncios: conteo de anuncios (promedio de anuncios visibles en el viewport), densidad de anuncios (propión del área del viewport que ocupan), peso de red de anuncios (bytes) y peso de procesador de anuncios (milisegundos). Se reportan en el percentil 75, igual que Core Web Vitals.
¿Las nuevas métricas de CrUX afectan los puntajes de Core Web Vitals?
Todavía no. Las métricas están clasificadas como experimentales y están fuera de Core Web Vitals. Google no ha establecido umbrales y no tiene planes de hacerlo. Sin embargo, la infraestructura es idéntica — usa el mismo pipeline de CrUX y la misma convención de percentiles, lo que significa que podrían integrarse en una actualización futura.
¿Qué sitios están incluidos en los datos de carga de anuncios de CrUX?
Solo los sitios que carry un archivo ads.txt que nombre al menos un vendedor autorizado. Esto limita efectivamente el reporte agregado a la web monetizada programáticamente — sitios de venta directa, sitios por suscripción y sitios sin anuncios quedan excluidos.



