Cumulative Layout Shift mide cuánto se mueve de forma inesperada el contenido visible de una página mientras carga y mientras alguien la usa. Un buen CLS es 0,1 o menos en el percentil 75 de datos reales y, a diferencia de los otros dos Core Web Vitals, casi todos los suspensos vienen de un puñado de causas predecibles que puedes arreglar en una tarde. Esta guía cubre cómo se calcula realmente el CLS, los cinco patrones que están detrás de casi todos los fallos y un proceso de seis pasos para eliminarlos.
El CLS es el Core Web Vital que más webs aprueban, y precisamente por eso suspenderlo hace tanto daño. Si tu competencia lo pasa y tú no, estás regalando un criterio de desempate en un problema que se resuelve mayoritariamente con CSS. En mi experiencia auditando sitios, un CLS en rojo casi nunca es un problema de ingeniería difícil: es un problema de gobernanza, donde nadie es dueño de los scripts de terceros y los widgets inyectados que provocan los saltos.
Qué mide realmente el Cumulative Layout Shift
El CLS no es un recuento de saltos. Es una puntuación construida a partir de dos fracciones que se multiplican, según la documentación de Google en web.dev sobre CLS:
- Fracción de impacto — la parte del viewport afectada por el elemento que se mueve, combinando dónde estaba y dónde acabó.
- Fracción de distancia — la mayor distancia recorrida por un elemento inestable, como proporción de la dimensión más grande del viewport.
Multiplica ambas y tienes la puntuación de ese desplazamiento. Un banner que ocupa la mitad del viewport y empuja todo hacia abajo un cuarto de pantalla puntúa 0,5 × 0,25 = 0,125. Un solo salto y ya has suspendido.
Esa fórmula explica algo que a los equipos les resulta contraintuitivo: muchísimos saltos diminutos suelen hacer menos daño que uno grande. Perseguir cada desplazamiento de 0,001 en DevTools es tiempo perdido. Busca el elemento que mueve muchos píxeles a mucha distancia.
La regla de la ventana de sesión
Al principio el CLS era un acumulado de toda la vida de la página, lo que castigaba injustamente a las sesiones largas. Google lo cambió en junio de 2021 para usar ventanas de sesión: los desplazamientos se agrupan en ventanas de 5 segundos como máximo, y cualquier hueco de más de 1 segundo abre una ventana nueva. Tu CLS reportado es el de la ventana peor, no la suma de todas.
Esto tiene una consecuencia práctica: un único elemento mal comportado en una sola ráfaga decide tu puntuación. Y no puedes “diluir” un salto malo con una sesión larga y estable después.
Qué queda excluido
Hay dos exclusiones que te salvan de falsos positivos. Los desplazamientos que ocurren dentro de los 500 milisegundos siguientes a una interacción del usuario —clic, toque o tecla— no cuentan, porque el usuario ha pedido ese cambio. Los desplazamientos provocados por el scroll también se excluyen. Todo lo demás cuenta, incluido el banner de cookies que aparece a los ocho segundos de entrar.
Por qué la mayoría de problemas de CLS son invisibles en laboratorio
Aquí es donde los equipos pierden semanas. Lighthouse da un CLS verde, todo el mundo lo da por bueno, y Google Search Console sigue marcando ese grupo de URLs como suspenso. Las dos herramientas tienen razón: están midiendo cosas distintas.
Lighthouse ejecuta una única carga sintética en un entorno controlado. No hace scroll, no hace clic, no espera a un módulo con lazy loading tres pantallas más abajo, y muchas veces ni siquiera dispara el banner de consentimiento porque no tiene estado previo de cookies. Los usuarios reales hacen todo eso.
Los datos de campo vienen del Chrome UX Report, que agrega mediciones de usuarios reales de Chrome que han dado su consentimiento. Esos son los datos que Google usa para las señales de experiencia de página, y los que ves en el informe de Core Web Vitals de Search Console y en la parte superior de PageSpeed Insights.
La regla: diagnostica en laboratorio, decide con datos de campo. Usa Lighthouse y DevTools para encontrar el mecanismo del salto. Usa los datos de CrUX para decidir si merece la pena arreglarlo y si tu arreglo funcionó. Nunca al revés.
Los datos de campo además van con retraso. El Chrome UX Report usa una ventana móvil de 28 días, así que un arreglo desplegado hoy no se reflejará del todo en Search Console hasta dentro de cuatro semanas. Cuéntalo en tus informes o te preguntarán por qué no ha cambiado nada.
Las cinco causas de cumulative layout shift que veo en casi todas las webs
Tras suficientes auditorías, los mismos cinco patrones explican la inmensa mayoría de los problemas de desplazamiento. Trabájalos en este orden.
1. Imágenes y vídeos sin dimensiones. El navegador no puede reservar espacio para un recurso cuyo tamaño desconoce, así que maqueta la página sin él y rehace el layout cuando llega. Poner los atributos width y height en el elemento permite al navegador calcular la relación de aspecto y guardar el hueco. Los navegadores modernos derivan aspect-ratio automáticamente de esos atributos, así que este único arreglo elimina una clase entera de saltos.
2. Publicidad, embeds e iframes. Los slots de terceros son los peores porque sus dimensiones llegan desde un servidor remoto después de que tu página ya haya renderizado. Reserva el mayor tamaño plausible con un contenedor min-height y nunca colapses a cero un slot sin rellenar a mitad de sesión.
3. Fuentes web. Cuando se sustituye la fuente de respaldo por la fuente web y sus métricas no coinciden, cada línea de texto se recoloca. Son desplazamientos anchos y poco profundos: fracción de distancia baja, pero fracción de impacto altísima, porque el área afectada es casi todo el viewport.
4. Contenido inyectado dinámicamente. Banners de cookies —obligatorios en toda web europea por el RGPD, y de ahí que este sea el problema número uno que veo en España—, barras de promoción, widgets de chat, bloques de personalización y variantes de tests A/B que insertan DOM por encima del contenido existente. Si aparece arriba del documento después del primer pintado, desplaza todo lo que hay debajo.
5. Animaciones sobre propiedades que disparan layout. Animar top, left, width, height o margin obliga al navegador a recalcular el layout en cada fotograma. Animar transform y opacity no, porque se ejecutan en el compositor. Es el arreglo más barato de la lista y además ayuda a la capacidad de respuesta.
Un proceso de seis pasos para arreglar el cumulative layout shift
Este es el orden que uso en proyectos de cliente. Está pensado para que los arreglos más baratos y de mayor rendimiento vayan primero.
Paso 1 — Consigue una línea base de campo por plantilla. Abre el informe de Core Web Vitals en Search Console y anota los grupos de URL que suspenden. No trabajes URL por URL. Agrupa por plantilla —ficha de producto, categoría, artículo de blog, home— porque el arreglo se aplicará a toda la plantilla.
Paso 2 — Reproduce en las condiciones correctas. En Chrome DevTools, abre el panel Performance, activa Layout Shift Regions en el cajón Rendering, limita la red a 4G lenta y la CPU a 4×, y graba una sesión completa incluyendo scroll más allá del pliegue. Borra las cookies antes para que salte el banner de consentimiento. La mayoría de equipos se salta esto y nunca llega a ver el desplazamiento que realmente les está suspendiendo.
Paso 3 — Pon dimensiones en todo. Añade width y height a cada <img> y <video>, y define un aspect-ratio en cualquier contenedor cuyo contenido cargue de forma asíncrona. Es el cambio de mayor rendimiento en casi todas las webs.
Paso 4 — Reserva espacio para los terceros. Cada slot publicitario, embed, widget de reseñas y lanzador de chat recibe un contenedor de altura fija en el CSS antes de que su script se ejecute. Si de verdad no puedes predecir la altura, renderiza el widget por debajo del pliegue o dentro de una capa con posición fija que no participe en el flujo del documento.
Paso 5 — Iguala las métricas de tus fuentes. Precarga el archivo de la fuente principal, usa font-display: swap y define un @font-face de respaldo con size-adjust, ascent-override y descent-override ajustados para que ocupe el mismo espacio vertical. Herramientas como Fontaine o la optimización de fuentes de Next.js generan esos valores automáticamente.
Paso 6 — Saca el contenido inyectado del flujo. Los banners de consentimiento y las barras promocionales deberían renderizarse como capas fijas, o venir ya en el HTML inicial desde servidor para que existan antes del primer pintado. Nunca los inyectes con JavaScript al principio del body después de la carga.
Después espera 28 días y vuelve a mirar los datos de campo. Ni un día antes.
Herramientas que sirven, y las que te despistan
Usa estas:
- Informe de Core Web Vitals de Search Console — datos de campo agrupados por plantilla. Tu fuente de verdad sobre si existe un problema.
- PageSpeed Insights — datos de campo más una prueba de laboratorio para una URL concreta, útil para confirmar una página específica.
- Panel Performance de Chrome DevTools con Layout Shift Regions — la única forma fiable de ver qué elemento se ha movido.
- La librería JavaScript
web-vitals— atribuye cada desplazamiento a un elemento concreto del DOM en tu propio monitoreo de usuarios reales. Es lo más parecido a un depurador de CLS en producción.
Ten cuidado con estas:
- La puntuación de Lighthouse en aislado — un CLS verde en laboratorio no demuestra casi nada, por todo lo anterior.
- Herramientas de “velocidad web” de terceros — la mayoría ejecuta una sola carga de escritorio desde una ubicación y devuelve un número sin relación con tus datos de CrUX.
- Repetir ejecuciones de PageSpeed — el CLS de laboratorio varía entre ejecuciones. Perseguir esa varianza no es optimizar.
Para ver cómo encaja todo esto en conjunto, mi proceso de auditoría de SEO técnico cubre los Core Web Vitals junto al rastreo, la indexación y el renderizado, porque los arreglos de rendimiento rara vez rinden de forma aislada.
Dónde encaja el CLS en las prioridades de SEO técnico en 2026
Voy a ser directo sobre el impacto en posicionamiento. Los Core Web Vitals forman parte de las señales de experiencia de página, y la propia documentación de Google Search Central es explícita en que una gran experiencia de página no compensa la falta de contenido relevante. Arreglar el cumulative layout shift no va a rescatar una página que no merece posicionar.
Lo que sí hace es quitar de en medio un criterio de desempate que juega en tu contra y, más importante, dejar de costarte dinero. Un desplazamiento que mueve un botón justo debajo del pulgar del usuario en pleno toque es un clic equivocado, un formulario abandonado o un producto incorrecto en el carrito. Ese impacto es inmediato y medible en tu propia analítica, a diferencia del efecto en rankings.
Mi orden de prioridad cuando una web suspende varios Core Web Vitals: arregla primero el CLS, porque es el más barato y el más autocontenido. Después el LCP, porque exige trabajo de infraestructura y de assets. Después el INP, porque normalmente implica replantear cuánto JavaScript envías. Cuando los tres aprueben en campo, deja de optimizar rendimiento y mueve el presupuesto a contenido y enlaces, que es donde están las ganancias reales de posicionamiento.
Esa secuencia importa más que cualquier arreglo concreto. He visto equipos gastar dos trimestres en recortar 200 ms de LCP mientras sus páginas de categoría no tenían enlazado interno ni contenido decente. El Cumulative Layout Shift merece una tarde de trabajo enfocado y un hueco en tu checklist de despliegue, no una línea de trabajo permanente. Si quieres una segunda opinión sobre dónde deberían estar tus prioridades, para eso está un consultor SEO independiente.
Preguntas frecuentes
¿Qué es un buen valor de CLS?
Un buen Cumulative Layout Shift es 0,1 o menos en el percentil 75 de tus datos de campo, medido por separado en móvil y escritorio. Entre 0,1 y 0,25 necesita mejora, y por encima de 0,25 es malo. Como Google usa el percentil 75, una cuarta parte de tus visitas reales puede ser peor que el valor que ves y aun así apruebas.
¿Es el CLS un factor de posicionamiento?
De forma indirecta, sí. El CLS es uno de los tres Core Web Vitals, y estos alimentan las señales de experiencia de página que Google usa como desempate entre páginas de relevancia similar. Un CLS malo no hunde por sí solo un buen contenido, pero te cuesta las decisiones ajustadas y perjudica la conversión, que es la mejor razón para arreglarlo.
¿Por qué mi CLS es distinto en PageSpeed Insights y en Lighthouse?
Porque miden cosas distintas. Lighthouse hace una sola carga sintética y nunca hace scroll ni clic, así que se pierde los saltos del lazy loading, del banner de cookies y de los scripts tardíos. PageSpeed Insights además muestra datos de campo del Chrome UX Report. Fíate de los datos de campo.
¿Cuentan los desplazamientos que ocurren tras un clic?
No, si suceden dentro de los 500 milisegundos posteriores a la interacción. Google los excluye porque los ha provocado el usuario. Los saltos por scroll también quedan fuera. Todo lo demás cuenta, incluido un banner que aparece bien entrada la sesión.
¿Cuánto tarda un arreglo de CLS en verse en Search Console?
El Chrome UX Report usa una ventana móvil de 28 días, así que cuenta con unas cuatro semanas hasta que un despliegue se refleje del todo en el informe de Core Web Vitals. Puedes confirmarlo antes en tu propio monitoreo de usuarios reales con la librería web-vitals, y por eso recomiendo tenerla instalada antes de empezar.
