¿Qué es el Cumulative Layout Shift (CLS) y cómo corregirlo?

¿Qué es el Cumulative Layout Shift (CLS)?

El Cumulative Layout Shift (CLS) representa la "estabilidad visual" dentro de los Core Web Vitals. El CLS mide cómo se mueve la página mientras el contenido se renderiza o aparece contenido nuevo. Te das cuenta cuando pierdes la línea en el artículo que empezabas a leer, o cuando haces clic en el botón equivocado porque se movió bajo el dedo. A veces lo llaman "content layout shift", pero el nombre de la métrica es Cumulative Layout Shift.

¿Qué es una buena puntuación de Cumulative Layout Shift (CLS)?

Un buen CLS está entre 0 y 0,1. Entre 0,1 y 0,25 necesita mejorar, y cualquier valor por encima de 0,25 se considera deficiente. Para aprobar los Core Web Vitals en Cumulative Layout Shift, al menos el 75% de las visitas a la página necesita una puntuación de CLS "buena". Ese es el p75 de tu field data, midiendo móvil y escritorio por separado. El CLS no tiene unidad: es una puntuación, mientras que el LCP y el INP son tiempos.

El informe de Core Web Vitals en Google Search Console agrupa las URL afectadas según el problema. "Problema de CLS: más de 0,1 (móvil)" significa que necesita mejorar, "Problema de CLS: más de 0,25 (ordenador)" significa deficiente, y ambos umbrales existen para cada dispositivo. Search Console calcula la media del field data en una ventana móvil. Por eso un fix no pone el informe en verde el mismo día del deploy: durante semanas, parte de lo que muestra sigue perteneciendo al sitio anterior.

Cuánto te cuesta un layout shift

Una página que da saltos parece rota, aunque todo funcione.

• Los visitantes y tu marca: Un layout shift interrumpe lo que el visitante estaba haciendo. Pierde la línea que leía o pulsa el enlace equivocado, y algunos se rinden y se van. Además, un sitio que no para de moverse parece mal construido, y eso repercute en la empresa que hay detrás.
• Accesibilidad: Los layout shifts afectan con más fuerza cuando solo ves una parte de la página, por ejemplo al hacer zoom o usar una lupa de pantalla. Un solo shift puede empujar fuera de la vista el texto que estabas leyendo.
• SEO y ranking de búsqueda: Los sistemas de ranking de Google utilizan los Core Web Vitals, y el CLS es uno de ellos. Es un factor pequeño. Google afirma que muestra primero el contenido más relevante, y una buena experiencia de página ayuda cuando varias páginas tienen una relevancia similar.

¿Cómo se mide el CLS?

Los navegadores reportan los layout shifts mediante la Layout Instability API. Pega esto en la consola y se registrará cada shift:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Cada entrada tiene un value, que es la puntuación de ese shift, y una lista sources con los elementos que se movieron. Los shifts que ocurren justo después de un clic tienen hadRecentInput establecido en true. Se registran aquí, pero no cuentan para el CLS.

Cómo se calcula el CLS

Cada layout shift tiene su propia puntuación:

layout shift score = impact fraction * distance fraction

La fracción de impacto es qué parte del viewport tocan los elementos que se mueven, teniendo en cuenta dónde estaban antes del shift y dónde terminaron. La fracción de distancia es cuánto se movieron, como proporción de la dimensión mayor del viewport (en un móvil, la altura).

Por ejemplo, un elemento que cubre la mitad del viewport y se desplaza hacia abajo un 25% de la altura del viewport. Entre el antes y el después cubre el 75% del viewport. Eso da una fracción de impacto de 0,75 y una fracción de distancia de 0,25, por lo que el shift puntúa 0,75 * 0,25 = 0,1875. Un solo shift así ya supera el 0,1 por sí solo. El CLS de la página suma estas puntuaciones por ventana de sesión, como se explica más abajo.

Layout shifts esperados frente a inesperados

Cuando haces clic en un enlace de "cargar más elementos", esperas que aparezcan elementos nuevos y que la página se mueva. Por eso solo los layout shifts inesperados cuentan para el CLS. Cualquier shift dentro de los 500 milisegundos posteriores a un clic, tap o pulsación de tecla queda fuera del cálculo; un menú desplegable que se abre al hacer clic no te cuesta nada. Hacer scroll no cuenta como interacción; más abajo lo explicamos.

