Cambio de diseño acumulado (CLS)

TL;DR — Cumulative Layout Shift (CLS) mide cuánto contenido de una página se mueve por sí solo mientras intentas leer o tocarla: una imagen que carga tarde y empuja el texto, o un botón que salta justo cuando vas a pulsarlo. Se puntúa desde 0 y 0,1 o menos es bueno. La mayoría de los cambios procede de elementos que no reservaron espacio antes de cargarse.

Qué es CLS

Lo has vivido aunque nunca hayas oído el término. Estás leyendo un artículo, termina de cargar un anuncio o una imagen por encima de tu posición y, de repente, toda la página salta hacia abajo. O vas a tocar «Cancel» y aparece un banner, de modo que el toque cae sobre «Confirm». Ese movimiento inesperado es un cambio de diseño, y Cumulative Layout Shift es la forma que tiene Google de convertir su gravedad en un número.

Es una de las tres Core Web Vitals, el trío de métricas de experiencia de página que Google sigue, junto con Largest Contentful Paint (cuánto tarda en cargar el contenido principal) e Interaction to Next Paint (con qué rapidez responde la página cuando tocas). CLS trata de la estabilidad visual: ¿la página se queda quieta?

Cómo funciona la puntuación (a grandes rasgos)

CLS es una puntuación, no un tiempo. Un CLS de 0,05 no significa 50 milisegundos de nada: es un número sin unidad. Cuanto mayor sea la parte de la pantalla que se mueve y cuanto más lejos se desplace, mayor —y peor— será la puntuación.

Los objetivos son sencillos:

• 0,1 o menos — bueno.
• De 0,1 a 0,25 — necesita mejoras.
• Más de 0,25 — malo.

Un detalle útil: los cambios que ocurren justo después de que tú hagas algo —tocar un botón o abrir un menú— no penalizan la página, porque los provocaste y los esperas. Solo cuenta el movimiento inesperado.

Por qué ocurre (y cómo arreglarlo)

Casi todos los cambios de diseño se reducen a lo mismo: algo cargó y ocupó un espacio que la página no había reservado. Los casos principales son:

• Imágenes y vídeos sin dimensiones. El navegador no sabe qué altura tendrá la imagen hasta que llega, así que el texto inferior baja al cargarse. La solución: asigna siempre a las imágenes width y height (o un CSS aspect-ratio) para que el navegador reserve el hueco.
• Anuncios, incrustaciones e iframes. El mismo problema: reserva espacio.
• Fuentes web. Cuando una fuente personalizada sustituye a la alternativa, el texto puede redistribuirse.
• Elementos emergentes. Banners de cookies, cuadros de «también te puede interesar» y cualquier contenido inyectado por encima de lo que ya estás mirando.

La regla mental es: si algo va a aparecer después, deja un hueco del tamaño correcto para que nada más tenga que moverse cuando aparezca.

¿Quieres la fórmula real, la regla de la «ventana de sesión», por qué no coinciden los números de CLS de laboratorio y de campo y la lista completa de causas y soluciones? Cambia a la pestaña Avanzado.

TL;DR — CLS es la Core Web Vital de la estabilidad visual. Cada cambio obtiene impact fraction × distance fraction; la métrica es la ventana de sesión más grande de cambios (≤ 1 s entre cambios y ≤ 5 s de ventana), no la suma de toda la vida de la página, que era la definición anterior a junio de 2021. Bueno es ≤ 0,1, necesita mejoras hasta 0,25 y es malo por encima de 0,25, en el percentil 75 de los datos de campo. Solo cuentan los cambios visibles en el viewport; los que ocurren dentro de 500 ms de una entrada discreta quedan excluidos, pero el desplazamiento no. Las causas son imágenes/vídeos/anuncios/iframes/incrustaciones sin tamaño, fuentes web y contenido inyectado sobre contenido existente; las soluciones son reservar espacio, font-display/size-adjust y animar solo con transform. La trampa: Lighthouse (laboratorio) suele leer casi 0 porque no interactúa con la página ni ejecuta todo su ciclo de vida; los datos de campo (CrUX) son los que Google mide realmente.

Qué mide CLS

La formulación de Google es: “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (traducción) «Cumulative Layout Shift (CLS) constituye una métrica estable de Core Web Vitals. Es una métrica importante y centrada en el usuario para medir la estabilidad visual porque ayuda a cuantificar con qué frecuencia los usuarios sufren cambios de diseño inesperados». La palabra clave es inesperado: contenido que se mueve solo, no porque el usuario haya hecho algo.

Forma parte del trío Core Web Vitals con Largest Contentful Paint (carga) e Interaction to Next Paint (capacidad de respuesta). LCP e INP se miden en milisegundos, pero CLS es la excepción: una puntuación de proporción sin unidad. Esto confunde constantemente. Un CLS de 0,05 no son 50 ms; no tiene unidad de tiempo.

