Si alguna vez intentaste tocar un botón en una página móvil y de pronto el botón saltó porque cargó un banner arriba, acabas de experimentar lo que mide el CLS. Es la métrica más «humana» de Core Web Vitals: cuantifica cuánto se mueve el contenido de la pantalla sin que el usuario haga nada. Y aunque suena trivial, es la métrica que más rápido se arregla cuando se sabe dónde mirar. Esta guía cubre las 8 causas reales que vemos en auditorías y cómo eliminarlas.
Qué mide el CLS exactamente
CLS (Cumulative Layout Shift) calcula la suma de todos los desplazamientos inesperados de elementos visibles durante la sesión de carga. Cada vez que un elemento ya pintado cambia de posición (no por una acción del usuario), se acumula puntaje. El número final es una proporción: cuánta superficie se movió multiplicado por cuánto se movió.
Los umbrales de Google son:
- Bueno: ≤ 0.1
- Necesita mejorar: entre 0.1 y 0.25
- Pobre: > 0.25
A diferencia de LCP e INP, CLS no se mide en tiempo: es un número adimensional. Lo importante es entender que 0.1 es bastante estricto. Un solo banner que aparece tarde y empuja el contenido principal puede llevarte a 0.3 sin esfuerzo.
Por qué Google le da tanto peso
CLS es la métrica de Core Web Vitals que mejor correlaciona con tasa de error en clics (mistaps). En móvil, donde los pulgares ya tienen poco margen, un layout que se mueve es una experiencia frustrante que dispara rebotes. Para Google es una señal directa de mala calidad: si el sitio «salta», el usuario percibe un producto inferior, indepedientemente del contenido.
Otra particularidad: CLS se mide durante toda la sesión de carga, no solo el momento inicial. Si tu página tiene contenido que aparece tarde (anuncios lazy-loaded, contenido inyectado por terceros, banners pop-up), todo eso cuenta.
Las 8 causas más comunes de un CLS alto
1. Imágenes sin atributos width y height
La causa #1 absoluta. Sin dimensiones declaradas, el navegador reserva 0 espacio y cuando la imagen carga, empuja todo el contenido hacia abajo. Solución: declarar width y height en HTML siempre, incluso en imágenes responsive (el navegador moderno usa la proporción para reservar espacio aunque el tamaño final sea distinto).
2. Fuentes web que cambian de tamaño al cargar
Si tu sitio usa una fuente web y el navegador renderiza primero con una fuente fallback, cuando la fuente real carga el texto cambia de métricas y todo se mueve. Soluciones: font-display: optional o swap con size-adjust para igualar métricas entre fuente fallback y fuente final.
3. Banners de cookies sin reserva de espacio
Banner de cookies que aparece en la parte superior 800 ms después de la carga inicial es una causa clásica. Solución: reservar el espacio del banner desde el HTML inicial (con CSS min-height o pre-renderizar el contenedor vacío).
4. Anuncios que se inyectan sin contenedor reservado
Anuncios de AdSense, anuncios programáticos o widgets de afiliación que aparecen mid-content sin que se haya reservado un slot fijo. Solución: contenedores con dimensiones específicas declaradas en CSS.
5. Contenido above-the-fold cargado vía JavaScript
Si tu hero o tu menú principal aparece después de que el JS se ejecuta, vas a tener un salto visible cada visita. Solución: renderizar críticos del lado del servidor (SSR) o entregar HTML estático con el contenido del fold.
6. Iframes sin dimensiones
YouTube embebido, Google Maps, formularios de Typeform o Calendly. Todos suelen cargarse sin dimensiones explícitas y empujan contenido. Solución: declarar width y height o usar un wrapper con aspect-ratio CSS.
7. Animaciones que cambian el layout
Animar propiedades como height, top, left o margin reorganiza el documento entero. Solución: usar siempre transform y opacity para animaciones, que se renderizan en una capa separada y no causan reflow.
8. Pop-ups y modales que empujan contenido
Si tu pop-up se inserta como un elemento dentro del flujo del DOM, mueve todo lo que tenga abajo. Solución: posicionarlos como fixed o absolute con overlay, nunca como elementos en el flujo normal.
Cómo diagnosticar de dónde viene tu CLS
PageSpeed Insights te da el dato de CrUX, pero no te dice qué elemento es el culpable. Para eso:
- Chrome DevTools, pestaña Performance: graba la carga de la página y busca las «layout shifts» marcadas en rojo. Cada una indica qué elemento se movió y cuánto.
- Web Vitals Extension: muestra los shifts en tiempo real mientras navegas.
- Lighthouse: en el reporte, sección «Avoid large layout shifts» lista los elementos problemáticos.
El método práctico: abre tu sitio con DevTools, ve a Performance, graba 5 segundos desde la carga, y revisa los shifts ordenados por puntaje. El de mayor puntaje es por donde empezar.
La regla de oro para evitar CLS
Todo elemento que vaya a aparecer en la página debe tener su espacio reservado desde el primer paint. Imágenes con dimensiones, iframes con dimensiones, banners con min-height, anuncios con contenedores fijos, fuentes con size-adjust. Si interiorizas esta regla, el 90% de los problemas de CLS desaparecen.
CLS y mobile-first
Casi todos los problemas de CLS son más graves en móvil que en desktop, simplemente porque el viewport es más pequeño y un mismo salto representa mayor porcentaje de la pantalla. Cuando audites CLS, hazlo siempre en simulación de móvil o con un dispositivo real.
Para completar el ciclo de auditoría de Core Web Vitals, revisa también cómo optimizar LCP y cómo mejorar INP. Las tres métricas se evalúan en conjunto: tener dos en verde y una en rojo no te aprueba.
CLS es, de las tres Core Web Vitals, la que más rápido devuelve resultados visibles cuando se trabaja. Es también la que más directamente mejora la experiencia subjetiva del usuario, lo que se traduce en menor tasa de rebote y mejor percepción
Visita https://seoinspector.pro/
Redactor SEO y experto en marketing digital con más de 8 años de experiencia tanto en publicidad pagada como crecimiento orgánico.