Chrome publica en CrUX cuánta publicidad tiene cada web con cuatro métricas nuevas

Si te gusta mi contenido, dile a Google que te lo muestre antes:

Chrome ha añadido al Chrome UX Report (CrUX) cuatro métricas experimentales que miden la publicidad de cada web con datos de campo: número de anuncios en pantalla, superficie que ocupan, CPU y datos que consumen. Se consultan ya en la CrUX API y en CrUX Vis para cualquier origen con ads.txt, pero Google deja claro que no forman parte de Core Web Vitals y que no tienen umbrales.

Las cuatro métricas de anuncios que llegan a CrUX

El 15 de septiembre de 2026 Alex Cone publicó en el blog de Chrome for Developers el post «New ad metrics in Chrome User Experience Report». Desde ese día, el informe con los datos de campo de los usuarios de Chrome (el mismo del que salen los Core Web Vitals) incluye cuatro métricas sobre la publicidad que carga cada web. El propio post explica el porqué: "We've all encountered overwhelming ad experiences on the web. We know them when we see them, but they're hard to quantify". En pocas palabras, todos sabemos reconocer una web saturada de anuncios, pero hasta ahora no había forma de ponerle número.

Las cuatro métricas, con la definición de la documentación técnica que firma Kevin K. Lee:

  • Ad Count: la media de anuncios distintos visibles en el viewport mientras el usuario hace scroll.
  • Ad Density: "the average fraction of the visible viewport area occupied by ad frames", la fracción media de la pantalla que ocupan los anuncios.
  • Ad Weight: CPU: la suma del tiempo de ejecución de JavaScript, en milisegundos, que consumen los frames de anuncios y sus subrecursos.
  • Ad Weight: Network: los bytes comprimidos que se transfieren para cargar todo lo relacionado con los anuncios (scripts, imágenes, hojas de estilo).

La medición empieza con el TTFB del documento y termina al descargar la página. El número y la densidad se muestrean una vez por segundo sobre lo que hay en pantalla, y basta con que un píxel del anuncio esté dentro del viewport para que cuente. La CPU y la red se acumulan durante toda la visita, así que un anuncio oculto con display: none no suma en número ni en densidad, pero sí en consumo.

Chrome publica solo el percentil 75 sobre una ventana móvil de 28 días, igual que con el resto de CrUX, y con datos tanto a nivel de origen como de URL y separables por dispositivo. Entran Chrome en Windows, macOS, Android, ChromeOS y Linux; quedan fuera Chrome en iOS, las WebView de Android y el resto de navegadores basados en Chromium.

Hay un detalle que conviene tener presente antes de sacar conclusiones: la documentación no es coherente con las unidades. El post habla de bytes para la red y la página de la métrica de kilobytes, y la densidad aparece como porcentaje entero en un sitio y como decimal en la documentación de la API. Tampoco se reinicia la medición en las navegaciones internas de una SPA, algo que Google dice que "will likely change in the near future".

Cómo detecta Chrome qué es un anuncio

La detección combina dos cosas. Por un lado, una lista de filtros que es una versión reducida de EasyList, publicada en GitHub. Por otro, el análisis de la pila de JavaScript: si un script de anuncios está en la pila cuando se crea un recurso o un iframe, ese elemento se marca como anuncio, y la marca se mantiene aunque el iframe navegue después a otra cosa. El frame principal de la página nunca se clasifica como anuncio.

Es la misma detección que Chrome ya usaba para la Heavy Ad Intervention, la que descarga los anuncios que consumen demasiada CPU o red. Y se puede ver en local: en DevTools, el panel Application tiene ahora una pestaña Ads con la casilla «Highlight ads», que marca en rojo lo que Chrome considera publicidad y calcula las cuatro métricas de la página que tienes abierta. También hay una columna «Is ad-related» en el panel Network.

Panel Application de Chrome DevTools con la pestaña Ads, las métricas de densidad, número, CPU y red de los anuncios y la opción Highlight ads marcada
La pestaña Ads de DevTools, con el anuncio resaltado en rojo y las cuatro métricas medidas en local. Fuente: Chrome for Developers.

