Core Web Vitals y publicidad: medir antes de optimizar

Los anuncios programáticos añaden red y JavaScript: el navegador descarga adsbygoogle.js, procesa etiquetas y puede insertar un iframe después del primer diseño. El efecto depende del dispositivo, la subasta y la posición. Mide LCP, CLS e INP en campo y reproduce los casos lentos en DevTools.

Qué miden LCP, CLS e INP

Los Core Web Vitals resumen tres experiencias distintas. Google evalúa los datos de campo en el percentil 75 y separa móvil y escritorio. Usa estas referencias como objetivos de experiencia, no como una garantía de posicionamiento o aprobación publicitaria:

async evita bloquear el análisis del HTML, pero el anuncio aún usa red y CPU y puede competir con la imagen LCP. Revisa la traza antes de atribuirle una puntuación baja: registra el elemento LCP, las solicitudes y las tareas cercanas.

LCP: separa la ruta crítica del inventario publicitario

Identifica el elemento LCP y graba una recarga con limitación de red y CPU en DevTools Performance. Selecciona su marcador y separa espera de servidor, descubrimiento, descarga y renderizado. Si un anuncio se adelanta a un recurso crítico, prueba diferir posiciones lejanas o reducir conexiones, manteniendo la integración publicitaria documentada.

No uses loading="lazy" en la imagen LCP. Difiere solo posiciones fuera del primer viewport y compara plantillas, dispositivos y consentimiento. Una subasta lenta de un bloque lejano no demuestra por sí sola la causa del LCP. Para el coste de más socios, revisa header bidding y Prebid.

En el waterfall de Network filtra por dominios de anuncios y compara inicio de descarga, duración y prioridad con el recurso LCP. Repite con el mismo viewport y perfil de red; si eliminas o retrasas un script en una prueba controlada, anota también fill rate e impresiones para no atribuir a velocidad un cambio causado por menos anuncios.

CLS: reserva el tamaño antes de pedir el anuncio

Reserva espacio en el contenedor antes de solicitar el anuncio. Para un tamaño conocido, fija una altura mínima coherente; para una proporción estable, usa aspect-ratio. Define el tamaño por breakpoint si móvil y escritorio admiten formatos distintos. Evita alturas arbitrarias: el hueco vacío también afecta a lectura y desplazamiento.

.ad-slot {
  display: block;
  width: 100%;
  min-height: 280px; /* ejemplo para una posición móvil */

}

.ad-slot--banner {
  min-height: 90px;
  aspect-ratio: 728 / 90; /* reserva para un formato horizontal */
}

@media (max-width: 600px) {
  .ad-slot--banner {
    min-height: 100px;
    aspect-ratio: 320 / 100;
  }
}

Los tamaños del ejemplo son ilustrativos: comprueba formatos reales en la cuenta y el viewport. Si una creatividad es menor que la reserva, el contenedor mantiene el espacio. Contrae un bloque después del renderizado solo tras medir el desplazamiento; alternar display:none puede crear CLS.

El CLS acumula cambios durante la visita. Graba scroll y espera a la respuesta del iframe: una prueba inicial puede omitir ese salto. Reservar el espacio no corrige imágenes sin dimensiones, fuentes tardías, banners de consentimiento ni otros componentes insertados.

Comprueba al menos anchos de 320, 375, 768 y 1024 píxeles y captura el estado antes y después de servir un anuncio. Registra la altura reservada, la creatividad resultante y el elemento que se desplaza. Ajusta el contenedor por plantilla; no uses una sola reserva global si el slot y los formatos cambian.

INP: localizar tareas largas de terceros

INP mide interacciones como abrir un menú o cerrar un banner. En DevTools Performance selecciona una interacción lenta y separa demora de entrada, procesamiento y presentación; expande las tareas del hilo principal. El trabajo del anuncio puede contribuir, pero también un menú propio o una etiqueta analítica.

Divide tareas propias largas y evita inicializar librerías pesadas al abrir la página. Contrasta la traza con datos de campo: Lighthouse no reproduce cada interacción real. CrUX agrega visitas; si una URL no tiene muestra, declara que el resultado es de laboratorio.

Si la interacción coincide con una respuesta publicitaria, revisa el hilo principal y los callbacks que se ejecutan alrededor del mismo instante. El objetivo no es bloquear cualquier script externo: identifica el trabajo concreto, evalúa si puede diferirse y repite la interacción con el mismo estado de consentimiento y la misma carga.

Lazy loading con margen: no esperes a que el bloque sea visible

