performance

CLS d'usuaris reals (dades de camp)

CLS d'usuaris reals de Chrome durant els últims 28 dies (percentil 75). Captura desplaçaments dinàmics que el laboratori no pot reproduir: anuncis tardans, fonts, variants A/B.

Què comprova aquesta auditoria

Llegeix el Cumulative Layout Shift al percentil 75 del Chrome User Experience Report, agregat en una finestra mòbil de 28 dies amb dades reals d’usuaris de Chrome que hi han donat consentiment. El CLS no té unitats: suma l’impacte de cada moviment inesperat del layout durant la visita, amb un sostre a la finestra de 5 segons amb més activitat.

CLS de camp (p75)Veredicte
≤ 0,10Bo
0,10–0,25Cal millorar
> 0,25Pobre

Per què el CLS de camp és diferent del CLS de laboratori:

  • El CLS de laboratori s’executa una vegada. Lighthouse carrega la pàgina, espera uns segons i suma els desplaçaments.
  • El CLS de camp s’executa durant tota la visita. Els usuaris reals fan scroll, cliquen i interactuen durant minuts. Cada desplaçament compta, incloent xarxes publicitàries que carreguen tard, imatges en lazy-load, variants A/B i widgets de recomanació que hidraten després del primer paint.

És per això que el CLS de camp sol ser pitjor que el de laboratori, i per què arreglar-lo requereix pensar en tot el recorregut de l’usuari, no només en els primers 5 segons.

Per què importa

El CLS és un dels tres Core Web Vitals de Google i un senyal de posicionament directe. Un CLS dolent no és només un problema de SEO, és un bug d’usabilitat que empitjora com més temps es queda l’usuari:

  • Els usuaris cliquen el botó equivocat quan un anunci empeny el contingut cap avall.
  • S’envien formularis amb els valors incorrectes quan un banner que carrega tard desplaça el layout.
  • Les taxes de conversió cauen de manera mesurable per sobre de CLS 0,25 (el llindar “pobre” de Google).

Si el teu CLS de camp és alt però el de laboratori és bo, el problema gairebé sempre és contingut que es carrega després del primer paint, i les eines de laboratori no esperen prou per veure-ho.

Com millorar-ho

1. Reserva espai per a tot el que sigui asíncron. Cada imatge, vídeo, embed, anunci o widget que es carrega després del primer paint necessita dimensions explícites abans de carregar-se:

<!-- Per a imatges, inclou sempre width + height -->
<img src="/foto.jpg" width="600" height="400" alt="..." />

<!-- Per a iframes (YouTube, Twitter), embolcalla'ls amb un contenidor de ràtio fixa -->
<div style="aspect-ratio: 16 / 9;">
  <iframe src="https://www.youtube.com/embed/abc" width="100%" height="100%"></iframe>
</div>

<!-- Per a slots d'anuncis, declara el min-height en CSS abans que carregui el SDK -->
<div class="ad-slot" style="min-height: 250px;"></div>

2. Evita injectar contingut sobre contingut existent. Si has de mostrar un banner de cookies, empeny-lo cap al peu de la pàgina o fes servir una barra fixa a dalt amb position: fixed. Mai l’injectis dins del flux del document.

3. Fes servir font-display: optional (o swap amb una fallback acurada). Les webfonts que arriben tard fan que el titular salti de les mètriques de la fallback a les de la webfont. El descriptor CSS size-adjust pot ajustar la fallback a l’alçada-x de la webfont perquè el canvi sigui invisible:

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

4. Fes servir transform en comptes de top / left / margin per a les animacions. Les animacions basades en transform no provoquen layout, així que no contribueixen al CLS.

5. Vigila les etiquetes <script> de càrrega tardana que muten el DOM. Eines de personalització, GTM, Hotjar, Intercom: tots són ofensors habituals. Si un script de tercers injecta un element above the fold després que la pàgina s’hagi renderitzat, això és CLS.

6. Prova amb extensions activades. Les eines de laboratori utilitzen un navegador net; els usuaris reals tenen ad-blockers que eliminen els marcadors d’espai, deixant layouts col·lapsats que després es tornen a desplaçar. Reserva l’espai amb CSS que sobrevisqui a la manipulació del DOM dels ad-blockers.

Preguntes freqüents

El meu CLS és genial en desenvolupament però pobre en producció. Per què?

Producció té coses que desenvolupament no té: inventari publicitari real, variants A/B reals, widgets de recomanació reals, personalització real. Configura l’API de CrUX o la llibreria JS web-vitals per mesurar en viu en producció: npm i web-vitals i crida onCLS(reportFn) per registrar els desplaçaments en directe.

Compten els desplaçaments provocats per l’usuari?

No. El CLS només compta els desplaçaments inesperats: qualsevol moviment durant els 500 ms posteriors a un clic, toc o pulsació de tecla queda exclòs. Així que una pestanya que obre un acordió no compta encara que visiblement desplaci el contingut.

I els enllaços d’àncora que fan saltar la pàgina?

Els scrolls a una àncora no compten com a CLS: l’especificació exclou qualsevol desplaçament que passi durant un scroll programàtic. Si el teu CLS és misteriosament alt, els salts d’àncora no en són la causa.

Fonts

Última actualització 2026-05-12