La fórmula: impacto × distancia

Para cada cambio, Google lo define así:

layout shift score = impact fraction × distance fraction

• Fracción de impacto “measures how unstable elements impact the viewport area between two frames” (traducción) «mide cómo afectan los elementos inestables al área del viewport entre dos fotogramas»: el área visible combinada que ocupaban los elementos móviles antes y después, como proporción del viewport.
• Fracción de distancia “the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” (traducción) «es la mayor distancia horizontal o vertical que haya recorrido cualquier elemento inestable en el fotograma, dividida por la dimensión mayor del viewport (ancho o alto, la que sea mayor)».

Ambas dimensiones importan por separado. Un elemento pequeño que recorre casi toda la pantalla y uno grande que apenas se desplaza pueden obtener puntuaciones muy distintas. El ejemplo de web.dev: una fracción de impacto de 0.75 y una fracción de distancia de 0.25 producen un CLS de 0.1875.

Ventanas de sesión: la parte que casi todos entienden mal

Este es el hecho sobre CLS que más se afirma mal y el que más quiero que recuerdes. CLS no es la suma de todos los cambios durante la vida de la página. Antes lo era; eso cambió en junio de 2021.

Hoy: “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traducción) «CLS mide el mayor conjunto de puntuaciones de cambios de diseño correspondiente a cada cambio inesperado durante todo el ciclo de vida de una página». Un conjunto es una ventana de sesión: “one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” (traducción) «uno o más cambios individuales ocurren rápidamente, con menos de 1 segundo entre ellos y una duración total máxima de 5 segundos». CLS es la puntuación de la ventana más grande, no la suma ni la media.

¿Por qué cambió? La antigua definición que lo sumaba todo castigaba silenciosamente a las páginas de larga duración. Una SPA o un feed con desplazamiento infinito acumulaba más CLS solo por existir más tiempo, aunque cada cambio individual fuera pequeño y estuviera bien espaciado. El equipo de Chrome Speed Metrics pasó a una ventana de sesión máxima para no penalizar la duración y eligió el máximo en vez de la media para evitar el resultado absurdo de que arreglar un cambio secundario pequeño empeorara la puntuación. Cuando se desplegó el cambio, ningún origen obtuvo una puntuación peor, la mayoría no cambió y mejoró una parte de las páginas con interfaces lentas o desplazamiento infinito. Si lees un artículo antiguo que aún dice «suma de todos los cambios», está desactualizado.

Qué cuenta y qué no

Tres exclusiones determinan qué llega realmente a tu puntuación:

• Lo que está bajo el pliegue no cuenta. Solo se puntúan cambios de contenido visible en el viewport actual. Un cambio al final de una página larga que el usuario nunca alcanza no tiene impacto. En la práctica, arreglar cambios dentro del viewport casi siempre ofrece más retorno que perseguir cambios muy abajo.
• Los cambios iniciados por el usuario tienen una tolerancia de 500 ms. “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” (traducción) «Los cambios que ocurren dentro de los 500 milisegundos de una entrada del usuario tendrán activada la marca hadRecentInput, por lo que pueden excluirse de los cálculos». Google considera que los cambios “that occur in response to user interactions… are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” (traducción) «que ocurren como respuesta a interacciones del usuario… suelen estar bien, siempre que sucedan lo bastante cerca de la interacción para que la relación sea clara». Abrir un acordeón o expandir un menú es un movimiento esperado y se perdona.
• Pero desplazarse no da vía libre. La exclusión de 500 ms solo se aplica a eventos discretos: toque, clic o pulsación de tecla. Los gestos continuos (desplazamiento y zoom con dos dedos) no activan la ventana de exclusión. Si el contenido cambia mientras alguien se desplaza, sigue contando. Esta distinción aparece mal explicada en mucha documentación; respétala.

Umbrales y de dónde sale la puntuación

“To provide a good user experience, sites should strive to have a CLS score of 0.1 or less,” (traducción) «Para ofrecer una buena experiencia de usuario, los sitios deberían aspirar a una puntuación CLS de 0,1 o menos», medida en “the 75th percentile of page loads, segmented across mobile and desktop devices.” (traducción) «el percentil 75 de las cargas de página, segmentado entre dispositivos móviles y de escritorio». Las bandas completas son:

• Bueno: ≤ 0,1
• Necesita mejoras: 0,1 – 0,25
• Malo: > 0,25