Sesiones de layout shifts

Cuando se introdujo el CLS, sumaba cada shift a lo largo de toda la vida de la página. Las páginas que permanecían abiertas mucho tiempo, como los scrolls infinitos y las single-page apps, acumulaban puntuación sin parar. Desde junio de 2021 el CLS se calcula en sesiones. Cada sesión dura como máximo 5 segundos y termina tras un intervalo de 1 segundo sin layout shifts. La sesión con la mayor puntuación de CLS se convierte en el CLS final.

Si la primera sesión suma 0,095, la siguiente 0,15 y la última 0, el CLS final será el más alto de los tres: 0,15.

Causas habituales de CLS

Todos los layout shifts funcionan igual. Después de renderizar la página, un elemento cambia de tamaño o de posición, y todo lo que viene detrás en el layout se desplaza. Estos son los motivos habituales:

Imágenes, vídeos e iframes sin dimensiones

El contenido multimedia sin dimensiones es una de las causas más frecuentes de CLS. El navegador solo conoce el tamaño de una imagen cuando llegan los primeros bytes del archivo. Hasta entonces, sin width y height (o un aspect-ratio en CSS), no reserva espacio y la imagen no tiene altura. Cuando carga, todo lo que está por debajo se desplaza hacia abajo.

Cómo las imágenes y el contenido multimedia causan layout shifts cubre imágenes, vídeos e iframes sin dimensiones, la trampa del width: auto en CSS, la dirección de arte, los desajustes en imágenes responsive, el lazy loading y los placeholders.

Intercambio de fuentes web

Mientras se descarga la fuente web, la página renderiza su texto con una fuente de fallback. Cuando llega la fuente web, el texto hace reflow. Al tener diferentes anchos de letra y alturas de línea, cambian los saltos de línea y se mueve cada bloque debajo de ese párrafo.

La auditoría de Lighthouse "Ensure text remains visible during webfont load" te empuja a usar font-display: swap. Para el CLS eso no soluciona nada por sí solo: el texto aparece antes con la fuente de fallback, pero el swap sigue moviéndolo. Lo que lo soluciona es un fallback que ocupe el mismo espacio, mediante anulaciones de métricas en @font-face como size-adjust y ascent-override. Después, entrega la fuente antes alojándola en tu propio servidor y haciendo preload de las fuentes críticas. En la guía para identificar y corregir problemas tienes el código.

Animaciones y transiciones CSS

Si animas top, left, width o height, el navegador recalcula el layout en cada frame. Cada uno de esos frames puede ser un layout shift. transform y opacity nunca disparan el layout, así que mueve los elementos con ellos. En Layout shift causado por transiciones CSS tienes el fix paso a paso.

Anuncios, embeds y contenido inyectado dinámicamente

Los anuncios cargan tarde y empujan el contenido hacia abajo. Un banner de cookies superpuesto a la página no desplaza nada, pero uno insertado en la parte superior empuja toda la página hacia abajo. Las peticiones AJAX hacen lo mismo cuando inyectan contenido sin reservar espacio. En todos los casos llega a la página algo que el navegador no conocía al calcular el layout. Reserva el espacio de antemano, por ejemplo con min-height en el contenedor. Para embeds de terceros como YouTube y Google Maps, el patrón facade elimina el CLS por completo.

Layout shifts provocados por scroll

Un test de carga de página en Lighthouse no hace scroll, por lo que no detectará esta causa de CLS. Las cabeceras que se ocultan al hacer scroll, los efectos parallax y las barras de navegación que se encogen suelen animar top o height. El scroll no es una interacción que excluya shifts en la especificación de Layout Instability, así que cada layout shift que provoca cuenta para el CLS. Usa transform: translateY() para cualquier elemento que se mueva al hacer scroll. Cómo las animaciones provocadas por scroll causan CLS tiene todos los detalles.

Cómo detectar y corregir problemas de CLS

Empieza con el field data. Un test de lab data solo ve los primeros segundos de la carga de la página, mientras que los visitantes hacen scroll, esperan a los anuncios y siguen leyendo. Revisa el p75 del CLS en móvil y escritorio por separado: en CLS, el escritorio suele ser el peor de los dos. Google Search Console muestra qué grupos de páginas fallan. Una herramienta de RUM como CoreDash también registra qué elemento se movió, para que veas si es la imagen de producto en una plantilla o el bloque de anuncios en otra. Fíjate también en la tendencia. Un salto repentino suele indicar que un deploy añadió algo, como un nuevo banner o un bloque de anuncios.

