CLS de usuarios reales (datos de campo)

Qué hace esta comprobación

Lee el percentil 75 de Cumulative Layout Shift del Chrome User Experience Report — agregado en una ventana móvil de 28 días a partir de usuarios reales de Chrome que han dado su consentimiento. CLS es adimensional; suma el impacto de cada movimiento inesperado del layout durante la visita, limitado a la mayor ventana de 5 segundos de actividad.

CLS de campo (p75)	Veredicto
≤ 0,10	Bueno
0,10–0,25	Necesita mejorar
> 0,25	Deficiente

Por qué el CLS de campo es distinto al de laboratorio:

• El CLS de laboratorio se ejecuta una sola vez. Lighthouse carga la página, espera unos segundos y suma los desplazamientos.
• El CLS de campo se ejecuta durante toda la visita. Los usuarios reales hacen scroll, clican e interactúan durante minutos. Cada desplazamiento cuenta — incluidos los anuncios de carga tardía, las imágenes con lazy-loading, las variantes A/B y los widgets de recomendación que se hidratan después del primer paint.

Por eso el CLS de campo suele ser peor que el de laboratorio, y por eso arreglarlo exige pensar en el recorrido completo del usuario, no solo en los primeros 5 segundos.

Por qué importa

CLS es uno de los tres Core Web Vitals de Google y una señal de posicionamiento directa. Un CLS malo no es solo un problema de SEO — es un fallo de usabilidad que empeora cuanto más tiempo permanece el usuario:

• Los usuarios clican el botón equivocado cuando un anuncio empuja el contenido hacia abajo.
• Los formularios se envían con valores incorrectos cuando un banner de carga tardía desplaza el layout.
• Las tasas de conversión caen de forma medible por encima de un CLS de 0,25 (el umbral de Google para «deficiente»).

Si tu CLS de campo es alto pero el de laboratorio es bueno, el fallo casi siempre está en contenido que se carga después del primer paint — y las herramientas de laboratorio no esperan lo bastante como para verlo.

Cómo mejorarla

1. Reserva espacio para todo lo asíncrono. Cada imagen, vídeo, embed, anuncio o widget que se cargue después del primer paint necesita dimensiones explícitas antes de cargarse:

<!-- For images, always include width + height -->
<img src="/photo.jpg" width="600" height="400" alt="..." />

<!-- For iframes (YouTube, Twitter), wrap in a fixed-ratio container -->
<div style="aspect-ratio: 16 / 9;">
  <iframe src="https://www.youtube.com/embed/abc" width="100%" height="100%"></iframe>
</div>

<!-- For ad slots, declare the min-height in CSS before the SDK loads -->
<div class="ad-slot" style="min-height: 250px;"></div>

2. Evita inyectar contenido por encima del contenido existente. Si tienes que mostrar un banner de cookies, empújalo al pie de la página o usa una barra fija superior con position: fixed — nunca lo inyectes dentro del flujo del documento.

3. Usa font-display: optional (o swap con un fallback bien afinado). Las fuentes web que llegan tarde hacen que el titular salte de las métricas de la fuente de respaldo a las de la fuente web. El descriptor CSS size-adjust puede ajustar el fallback a la altura de x de la fuente web para que el cambio sea invisible:

@font-face {
  font-family: "Inter-Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

4. Usa transform en lugar de top / left / margin para las animaciones. Las animaciones basadas en transform no provocan layout, así que no contribuyen al CLS.

5. Cuidado con las etiquetas <script> de enlace tardío que mutan el DOM. Herramientas de personalización, GTM, Hotjar, Intercom — todos infractores habituales. Si un script de terceros inyecta un elemento por encima del pliegue después de que la página se haya renderizado, eso es CLS.

6. Prueba con extensiones activadas. Las herramientas de laboratorio corren un navegador limpio; los usuarios reales tienen bloqueadores de anuncios que eliminan los placeholders, dejando layouts colapsados que después se vuelven a reordenar. Reserva el espacio con CSS que sobreviva a la manipulación del DOM del bloqueador.

Preguntas frecuentes

Mi CLS es excelente en desarrollo pero deficiente en producción. ¿Por qué?

Producción tiene cosas que desarrollo no: inventario publicitario real, variantes A/B reales, widgets de recomendación reales, personalización real. Configura la API de CrUX o la librería JS web-vitals para medir en vivo en producción — npm i web-vitals y llama a onCLS(reportFn) para registrar los desplazamientos en directo.

¿Se cuentan los desplazamientos provocados por la interacción del usuario?

No. CLS solo cuenta los desplazamientos inesperados — todo lo que ocurre dentro de los 500 ms posteriores a un clic, toque o pulsación de tecla queda excluido. Por eso una pestaña que abre un acordeón no cuenta aunque desplace visiblemente el contenido.

¿Y los enlaces de anclaje que saltan dentro de la página?

Los desplazamientos por anclas no se cuentan como CLS — la especificación excluye cualquier desplazamiento que ocurra durante un scroll programático. Si tu CLS es misteriosamente alto, los saltos por anclas no son la causa.