Usa IntersectionObserver para iniciar una posición cuando se aproxima al viewport. Un margen de 700 píxeles es solo un valor de prueba: da tiempo a solicitar y renderizar antes de que llegue la persona. Esperar a la intersección exacta puede dejar el hueco vacío; solicitar todo al inicio resta valor al diferido.

El ejemplo presupone la etiqueta de AdSense cargada una vez y un slot real con sus atributos; sus IDs son ficticios. Respeta el punto de consentimiento y la integración documentada. No alteres anuncios para provocar clics u ocultar su comportamiento.

const observer = new IntersectionObserver((entries, currentObserver) => {
  for (const entry of entries) {
    if (!entry.isIntersecting) continue;

    const slot = entry.target.querySelector(".adsbygoogle");
    if (slot && slot.dataset.requested !== "true") {
      slot.dataset.requested = "true";
      (window.adsbygoogle = window.adsbygoogle || []).push({});
    }
    currentObserver.unobserve(entry.target);
  }
}, { rootMargin: "700px 0px" });

document.querySelectorAll("[data-ad-lazy]").forEach((container) => {
  observer.observe(container);
});

Solicitar antes no asegura Active View: cuentan el renderizado y que al menos la mitad del área permanezca visible el tiempo requerido. Mide Active View Viewable y cambia el margen de una posición cada vez; equilibra visibilidad con Core Web Vitals.

Proceso reproducible con Chrome DevTools y CrUX

1. Elige páginas representativas. Incluye una plantilla de artículo, una portada, al menos un móvil y un escritorio; el mismo slot puede estar en un lugar distinto según la plantilla.
2. Graba una línea base. En DevTools Performance, activa las métricas web, simula una conexión móvil y registra carga, interacción y scroll. Anota el navegador, viewport y pasos realizados.
3. Inspecciona eventos concretos. Selecciona el marcador LCP, abre los cambios de layout y revisa tareas largas alrededor de interacciones. Filtra las solicitudes por dominio para localizar los recursos de Google y socios.
4. Contrasta campo y laboratorio. Consulta CrUX o PageSpeed Insights para la URL u origen y separa escritorio de móvil. CrUX es agregado y puede no tener suficiente muestra para cada URL.
5. Cambia una variable y repite. Reserva espacio, difiere solo posiciones lejanas o reduce trabajo de terceros. Conserva tráfico, ingresos, impresiones y Active View como guardas para detectar un coste no deseado.

Aplica una hipótesis pequeña y compara tráfico, periodo y dispositivo equivalentes. Relaciona el análisis con integración del código y transparencia de vendedores; una puntuación de laboratorio no prueba una mejora de campo.

En CrUX, distingue datos de origen y de URL cuando ambos están disponibles. Un resultado de origen mezcla páginas con plantillas distintas; úsalo para contexto y apóyate en las grabaciones de la plantilla que estás cambiando. Mantén un registro de fecha, versión y configuración para que el siguiente despliegue permita una comparación reproducible.

Errores frecuentes en producción y diagnóstico

• CLS tras el scroll: graba la posición y compara tamaño del contenedor antes y después de la puja.
• Reserva móvil incorrecta: prueba breakpoints y formatos servidos en el viewport real.
• LCP no mejora: identifica el elemento LCP y revisa waterfall, imagen, fuentes y servidor.
• Menú lento: localiza tareas largas y listeners duplicados alrededor de la interacción.
• Active View cae: mide latencia y visibilidad; ajusta el margen, no fuerces scroll ni clics.
• DevTools y CrUX discrepan: compara mismo dispositivo y periodo; son datos de laboratorio y campo distintos.

Preguntas frecuentes

¿Async elimina el coste de adsbygoogle.js?

No. Evita bloquear el parser, pero hay uso de red, CPU e iframes. Comprueba las tareas y solicitudes reales.

¿La altura mínima garantiza CLS cero?

No. Reduce desplazamientos por expansión, pero otros elementos pueden moverse; mide la visita completa.

¿Debo diferir todos los anuncios hasta que sean visibles?

No siempre. Solicitar tarde puede reducir visibilidad; usa un margen medido y revisa Active View.

¿Lighthouse demuestra experiencia de campo?

No. DevTools y Lighthouse ayudan a diagnosticar; CrUX aporta datos agregados de visitas reales cuando hay muestra.

Referencias técnicas

• Core Web Vitals y umbrales oficiales, optimización de CLS y optimización de INP.
• Buenas prácticas de Active View y criterio de visibilidad.