La propia herramienta avisa de que la detección de Chrome puede equivocarse, y la documentación añade que no hay ninguna API de JavaScript para replicarla en herramientas de RUM propias.

El requisito de ads.txt para tener datos

El post dice que las métricas siguen "the same eligibility criteria as our existing Web Vitals", es decir, que hace falta el volumen de tráfico mínimo de siempre. Pero la documentación añade un filtro más: "Pages and origins without at least one authorized seller defined in ads.txt file won't have ad metrics data in CrUX". En pocas palabras, sin un vendedor autorizado en ads.txt no hay datos, y un ads.txt con solo un registro de relleno tampoco vale.

Google lo justifica con que su detección "is most reliable on sites with recognizable advertising partners", es más fiable en webs con socios publicitarios reconocibles. Así que una web sin publicidad programática no va a aparecer en estas métricas aunque tenga banners propios.

Dónde consultar las métricas de anuncios de CrUX

Los datos están disponibles desde el 15 de septiembre en tres sitios. La CrUX API da los últimos 28 días con actualización diaria, con los campos experimental_ad_count, experimental_ad_density, experimental_ad_cpu y experimental_ad_kilobytes. La CrUX History API ofrece 40 puntos semanales (unos seis meses) que se publican cada lunes. Y CrUX Vis tiene una sección nueva, «Ad metrics», con las gráficas de las cuatro.

Sección Ad metrics de CrUX Vis con la gráfica del percentil 75 de Ad Count para un origen en móvil y los desplegables de Ad Density, Ad Weight CPU y Ad Weight Network
La nueva sección de métricas de anuncios en CrUX Vis, con la evolución de Ad Count en móvil. Fuente: Chrome for Developers.

Donde todavía no están es en BigQuery: la documentación dice que están trabajando en añadirlas al dataset de CrUX, sin fecha. Tampoco hay ninguna mención a PageSpeed Insights, Lighthouse ni Search Console. Y Chrome avisa de que "Developers should expect data availability to increase over the coming month", así que es normal que ahora mismo muchos orígenes aún no tengan datos. Barry Schwartz lo comprobó el mismo día en Search Engine Roundtable: con algunos sitios, las métricas no le aparecían.

Métricas experimentales y fuera de Core Web Vitals

Google lo repite en el post y en la documentación. En el post: "While inspired by Core Web Vitals […] CrUX ad metrics are not part of Core Web Vitals and don't have suggested targets or thresholds". En la documentación, además, que no tienen categorías de «bueno», «necesita mejorar» o «malo». Las cuatro llevan la etiqueta de experimentales porque Chrome dice estar abierto a cambiarlas según el feedback y a explorar métricas nuevas.

Ni el post ni las ocho páginas de documentación dicen nada sobre el posicionamiento en Google, ni a favor ni en contra. El público al que apunta Chrome es otro: "We expect these metrics to be particularly useful for web advertisers and the services they use to place ads", y el post recoge apoyos de WPP, The Guardian, Mediavine, Index Exchange y Display & Video 360. Search Engine Land apunta que Google no ha aclarado si DV360 usará estas señales para pujar o valorar inventario, y recoge, atribuido a Digiday, que las plataformas publicitarias independientes tendrán acceso a los datos al mismo tiempo que los negocios publicitarios de Google.

Mi lectura

Google no ha dicho que esto vaya a influir en el ranking, y de momento no hay motivo para pensarlo. Pero ojo, porque INP también nació como métrica experimental en CrUX y acabó siendo Core Web Vital, así que no descartaría que algún día la carga publicitaria pese en algo (es una hipótesis mía, Google no ha dicho nada parecido).

Si trabajas con medios o webs que viven de la publicidad, yo metería estas cuatro métricas en la Auditoría SEO junto a lo que ya se mira de WPO, sobre todo la CPU de los anuncios. Y si monetizas con AdSense, ojo también con el cambio en cómo cuenta las impresiones.