La línea de 0,1 no es arbitraria. La investigación de usuarios de Google descubrió que “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” (traducción) «los niveles de cambio de 0,15 o superiores se percibían sistemáticamente como molestos, mientras que los de 0,1 o inferiores se notaban, pero no resultaban excesivamente molestos». Eligieron 0,1 en parte porque las incrustaciones de terceros (anuncios y redes sociales) provocan cambios con tanta frecuencia que un umbral más estricto sería poco práctico para la web real.

La parte del percentil 75 de los datos de campo es decisiva, y nos lleva a la mayor trampa de medición.

Laboratorio frente a campo: por qué no coinciden las cifras

Aquí es donde más gente se quema. Lighthouse y otras herramientas de laboratorio suelen mostrar un CLS cercano a 0,0 mientras los datos de campo —y Google— muestran algo mucho peor. La diferencia no significa que una herramienta mienta; es una cuestión de alcance. Una prueba de laboratorio es una carga única, breve y guionizada: no se desplaza, no hace clic y no permanece abierta, así que solo captura cambios de la carga inicial. Los datos de campo (CrUX) agregan visitas reales de muchos usuarios, dispositivos y navegaciones durante una ventana móvil, y CLS se define en todo el ciclo de vida de la página: apertura de menús, carga diferida al desplazarse, anuncios tardíos y cualquier duración de sesión. Una prueba breve de laboratorio no puede observar estructuralmente la mayor parte de eso.

La regla práctica es: usa los datos de laboratorio para depurar un cambio concreto y los de campo para conocer tu puntuación real. Google posiciona con datos de campo de Chrome User Experience Report (CrUX), que aparecen en PageSpeed Insights y Search Console. Si Lighthouse lee 0,0 pero PageSpeed Insights muestra 0,18, trata el dato de campo como el que representa a tus usuarios y reproduce después el cambio en el laboratorio interactuando como lo haría un visitante real. Hay dos diferencias de alcance más: la mayoría de herramientas, incluida Lighthouse, no propaga los cambios de diseño de un iframe a la puntuación del documento padre aunque CrUX pueda reflejarlos, y el RUM basado en Layout Instability API hereda ese punto ciego; por eso tu monitorización propia puede explicar peor un número de CrUX que parece más malo que tu atribución de primera parte.

Las causas más comunes

En orden aproximado de frecuencia según lo que veo:

1. Imágenes y vídeos sin dimensiones. Sin una altura reservada, todo lo que está debajo salta al cargar el contenido.
2. Anuncios, incrustaciones e iframes sin espacio reservado. Las redes publicitarias sirven tamaños dinámicos y las incrustaciones no anuncian su altura antes de cargar.
3. Contenido inyectado dinámicamente sobre contenido existente. Banners de cookies, barras de avisos, widgets «relacionados» y promociones tardías: todo lo que empuja lo que ya está en pantalla.
4. Fuentes web (FOIT/FOUT). Si la fuente personalizada sustituye a la alternativa y sus métricas difieren, el texto se redistribuye.
5. Animaciones de propiedades que activan el diseño. Animar top, left, margin, box-shadow o box-sizing obliga al navegador a recalcular el diseño en cada fotograma.

Las soluciones

Cada solución refleja su causa:

• Imágenes/vídeo: reserva el espacio. Define atributos width y height para que el navegador calcule la proporción y mantenga la caja; combínalos con img { height: auto; width: 100%; } para el comportamiento adaptable, o usa la propiedad CSS aspect-ratio. En la mayoría de los sitios es la corrección de CLS con mayor efecto.
• Anuncios/incrustaciones/iframes: reserva espacio también. Usa min-height o aspect-ratio en el contenedor. La guía de Publisher Tag de Google es tajante: “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (traducción) «Definir directamente una altura y una anchura fijas en el div del espacio publicitario es la forma más eficaz de hacerlo». En espacios de varios tamaños, reserva el del tamaño configurado más grande. Baja el contenido tardío para que cualquier cambio residual quede bajo el pliegue.
• Contenido dinámico: no lo insertes en el flujo. Reserva un marcador del tamaño final o superpón el contenido en vez de inyectarlo. Los esqueletos solo ayudan si coinciden exactamente con las dimensiones finales; incluso unos pocos píxeles de diferencia provocan otro cambio. Prefiere cargas activadas por el usuario («Cargar más») a inserciones sorpresa.
• Fuentes: iguala las métricas. font-display: optional es el único valor con un riesgo de CLS prácticamente cero; swap reduce el texto invisible, pero puede provocar un cambio al sustituirse. Mejor aún, usa las anulaciones CSS size-adjust, ascent-override, descent-override y line-gap-override para ajustar la fuente alternativa a la web. Precarga las fuentes críticas.
• Animaciones: solo transform. Anima con transform (translate, scale y rotate) en lugar de top/left/margin. Las animaciones basadas en transform se componen y no activan el diseño, así que no desplazan nada.

