CLS A/B testing

CLS (Cumulative Layout Shift) es una de las tres Core Web Vitals definidas por Google, y mide la estabilidad visual de una página web: es decir, la forma en que los elementos se desplazan de manera inesperada durante la carga.
En el marco del A/B testing, el CLS es una trampa frecuente que puede falsear los resultados de un test o perjudicar la experiencia de usuario, incluso si la variación probada parece mejor en el fondo.

🎯 Por qué es crítico en A/B testing

Un A/B test busca aislar el impacto de un cambio específico en el comportamiento del usuario (clic, conversión…). Pero si la variación introduce un desplazamiento visual (ej.: botón que salta, imagen que empuja el contenido hacia abajo), entonces:

• La interacción del usuario se ve alterada: clic fallido, mala impresión, atención desviada,
• El resultado del test se ve sesgado: la caída de rendimiento no proviene del contenido probado, sino de la calidad de ejecución técnica.

💡 Un CLS demasiado elevado no será visible en los KPIs clásicos, pero afectará el CVR sin que se entienda por qué.

🧪 Cómo un A/B test puede provocar CLS

Estos son los escenarios frecuentes en los que una variación genera CLS de forma involuntaria:

• Añadir una imagen o un bloque HTML sin reservar espacio: el contenido "empuja" el resto de la página una vez cargado,
• Carga de scripts de A/B test mediante un tag manager lento (en lugar de una integración directa en el <head>),
• Inserción dinámica de un mensaje o una barra promocional encima del contenido sin espacio reservado,
• Cambio de fuente o de peso de fuente sin preload, provocando “saltos” de texto,
• Uso de animaciones CSS no controladas (ej.: efecto de slide o fade-in que redibuja la página).

📌 Riesgos directos en test A/B:

• Pérdida de conversiones en móvil (donde los saltos visuales se amplifican),
• Resultados estadísticamente significativos pero falsos,
• Caída del CVR sin explicación aparente,
• Rechazo de la variación por malas razones.

✅ Buenas prácticas de CRO para evitar impactar el CLS:

1. Prever el espacio reservado para cada bloque añadido en una variación (ej.: reservar la altura de una imagen con CSS aspect-ratio o clases placeholder),
2. Evitar la inyección tardía de contenido con JavaScript (preferir las inserciones del lado del servidor o lo antes posible del lado del cliente),
3. Probar todas las variaciones con Lighthouse o PageSpeed Insights antes del despliegue para verificar el puntaje CLS,
4. Integrar los scripts de A/B test directamente en el código (head) para evitar el flickering,
5. Medir los Core Web Vitals en vivo en cada variación con una herramienta como Web Vitals Extension, SpeedCurve, Datadog RUM o BigQuery + GA4.