Anuncios y Core Web Vitals: convivir sin perder velocidad

Google avisa de que tu sitio va lento y la sospecha cae sobre la publicidad. A veces con razón y a veces no. Esto es qué mide cada métrica, qué parte del problema es realmente de los anuncios y qué se puede arreglar sin renunciar a los ingresos.

Qué mide Google cuando dice que tu sitio va lento

Core Web Vitals es el conjunto de métricas con las que Google resume la experiencia real de tus lectores. No son una nota de laboratorio: se calculan con datos de navegación de gente que ha abierto tus páginas, y el valor que se publica es el percentil 75, el valor por debajo del cual quedan tres de cada cuatro visitas.

Son tres. LCP (Largest Contentful Paint) mide cuánto tarda en aparecer el contenido principal. CLS (Cumulative Layout Shift, desplazamiento acumulado del diseño) mide cuánto se mueve la página sola mientras carga. INP (Interaction to Next Paint) mide cuánto tarda en responder cuando alguien toca algo. Las tres tienen un umbral público de Google para considerarse buenas.

LCP: cuánto tarda en aparecer lo que el lector vino a ver

El LCP marca el momento en que termina de pintarse el elemento visible más grande de la primera pantalla: normalmente la imagen de cabecera o el titular. Google considera buena una LCP de 2,5 segundos o menos, mejorable hasta 4 y mala por encima. Se mide desde que el usuario pide la página, no desde que responde tu servidor.

La publicidad rara vez es la culpable directa de un LCP malo: el creativo casi nunca es el elemento más grande de la primera pantalla. Lo es de forma indirecta. Si el navegador está ocupado descargando y ejecutando librerías publicitarias, tarda más en llegar a tu imagen principal. Nada del stack de anuncios debería competir por el ancho de banda con el recurso que define tu LCP.

CLS: el salto que hace fallar el clic

El CLS no se mide en segundos, sino con una puntuación sin unidades que combina cuánta superficie de la pantalla se mueve y cuánta distancia recorre. Google considera bueno un CLS de 0,1 o menos, mejorable hasta 0,25 y malo por encima. Cero es alcanzable, y es el objetivo razonable para una página de contenido.

Es la métrica más fácil de entender porque cualquiera la ha sufrido: estás leyendo, algo carga arriba, el texto baja de golpe y pierdes la línea. O peor: vas a pulsar un enlace y en ese instante aparece un bloque que lo empuja hacia abajo, así que pulsas otra cosa. Un desplazamiento justo después de una interacción del usuario no cuenta; el que ocurre solo, sí.

Por qué la publicidad es la sospechosa habitual del CLS

Porque un hueco publicitario, tal como se implementa por defecto, no tiene tamaño hasta que la subasta termina. El navegador pinta la página con el hueco a cero de alto, llega la respuesta, el creativo mide 250 píxeles y todo lo de debajo se desplaza 250 píxeles. Repetido en cinco huecos, el CLS se dispara. Los patrones más frecuentes:

• Huecos sin altura reservada, que pasan de cero a su tamaño final al llegar el anuncio.
• Huecos multitamaño en los que no se sabe qué altura llegará.
• Anuncios insertados entre párrafos cuando la página ya está pintada.
• Contenedores que colapsan con la subasta vacía y luego se rellenan con un respaldo.
• Barras adhesivas que empujan el contenido en vez de superponerse a él.

Reservar el espacio antes de que llegue el anuncio

La solución es aburrida y funciona: darle al contenedor su altura antes de pedir nada. Si el hueco va a servir un 300x250, ocupa 250 píxeles de alto desde el primer pintado, con un fondo neutro. Llegue lo que llegue, nada se mueve. En CSS se consigue con min-height o aspect-ratio, y conviene declarar alturas distintas por punto de ruptura.

Si un hueco admite varios tamaños, reserva la altura del mayor que realmente vayas a servir, o recorta la lista para que la diferencia sea pequeña. Y para la subasta vacía decide antes: o el contenedor mantiene su alto siempre, o se colapsa, pero no se colapsa después de haber estado abierto. Los huecos por encima del pliegue son los que más castigan.

Reservar el espacio no le quita ingresos a nadie: el anuncio se sirve igual, solo que sin empujar el texto.

INP y el coste real de los scripts publicitarios

El INP sustituyó al antiguo FID (First Input Delay) y mide algo más honesto: de todas las interacciones de la visita, cuánto tarda la página en mostrar una respuesta visible. Google considera bueno 200 milisegundos o menos, mejorable hasta 500 y malo por encima. Aquí la publicidad sí pesa de forma directa.

Un stack moderno carga la librería del servidor de anuncios, un wrapper de header bidding y un adaptador por cada socio de demanda. Todo eso es JavaScript que se ejecuta en el mismo hilo principal que atiende los toques del usuario. Mientras ese hilo resuelve una subasta, el menú no se abre. Lo que hay que vigilar no es cuántos socios tienes, sino cuánto hilo principal consumen entre todos.

Cargar de forma asíncrona: qué arregla y qué no

Un script normal bloquea: el navegador se detiene, lo descarga, lo ejecuta y solo entonces sigue construyendo la página. Con async lo descarga en paralelo y lo ejecuta en cuanto está listo, sin frenar el análisis del HTML. Con defer espera además a que el documento esté completo. Cualquier etiqueta publicitaria debería ir async.

Pero conviene entender el límite: async evita el bloqueo de la descarga, no el coste de la ejecución. El script sigue consumiendo hilo principal cuando le toca, y sigue pudiendo mover el diseño si el hueco no tiene altura reservada. Asíncrono es el punto de partida, no la solución completa.

Lazy loading: no pedir lo que nadie ha mirado todavía

Un artículo largo puede tener seis o siete huecos, pero el lector solo ve uno o dos antes de decidir si se queda. Pedirlos todos a la vez multiplica las peticiones, alarga la subasta y ocupa el hilo principal para nada. La carga diferida dispara la petición de cada hueco solo cuando se acerca al área visible.

El margen de anticipación es lo que hay que calibrar. Muy corto y el anuncio llega cuando el hueco ya pasó, lo que baja la visibilidad. Muy largo y vuelves a cargarlo todo. Un punto de partida habitual es pedir cuando el hueco está a una pantalla. Los huecos de la primera pantalla no se difieren nunca.

Cuántos huecos aguanta una página

La tentación cuando bajan los ingresos es añadir un hueco más. Cada hueco nuevo suma peticiones, tiempo de subasta y trabajo de hilo principal, y reparte la misma atención entre más unidades. Al mismo tiempo la página responde peor, y el lector que se va no llega a cargar ninguna impresión.

El ejercicio útil es mirar cada hueco por separado: qué visibilidad tiene, qué ingreso aporta y qué le cuesta a la página. Casi siempre aparecen uno o dos que apenas facturan y sí ensucian las métricas. Quitarlos suele salir mejor que sumar el octavo.

El resumen es corto: reserva la altura de todos los huecos, carga las etiquetas de forma asíncrona, difiere lo que está por debajo del pliegue y revisa cada posición por lo que aporta de verdad. La publicidad y una página rápida no son incompatibles; lo incompatible es una implementación publicitaria que nadie ha revisado.