Cómo encaja CLS en el posicionamiento (mantén la proporción)

CLS es una entrada de la señal de experiencia de página de Google. Google dice que sus sistemas de posicionamiento usan Core Web Vitals, pero la documentación actual de Search no publica un peso exacto de CLS, una regla de desempate ni una garantía de posicionamiento. Trata cualquier mecanismo concreto —incluido «es un desempate»— como una aproximación de trabajo, no como un hecho documentado. Mi consejo constante para todo lo que escribo sobre Core Web Vitals es: entra en la banda «bueno» y sigue adelante. La mayoría de sitios no verá un aumento relevante de tráfico o negocio por bajar de 0,08 a 0,02, y una sola puntuación rara vez explica por sí misma un resultado de ingresos o conversiones. CLS es un requisito básico: hay que superar el umbral, pero no debe convertirse en el centro del programa SEO a costa de LCP, INP o, francamente, del contenido.

Dos notas operativas que evitan mucha confusión:

• CrUX lleva un retraso de unos 28 días. Es una ventana móvil de 28 días, así que una corrección publicada hoy tardará semanas en registrarse por completo en PageSpeed Insights o Search Console. No te alarmes si la cifra no cambia mañana.
• El elemento atribuido no suele ser la causa raíz. Layout Shift Attribution API indica qué elemento se movió, pero web.dev advierte que “it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (traducción) «es posible que esos elementos solo estén relacionados indirectamente con la “causa raíz” de la inestabilidad del diseño». El texto que salta suele ser la víctima de una imagen sin tamaño situada por encima que carga tarde: corrige la causa, no el síntoma. Trabaja con un bucle de marca de tiempo y disparador: anota cuándo empezó el cambio, revisa qué más cambió en esa ventana —una petición de red, una imagen o fuente, un redimensionamiento o una clase/estilo— y considera el nodo atribuido una pista, no una prueba, hasta asociarlo con el disparador.

Resumen de IA

Una versión condensada de la versión Advanced:

• CLS = estabilidad visual, la Core Web Vital del movimiento inesperado del contenido visible. Está junto a Largest Contentful Paint e Interaction to Next Paint.
• Es una puntuación sin unidad, no un tiempo. 0,05 es una proporción, no 50 ms.
• Fórmula por cambio: impact fraction × distance fraction: cuánto viewport se movió multiplicado por cuánto se desplazó, relativo a la dimensión mayor del viewport.
• La métrica es la mayor ventana de sesión (≤ 1 s entre cambios y ≤ 5 s en total), no la suma de toda la vida. Cambió en junio de 2021 para dejar de penalizar páginas de larga duración/SPA; se eligió el máximo sobre la media.
• Umbrales (percentil 75, datos de campo): Bueno ≤ 0,1 · Necesita mejoras ≤ 0,25 · Malo > 0,25.
• Exclusiones: los cambios bajo el pliegue no cuentan; los que ocurren dentro de 500 ms de una entrada discreta (toque/clic/tecla) se excluyen, pero el desplazamiento no está exento.
• Causas: imágenes/vídeo/anuncios/iframes/incrustaciones sin tamaño; contenido inyectado sobre contenido existente; fuentes web; animación de propiedades que activan el diseño.
• Soluciones: define width/height o aspect-ratio; reserva espacio para el contenido dinámico (los esqueletos deben coincidir exactamente); usa font-display + size-adjust; anima solo con transform.
• Laboratorio ≠ campo. Lighthouse suele leer casi 0 porque no interactúa ni ejecuta todo el ciclo; los datos de campo (CrUX/PageSpeed Insights) son los que Google usa para posicionar. Los cambios de iframe normalmente no llegan a la puntuación del documento padre en herramientas de laboratorio ni de RUM.
• Posicionamiento: Google dice que es una entrada de sus sistemas dentro de la experiencia de página, pero no documenta un peso ni una regla de desempate. Llega a «bueno» en vez de perseguir un mecanismo concreto. CrUX lleva unos 28 días de retraso y el elemento atribuido no suele ser la causa raíz.

Documentación oficial

Documentación de fuentes primarias de Google y del equipo de Chrome.

Documentación principal de CLS

• Cumulative Layout Shift (CLS) — definición canónica, fórmula impacto × distancia, ventanas de sesión, umbrales y exclusión hadRecentInput (Milica Mihajlija y Philip Walton).
• Optimizar Cumulative Layout Shift — guía oficial de causas y soluciones: imágenes, anuncios/incrustaciones, contenido inyectado, fuentes y animaciones.
• Depurar los cambios de diseño — búsqueda de cambios en Chrome DevTools, superposición Layout Shift Regions y API LayoutShiftAttribution (Katie Hempenius y Barry Pollard).

