CLS di utenti reali (dati di campo)

Cosa fa questo controllo

Legge il 75° percentile del Cumulative Layout Shift dal Chrome User Experience Report — aggregato su una finestra mobile di 28 giorni dagli utenti Chrome reali che hanno aderito. Il CLS è adimensionale; somma l’impatto di ogni spostamento di layout inatteso durante la visita, limitato alla finestra di attività di 5 secondi più rilevante.

CLS di campo (p75)	Verdetto
≤ 0,10	Buono
0,10–0,25	Da migliorare
> 0,25	Scarso

Perché il CLS di campo è diverso da quello di lab:

• Il CLS di lab gira una sola volta. Lighthouse carica la pagina, aspetta qualche secondo e somma gli spostamenti.
• Il CLS di campo gira per tutta la visita. Gli utenti reali scorrono, cliccano e interagiscono per minuti. Ogni spostamento conta — incluse le reti pubblicitarie che caricano in ritardo, le immagini lazy-loaded, le varianti A/B e i widget di raccomandazione che si idratano dopo il primo paint.

Per questo il CLS di campo è di solito peggiore di quello di lab, e per questo risolverlo richiede di pensare all’intero percorso utente, non solo ai primi 5 secondi.

Perché conta

Il CLS è uno dei tre Core Web Vitals di Google e un segnale di ranking diretto. Un CLS scarso non è solo un problema SEO — è un bug di usabilità che peggiora più a lungo l’utente rimane sulla pagina:

• Gli utenti cliccano sul pulsante sbagliato quando un annuncio spinge giù il contenuto.
• I form vengono inviati con i valori sbagliati quando un banner caricato in ritardo sposta il layout.
• I tassi di conversione calano in modo misurabile sopra un CLS di 0,25 (la soglia “scarsa” di Google).

Se il CLS di campo è alto ma quello di lab è buono, il problema è quasi sempre contenuto che si carica dopo il primo paint — e gli strumenti di lab non aspettano abbastanza per vederlo.

Come migliorarlo

1. Riserva spazio per tutto ciò che è asincrono. Ogni immagine, video, embed, annuncio o widget che si carica dopo il primo paint deve avere dimensioni esplicite prima di caricarsi:

<!-- Per le immagini, includi sempre width + height -->
<img src="/photo.jpg" width="600" height="400" alt="..." />

<!-- Per gli iframe (YouTube, Twitter), avvolgili in un contenitore a rapporto fisso -->
<div style="aspect-ratio: 16 / 9;">
  <iframe src="https://www.youtube.com/embed/abc" width="100%" height="100%"></iframe>
</div>

<!-- Per gli ad slot, dichiara il min-height in CSS prima che l'SDK si carichi -->
<div class="ad-slot" style="min-height: 250px;"></div>

2. Evita di iniettare contenuto sopra contenuto esistente. Se devi mostrare un banner cookie, spingilo in fondo alla pagina o usa una barra sticky in alto con position: fixed — non iniettarlo mai nel flusso del documento.

3. Usa font-display: optional (o swap con un fallback ben curato). I webfont che arrivano in ritardo fanno saltare i titoli dalle metriche del fallback a quelle del webfont. Il descrittore CSS size-adjust può allineare il fallback all’altezza x del webfont, così lo scambio è invisibile:

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

4. Imposta transform invece di top / left / margin per le animazioni. Le animazioni basate su transform non scatenano layout, quindi non contribuiscono al CLS.

5. Attenzione ai tag <script> a binding tardivo che mutano il DOM. Strumenti di personalizzazione, GTM, Hotjar, Intercom — tutti colpevoli comuni. Se uno script di terze parti inietta un elemento sopra la piega dopo che la pagina si è renderizzata, è CLS.

6. Testa con le estensioni attive. Gli strumenti di lab girano in un browser pulito; gli utenti reali hanno ad-blocker che rimuovono i placeholder, lasciando layout collassati che poi si rispostano. Riserva lo spazio con CSS che sopravviva alla manipolazione del DOM dell’ad-blocker.

Domande frequenti

Il mio CLS è ottimo in sviluppo ma scarso in produzione. Perché?

La produzione ha cose che lo sviluppo non ha: inventario pubblicitario reale, varianti A/B reali, widget di raccomandazione reali, personalizzazione reale. Configura le API CrUX o la libreria JS web-vitals per misurare dal vivo in produzione — npm i web-vitals e chiama onCLS(reportFn) per loggare gli spostamenti in diretta.

Gli spostamenti di layout su input utente vengono contati?

No. Il CLS conta solo gli spostamenti inattesi — qualsiasi cosa entro 500 ms da un click, tap o pressione di tasto è esclusa. Quindi una tab che apre un accordion non conta anche se sposta visibilmente i contenuti.

E i link ancora che fanno saltare la pagina?

Gli scroll su ancora non contano come CLS — la specifica esclude qualsiasi spostamento che avvenga durante uno scroll programmatico. Se il tuo CLS è misteriosamente alto, i salti su ancora non sono la causa.