Luego reprodúcelo en Chrome DevTools o con la extensión Core Web Vitals Visualizer y averigua qué lo hace moverse. El diagnóstico paso a paso, los recorridos por las herramientas, los fixes de código para cada causa y una checklist de soluciones rápidas están en Cómo detectar y corregir problemas de Cumulative Layout Shift (CLS).

Caso de estudio: test A/B de Core Web Vitals en Rakuten 24

Rakuten 24, una tienda online japonesa, optimizó una landing page de alto tráfico para los Core Web Vitals. La compararon con la versión original durante un mes, con un 50% del tráfico en cada versión. Para el CLS, reservaron espacio para las imágenes con aspect-ratio en CSS y para los elementos con lazy loading mediante min-height. El CLS de la página optimizada fue un 92,72% más bajo. También terminó de cargar 0,4 segundos antes en su test de carga móvil, con mejores valores de FCP y TTFB. En comparación con la versión original, la página optimizada obtuvo:

• Un 53,37% más de ingresos por visitante
• Una tasa de conversión un 33,13% superior
• Un valor medio del pedido un 15,20% más alto
• Una tasa de salida un 35,12% menor

El CLS fue la mayor mejora del test, pero el tiempo de carga, el FCP y el TTFB también mejoraron. Por tanto, estos resultados corresponden a la optimización en su conjunto. No los cites como el valor del CLS por sí solo.

Qué muestran los datos reales de CLS

En el Chrome UX Report de agosto de 2026, el 81,5% de los orígenes tenía un buen CLS, frente al 80,1% de agosto de 2025.

En el propio corewebvitals.io, CoreDash mide el CLS como el Core Web Vital con mejor rendimiento. Del total de cargas de página, el 92,8% obtiene una puntuación "buena", casi sin diferencia entre escritorio (92,8% bueno) y móvil (92,7% bueno). Ambos tienen un p75 de 0, por lo que al menos tres cuartas partes de las cargas no tuvieron ningún layout shift.

En toda la web, el CLS es mejor en móvil que en escritorio. Ocurre justo lo contrario que con el LCP y el INP. El Web Almanac de 2025 muestra las cifras, junto con la frecuencia de las causas anteriores:

• El 81% de los sitios móviles y el 72% de los de escritorio tienen un buen CLS. Alrededor del 9% en móvil y del 10% en escritorio son deficientes.
• El 62% de las páginas móviles tiene al menos una imagen sin dimensiones explícitas, frente al 66% en 2024.
• El 40% de las páginas móviles (44% en escritorio) incluye animaciones no compuestas.
• El 87% de las páginas móviles usa al menos una fuente web, y alrededor del 12% precarga alguna (capítulo de fuentes).

Guías relacionadas

Estas guías profundizan en cómo detectar y corregir el CLS:

• Cómo detectar y corregir problemas de CLS: diagnóstico paso a paso con recorridos por las herramientas, fixes de código para cada causa y una checklist de soluciones rápidas.
• Cómo las imágenes y el contenido multimedia causan layout shifts: CLS provocado por imágenes, vídeos e iframes sin dimensiones, dirección de arte, imágenes responsive, lazy loading y placeholders.
• Cómo corregir layout shifts causados por imágenes con tamaño automático: añade dimensiones adecuadas a las imágenes y a los contenedores responsive.
• Cómo corregir layout shifts causados por transiciones CSS: detecta animaciones CSS que provocan layout y sustitúyelas por alternativas compuestas.
• Animaciones provocadas por scroll y CLS: la causa de CLS que pasa por alto un test de carga en Lighthouse, y cómo solucionarla.
• Alojar Google Fonts en tu propio servidor: reduce el CLS en la carga de fuentes alojándolas tú mismo con el font-display adecuado y preloading.
• Asegurar que el texto permanezca visible durante la carga de fuentes web: font-display y anulaciones de métricas tipográficas contra los layout shifts por intercambio de fuentes.
• Cómo crear un widget de chat con Core Web Vitals perfectos: un caso de estudio sobre cómo integrar un widget de terceros sin regresiones en CLS, INP o LCP.

La visión general de los Core Web Vitals abarca las tres métricas, y la checklist de Core Web Vitals te ayuda a auditar tu sitio.