Contexto y medición

• Cómo evoluciona CLS en las herramientas web — por qué la métrica pasó de sumar todos los cambios a la mayor ventana de sesión en junio de 2021 (Annie Sullivan y Hongbo Song, equipo de métricas de velocidad de Chrome).
• Cómo se definieron los umbrales de las métricas de Core Web Vitals — investigación de usuarios y datos de alcanzabilidad detrás de las bandas 0,1 / 0,25.
• Primeros pasos para medir Web Vitals — datos de laboratorio frente a campo y por qué el CLS de laboratorio puede leer artificialmente bajo.
• Buenas prácticas para fuentes — font-display, anulaciones de métricas y precarga para el CLS relacionado con fuentes.

Anuncios y Search

• Minimizar los cambios de diseño — guía de Google Publisher Tag para reservar espacio del anuncio.
• Cómo influyen las Core Web Vitals en los resultados de Google Search — cómo influyen las CWV, incluido CLS, en Search.

Citas de las fuentes

Declaraciones públicas de Google y del equipo de Chrome. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — qué es CLS

• “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (traducción) «Cumulative Layout Shift (CLS) es una métrica estable de Core Web Vitals. Es importante y está centrada en el usuario porque cuantifica con qué frecuencia se sufren cambios de diseño inesperados». Ir a la cita
• “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traducción) «CLS mide el mayor conjunto de puntuaciones de cambios para cada cambio inesperado durante todo el ciclo de vida de una página». Ir a la cita

Google — la fórmula

• “layout shift score = impact fraction * distance fraction” (traducción) «puntuación del cambio de diseño = fracción de impacto * fracción de distancia». Ir a la cita
• “The impact fraction measures how unstable elements impact the viewport area between two frames.” (traducción) «La fracción de impacto mide cómo afectan los elementos inestables al área del viewport entre dos fotogramas». Ir a la cita
• “The distance fraction is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” (traducción) «La fracción de distancia es la mayor distancia horizontal o vertical recorrida por un elemento inestable, dividida por la dimensión mayor del viewport (ancho o alto, la que sea mayor)». Ir a la cita

Google — la ventana de sesión

• “A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” (traducción) «Un conjunto de cambios, llamado ventana de sesión, ocurre cuando uno o más cambios individuales suceden rápidamente, con menos de 1 segundo entre ellos y una duración total máxima de 5 segundos». Ir a la cita

Google — umbrales y entrada del usuario

• “To provide a good user experience, sites should strive to have a CLS score of 0.1 or less… a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (traducción) «Para ofrecer una buena experiencia, los sitios deberían aspirar a CLS de 0,1 o menos… un buen umbral es el percentil 75 de las cargas, segmentado entre móvil y escritorio». Ir a la cita
• “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” (traducción) «Los cambios dentro de los 500 milisegundos de una entrada del usuario tendrán activada hadRecentInput y pueden excluirse de los cálculos». Ir a la cita
• “Layout shifts that occur in response to user interactions (such as clicking or tapping a link, pressing a button, or typing in a search box) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” (traducción) «Los cambios en respuesta a interacciones del usuario suelen estar bien, siempre que ocurran suficientemente cerca para que la relación sea clara». Ir a la cita

Google — cómo se eligieron los umbrales

• “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” (traducción) «los cambios de 0,15 o más se percibían sistemáticamente como molestos, mientras que los de 0,1 o menos eran perceptibles, pero no excesivamente molestos». Ir a la cita

Google — reservar espacio para el anuncio

• “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (traducción) «Definir directamente una altura y una anchura fijas en el div del espacio publicitario es la forma más eficaz de hacerlo». Ir a la cita

Google — el elemento atribuido frente a la causa raíz

• “elements listed as sources are the elements that shifted during the layout shift. However, it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (traducción) «los elementos listados como fuentes son los que se desplazaron durante el cambio; sin embargo, es posible que solo estén relacionados indirectamente con la “causa raíz” de la inestabilidad del diseño». Ir a la cita

Lista de comprobación de causas → soluciones de CLS

Trabaja de arriba abajo; los dos primeros puntos corrigen la mayoría del CLS del mundo real.

• Cada <img> y <video> tiene width + height (o un CSS aspect-ratio), con img { height: auto; width: 100%; } para diseños adaptables.
• Los espacios publicitarios, iframes e incrustaciones reservan espacio mediante min-height / aspect-ratio; los espacios de varios tamaños reservan el mayor configurado.
• El contenido que carga tarde queda bajo el pliegue cuando sea posible, para que cualquier cambio residual no cuente.
• El contenido inyectado (banners de cookies, promociones y widgets «relacionados») se superpone o se reserva de antemano, no se inserta sobre contenido existente.
• Los marcadores esqueleto coinciden con las dimensiones exactas del contenido final; unos pocos píxeles de diferencia siguen provocando un cambio.
• Las fuentes web usan font-display: optional cuando sea aceptable, o swap junto con size-adjust / ascent-override para igualar las métricas; las fuentes críticas se precargan.
• Las animaciones usan solo transform: nunca top, left, margin, box-shadow ni box-sizing.
• Has comprobado la puntuación en datos de campo (PageSpeed Insights / Search Console / CrUX), no solo en Lighthouse.
• Has reproducido los cambios interactuando con la página —desplazarte, abrir menús y activar cargas diferidas—, no solo en la carga inicial.
• Los cambios de anuncios/iframes se han verificado en campo; las herramientas de laboratorio a menudo no los propagan a la puntuación del documento padre.

Chuleta de CLS

Los números

La definición en una línea

• layout shift score = impact fraction × distance fraction (por cambio).
• CLS = la mayor ventana de sesión de cambios: ≤ 1 s entre cambios y ≤ 5 s de ventana total. No es la suma de toda la vida (esa era la definición anterior a junio de 2021).
• Es una puntuación sin unidad, no un tiempo.

Qué queda excluido

• Cambios bajo el pliegue (fuera del viewport actual).
• Cambios dentro de 500 ms de una entrada discreta (toque/clic/pulsación): hadRecentInput.
• No quedan excluidos los cambios durante el desplazamiento o el pellizco (gestos continuos).

Causas → soluciones

Trampas de medición

• Lighthouse (laboratorio) suele leer ~0: no interactúa con la página ni ejecuta todo el ciclo de vida. CrUX / PageSpeed Insights (campo) es lo que Google usa para posicionar.
• CrUX lleva unos 28 días de retraso: las correcciones tardan semanas en aparecer.
• Los cambios de iframe normalmente no se propagan a la puntuación del documento padre en herramientas de laboratorio.
• El elemento atribuido es el que se movió, no necesariamente la causa raíz.

Herramientas para medir y depurar CLS

Datos de campo (los que usa Google para posicionar)

• PageSpeed Insights — CLS de campo de CrUX a nivel de página y de origen, junto a una prueba de laboratorio de Lighthouse. Es la forma más rápida de ver la diferencia entre laboratorio y campo.
• Search Console — informe de Core Web Vitals — CLS de campo por grupo de URL en todo el sitio, agrupado por estado.
• CrUX (Chrome User Experience Report) — el conjunto de datos de campo subyacente; explora su historial mediante los paneles de CrUX o BigQuery.

Datos de laboratorio (para depurar)

• Chrome DevTools — panel Performance — graba una traza y lee la pista Layout Shifts; al hacer clic en un cambio se resaltan los elementos movidos y se muestra su puntuación. Live Metrics muestra la actualización de CLS mientras interactúas.
• Superposición Layout Shift Regions — DevTools → Settings → More tools → Rendering → Layout Shift Regions. Recarga y las áreas que cambian parpadearán para que puedas verlas.
• Lighthouse — CLS rápido de laboratorio, pero recuerda que solo captura cambios de la carga inicial.
• WebPageTest — CLS de laboratorio con tira de película y traza.

RUM (tus propios datos de campo)

• Biblioteca JavaScript web-vitals — onCLS() informa del CLS real de tus visitantes (~2 KB), la imagen más precisa de lo que experimentan.
• PerformanceObserver (layout-shift) — la API sin procesar que envuelve la biblioteca, junto con LayoutShiftAttribution y sus sources, que indican qué elementos se movieron.

Cómo puntúan las propias herramientas

Un ejemplo real de la métrica que describe esta página: servicios conocidos de velocidad y monitorización clasificados por su propio CLS móvil de usuarios reales (datos de campo de Chrome UX Report):

¿Qué corrección de CLS debes hacer primero?

Errores de CLS que ocultan el problema real

Tratar una ejecución limpia de Lighthouse como una prueba

Lighthouse puede terminar antes de que ocurra un banner de consentimiento, un anuncio o un cambio provocado por una interacción. Usa la prueba de laboratorio para depurar, pero comprueba CrUX o tu propia monitorización de usuarios reales antes de declarar solucionado el problema.

Corregir solo el elemento que DevTools dice que se movió

El elemento desplazado suele ser la víctima. La causa puede ser algo que carga tarde por encima. Reproduce la traza e inspecciona qué entró o cambió de tamaño justo antes del movimiento.

Reservar espacio con una altura fija inventada

Un marcador fijo puede crear un segundo cambio si el contenido adaptable es más alto o más bajo. Usa dimensiones intrínsecas o aspect-ratio cuando conozcas las proporciones del contenido.

Animar propiedades del diseño

Cambiar top, left o los márgenes puede mover el contenido que los rodea. Anima con transform cuando el efecto no necesite cambiar el flujo del documento.

Diagnostica un problema de CLS por su síntoma

El CLS de campo es malo, pero la puntuación de laboratorio se acerca a cero

Causa probable: el cambio ocurre después de una interacción, durante una sesión larga o solo para una parte de los usuarios. Solución: reproduce el recorrido real mientras grabas el panel Performance y añade la atribución de web-vitals en la monitorización de usuarios reales. Confirmación: la interacción problemática y el elemento desplazado aparecen en la traza o en el registro RUM.

El texto salta cuando llega la fuente personalizada

Causa probable: la fuente alternativa y la web usan métricas diferentes. Solución: precarga solo la fuente crítica cuando proceda y ajusta la alternativa con anulaciones de métricas. Confirmación: repite con la caché desactivada y comprueba que la pista Layout Shifts ya no registra el cambio de fuente.

Un banner o anuncio empuja la página hacia abajo

Causa probable: el espacio no tiene dimensiones reservadas antes de que llegue el contenido. Solución: asigna un contenedor estable o coloca el mensaje donde no desplace contenido visible. Confirmación: limita la carga y observa que el espacio conserve su huella.

CLS mejora en las pruebas, pero no en PageSpeed Insights

Causa probable: CrUX es un conjunto de datos de campo móvil, no una comprobación inmediata del despliegue. Solución: verifica primero el cambio en laboratorio y RUM, y espera después a que cambie la ventana de campo. Confirmación: tu distribución de campo posterior al lanzamiento mejora antes de que le siga el agregado público de CrUX.

Captura los cambios de diseño en el navegador

Pega esto en la consola de DevTools antes de reproducir el problema. Ignora los cambios vinculados a entradas recientes del usuario e imprime la puntuación junto con los elementos que el navegador atribuyó.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.table({
      value: entry.value,
      time: Math.round(entry.startTime),
      elements: entry.sources?.map((source) => source.node),
    });
  }
});

observer.observe({ type: 'layout-shift', buffered: true });

El nodo atribuido es una pista, no una prueba automática de la causa. Compara su marca de tiempo con las peticiones de red, las cargas de fuentes y las inserciones del DOM en la misma traza.

Demuestra que una corrección de CLS funcionó

Prueba de espacio reservado

Prueba: desactiva la caché, limita la conexión, recarga y graba la pista Layout Shifts del panel Performance. Resultado esperado: el contenido multimedia o la incrustación conserva la misma huella antes y después de cargar. Interpretación del fallo: el contenedor aún depende de contenido tardío para sus dimensiones. Ventana de monitorización: inmediata en la traza. Disparador de reversión: el marcador nuevo crea recortes, demasiado espacio vacío o un cambio nuevo en un breakpoint adaptable.

Prueba de sustitución de fuente

Prueba: recarga con la caché desactivada mientras observas el texto y la pista Layout Shifts. Resultado esperado: la transición de la fuente alternativa a la web no crea un cambio medible. Interpretación del fallo: las métricas alternativas siguen siendo distintas o la fuente crítica llega tarde. Ventana de monitorización: inmediata en ejecuciones de laboratorio repetidas. Disparador de reversión: el cambio oculta el texto durante más tiempo o hace que la tipografía final sea materialmente incorrecta.

Confirmación en campo

Prueba: compara los datos onCLS() posteriores al lanzamiento de la plantilla modificada con su línea base anterior y observa CrUX. Resultado esperado: el p75 de usuarios reales mejora sin una cola peor en los recorridos importantes. Interpretación del fallo: queda otra fuente tardía o activada por interacción. Ventana de monitorización: RUM a medida que llega tráfico; CrUX durante su ventana móvil de 28 días. Disparador de reversión: CLS o los errores de interacción empeoran de forma constante después del lanzamiento.

Métricas de CLS que merece la pena seguir

CLS de usuarios reales en p75

Métrica: CLS en el percentil 75 para cada plantilla importante y clase de dispositivo. Qué indica: si la mayoría de las visitas alcanza el objetivo de estabilidad visual. Cómo obtenerla: CrUX, PageSpeed Insights o RUM con web-vitals. Referencia / rango realista: bueno es 0,1 o menos; 0,1–0,25 necesita mejoras; por encima de 0,25 es malo. Cadencia: monitoriza los lanzamientos en RUM y revisa mensualmente la tendencia móvil de campo.

Tasa de visitas malas

Métrica: proporción de visitas reales con CLS por encima de 0,25. Qué indica: si un p75 aceptable oculta una cola dañina. Cómo obtenerla: agrupa los eventos onCLS() por plantilla y recorrido. Referencia / rango realista: establece una línea base del sitio y reduce el grupo malo; la mezcla de tráfico hace engañoso un objetivo universal. Cadencia: semanal para plantillas con mucho tráfico y después de lanzamientos de diseño.

Atribución de cambios por causa

Métrica: entradas de layout shift agrupadas por elemento o componente. Qué indica: qué implementación recurrente posee la mayor inestabilidad. Cómo obtenerla: la compilación de atribución de web-vitals o PerformanceObserver. Referencia / rango realista: no existe un rango universal; compara componentes por impacto total y visitas afectadas. Cadencia: revisa con cada lanzamiento de plantilla o componente.

Recursos que merecen tu tiempo

Oficiales y detallados

• Cumulative Layout Shift (CLS) — referencia canónica.
• Optimizar Cumulative Layout Shift — guía oficial de correcciones.
• Depurar los cambios de diseño — flujo de trabajo de DevTools.
• Cómo evoluciona CLS en las herramientas web — explica el cambio de junio de 2021 a la ventana de sesión, por el equipo que lo creó.

De profesionales

• Cómo corregir problemas de Cumulative Layout Shift (CLS) — Barry Pollard, Smashing Magazine. Profundiza en los descriptores de fuentes y en el problema de que «el elemento que se movió no es la causa raíz».
• Cumulative Layout Shift en la práctica — Nic Jansma (Cloudflare; W3C Web Performance WG). Excelente análisis de matices: atribución de iframes, muestra de cinco elementos y discrepancias entre herramientas.
• Medir y optimizar Cumulative Layout Shift — DebugBear.
• Guía casi completa de Cumulative Layout Shift — Jess Peck. Trata casos límite, incluidos cambios de navegación SPA y exclusiones de gestos continuos.
• Causantes de cambios de diseño — documentación de Chrome DevTools sobre el panel de culpables de CLS.
• Cómo corregir Cumulative Layout Shift (CLS) — Kinsta. Guía práctica centrada en CMS y causas específicas de WordPress.
• Layout Instability API — especificación de WICG y API subyacente de CLS para RUM personalizado y semántica exacta de hadRecentInput.

Dónde encaja en mi trabajo

• CLS aparece como una métrica básica en mi cobertura de Core Web Vitals: síguelo, entra en la banda buena y mantenlo en proporción frente a LCP, INP y tu contenido. Google no publica un peso exacto de CLS ni una regla de desempate, así que es una entrada que conviene observar, no el juego entero.

Estadísticas que merece la pena citar

• El umbral de 0,1 se basa en investigación de percepción. Los estudios de usuarios de Google descubrieron que los cambios de 0,15 o más se percibían sistemáticamente como molestos, mientras que los de 0,1 o menos eran perceptibles, pero no excesivamente molestos. Fuente
• CLS es la Core Web Vital más fácil de aprobar. En mis auditorías empresariales el patrón es constante: una gran mayoría de sitios supera el umbral CLS (a menudo ~80 % o más), pero solo algo más de la mitad aprueba las tres métricas; CLS rara vez es el obstáculo.
• El cambio de junio de 2021 ayudó, nunca perjudicó. Al pasar CLS a la ventana de sesión más grande, ningún origen recibió una puntuación peor, la mayoría no cambió y mejoró una parte de las páginas de desplazamiento infinito e interfaz lenta. Fuente
• Los recursos multimedia sin tamaño siguen siendo muy comunes. Los rastreos de la industria (Web Almanac) encuentran sistemáticamente muchas páginas que sirven imágenes sin dimensiones explícitas: la causa más común de CLS y la más fácil de arreglar.
• El 72 % de los sitios web del mundo logra ahora un CLS bueno (datos de Web Almanac / HTTP Archive de 2025), lo que lo convierte en la Core Web Vital más fácil de aprobar; aun así, el 62 % de las páginas móviles sirve al menos una imagen sin dimensiones explícitas, la causa más común. Fuente: HTTP Archive / Web Almanac
• Impacto empresarial: Rakuten 24 informó de un aumento del 53,37 % en ingresos por visitante para usuarios con CLS bajo frente a alto: un caso citado con frecuencia, no prueba de que una cifra CLS concreta cause el mismo resultado en otros sitios. Fuente: casos de estudio de corewebvitals.io

Vídeos

• Google Search Central / Chrome para desarrolladores (YouTube) — recorrido por Core Web Vitals y Depurar los cambios de diseño, con demostraciones de DevTools de la pista Layout Shifts y la superposición Layout Shift Regions. Canal

Ponte a prueba: Cumulative Layout Shift

Cinco preguntas rápidas sobre medir y corregir la inestabilidad visual. Elige una respuesta para cada una y después comprueba el resultado.

Registro de cambios