Cumulative Layout Shift (CLS): guida alla stabilità visiva

TL;DR — Cumulative Layout Shift (CLS) misura quanto gli elementi di una pagina si spostano da soli mentre cerchi di leggere o toccare qualcosa: l’immagine che si carica in ritardo e spinge il testo verso il basso, il pulsante che salta proprio mentre stai per toccarlo. Il punteggio parte da 0 e 0,1 o meno è buono. Nella maggior parte dei casi il problema nasce da elementi che non hanno riservato il proprio spazio prima di caricarsi.

Che cos’è il CLS

Lo hai sperimentato anche se non hai mai sentito il termine. Stai leggendo un articolo, un annuncio o un’immagine finisce di caricarsi sopra il punto che stai guardando e all’improvviso tutta la pagina salta verso il basso. Oppure stai per toccare “Annulla” e compare un banner, così il tuo tocco finisce su “Conferma”. Questo movimento inatteso è un layout shift e Cumulative Layout Shift è il modo con cui Google gli assegna un numero che indica quanto sia grave.

È uno dei tre Core Web Vitals, il trio di metriche dell’esperienza di pagina che Google monitora, insieme a Largest Contentful Paint (la velocità con cui si carica il contenuto principale) e Interaction to Next Paint (la rapidità con cui la pagina risponde quando tocchi). Il CLS riguarda la stabilità visiva: la pagina resta ferma?

Come funziona il punteggio (in breve)

Il CLS è un punteggio, non un tempo. Un CLS di 0,05 non significa 50 millisecondi di qualcosa: è un numero senza unità. Più grande è la porzione dello schermo che si sposta e più lontano si muove, più alto (e peggiore) è il punteggio.

Gli obiettivi sono semplici:

• 0,1 o meno — buono.
• Da 0,1 a 0,25 — necessita miglioramenti.
• Oltre 0,25 — scarso.

Un dettaglio utile: gli spostamenti che avvengono subito dopo che tu fai qualcosa — tocchi un pulsante, apri un menu — non si ripercuotono sulla pagina, perché li hai causati tu e te li aspetti. Conta solo il movimento inaspettato.

Perché succede (e come risolverlo)

Quasi ogni layout shift dipende dalla stessa cosa: qualcosa si è caricato e ha occupato uno spazio che la pagina non aveva riservato. I casi principali sono:

• Immagini e video senza dimensioni. Il browser non sa quanto sarà alta l’immagine finché non arriva, quindi il testo sottostante viene spinto verso il basso. La soluzione: assegna sempre a immagini e video width e height (oppure un aspect-ratio CSS), così il browser riserva lo spazio.
• Annunci, embed e iframe. Lo stesso problema: riserva loro lo spazio.
• Font web. Quando un font personalizzato sostituisce il fallback, il testo può ridisporrsi.
• Elementi che compaiono dopo. Banner dei cookie, riquadri “potrebbe piacerti”, qualunque cosa venga inserita sopra contenuti che stai già guardando.

La regola mentale è questa: se qualcosa sta per comparire più tardi, lascia un vuoto delle dimensioni corrette così nient’altro dovrà spostarsi quando apparirà.

Vuoi la formula effettiva, la regola della “finestra di sessione”, il motivo per cui i numeri CLS di laboratorio e sul campo non coincidono e l’elenco completo di cause e correzioni? Passa alla scheda Advanced.

TL;DR — CLS è il Core Web Vital della stabilità visiva. Ogni spostamento riceve il punteggio impact fraction × distance fraction; la metrica è la finestra di sessione più grande degli spostamenti (≤ 1 s tra gli spostamenti, finestra di ≤ 5 s), non la somma sull’intera vita della pagina, che era la definizione precedente a giugno 2021. Buono è ≤ 0,1, necessita miglioramenti fino a 0,25, scarso > 0,25, al 75° percentile dei dati sul campo. Contano solo gli spostamenti visibili nella viewport; sono esclusi quelli entro 500 ms da un input discreto (lo scrolling no). Le cause sono immagini/video/annunci/iframe/embed senza dimensioni, font web e contenuti inseriti sopra contenuti esistenti; le correzioni consistono nel riservare spazio, usare font-display/size-adjust e animare solo con transform. La trappola da evitare: Lighthouse (laboratorio) legge spesso valori vicini a 0 perché non interagisce con la pagina e non esegue l’intero ciclo di vita; i dati sul campo (CrUX) sono ciò che Google misura davvero.

Che cosa misura il CLS

L’inquadramento di Google è questo: “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.” La parola operativa è inaspettato: contenuto che si sposta da solo, non perché l’utente abbia fatto qualcosa.

Fa parte del trio dei Core Web Vitals insieme a Largest Contentful Paint (caricamento) e Interaction to Next Paint (reattività). Mentre LCP e INP si misurano in millisecondi, il CLS è l’eccezione: un punteggio di rapporto senza unità. È una distinzione che confonde continuamente. Un CLS di 0,05 non è 50 ms: non ha alcuna unità di tempo.

La formula: impatto × distanza

Per ogni spostamento, Google la definisce così:

layout shift score = impact fraction × distance fraction

• Impact fraction “measures how unstable elements impact the viewport area between two frames”: l’area visibile combinata occupata dagli elementi in movimento (prima e dopo), espressa come quota della viewport.
• Distance fraction è “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).”

Entrambe le dimensioni contano indipendentemente. Un elemento piccolo che attraversa quasi tutto lo schermo e un elemento grande che si sposta appena possono ottenere punteggi molto diversi. L’esempio svolto di web.dev: una impact fraction di 0.75 e una distance fraction di 0.25 producono un punteggio di layout shift pari a 0.1875.

Finestre di sessione: la parte che tutti interpretano male

Ecco il fatto sul CLS che viene riportato più spesso in modo errato e che voglio soprattutto tu ricordi. CLS non è la somma di tutti gli spostamenti durante la vita della pagina. Un tempo lo era, ma è cambiato nel giugno 2021.

Oggi: “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” Un burst è una finestra di sessione: “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.” CLS è il punteggio della finestra più grande, non la somma e non la media.

Perché il cambiamento? La vecchia definizione, che sommava tutto, penalizzava silenziosamente le pagine longeve. Una single-page app o un feed a scorrimento infinito accumulava più CLS solo per il fatto di esistere più a lungo, anche se ogni spostamento era piccolo e ben distanziato. Il team Chrome Speed Metrics è passato alla finestra di sessione massima per evitare di penalizzare la durata e ha scelto il massimo invece della media per evitare il risultato perverso per cui correggere uno spostamento secondario piccolo avrebbe potuto peggiorare il punteggio. Quando la modifica è stata distribuita, nessun origin ha ricevuto un punteggio peggiore, la maggior parte non ha visto cambiamenti e una parte delle pagine con UI lenta o scrolling infinito è migliorata. Se leggi un articolo vecchio che parla ancora della “somma di tutti gli spostamenti”, è obsoleto.

Che cosa conta e che cosa no

Tre esclusioni decidono che cosa finisce davvero nel punteggio:

• Ciò che è sotto la piega non conta. Vengono valutati solo gli spostamenti del contenuto visibile nella viewport corrente. Uno spostamento in fondo a una pagina lunga, che l’utente non raggiunge mai con lo scroll, non ha alcun impatto. In pratica, correggere gli spostamenti nella viewport ha quasi sempre un ROI maggiore che inseguire quelli molto più in basso.
• Gli spostamenti avviati dall’utente hanno una deroga di 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.” La posizione di Google è che gli spostamenti “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.” Apri un accordion o espandi un menu: il movimento è atteso, quindi viene perdonato.
• Lo scrolling però non è una deroga automatica. L’esclusione di 500 ms vale solo per eventi discreti: tocco, clic, pressione di un tasto. I gesti continui (scrolling, pinch-zoom) non attivano la finestra di esclusione. Se il contenuto si sposta mentre qualcuno scorre, conta comunque. Molte descrizioni sbagliano questa distinzione: è importante applicarla correttamente.

Soglie e origine del punteggio

“To provide a good user experience, sites should strive to have a CLS score of 0.1 or less,” misurato al “the 75th percentile of page loads, segmented across mobile and desktop devices.” Le fasce complete:

• Good: ≤ 0,1
• Needs improvement: da 0,1 a 0,25
• Poor: > 0,25

La soglia di 0,1 non è arbitraria. La ricerca sugli utenti di Google ha rilevato che “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.” Hanno scelto 0,1 invece di una soglia più rigida anche perché gli embed di terze parti (annunci, social) causano spostamenti così spesso che una soglia più severa sarebbe poco pratica per il web reale.

La parte “75° percentile dei dati sul campo” è fondamentale, e ci porta alla trappola di misurazione più grande.

Laboratorio e campo: perché i numeri non coincidono

È qui che la maggior parte delle persone si scotta. Lighthouse e altri strumenti di laboratorio riportano spesso un CLS vicino a 0,0 mentre i dati sul campo — e Google — mostrano qualcosa di molto peggiore. La differenza non significa che uno strumento sia disonesto: è una differenza di ambito. Un test di laboratorio è un singolo caricamento breve e programmato; non scorre, non fa clic e non si trattiene, quindi cattura solo gli spostamenti del caricamento iniziale. I dati sul campo (CrUX) aggregano visite reali di molti utenti, dispositivi e navigazioni su una finestra mobile, e CLS è definito sull’intero ciclo di vita della pagina: apertura dei menu, caricamento lazy dei contenuti durante lo scrolling, riempimento tardivo degli annunci, per tutta la durata della sessione. Un breve test di laboratorio non può strutturalmente vedere gran parte di tutto questo.

La regola pratica è quindi: usa i dati di laboratorio per diagnosticare uno spostamento specifico e i dati sul campo per conoscere il tuo punteggio reale. Google usa per il ranking i dati sul campo del Chrome User Experience Report (CrUX), mostrati in PageSpeed Insights e Search Console. Se Lighthouse legge 0,0 ma PageSpeed Insights mostra 0,18, considera il numero sul campo quello che riflette i tuoi utenti reali; poi riproduci lo spostamento in laboratorio interagendo con la pagina come farebbe un visitatore. Ci sono altri due divari di ambito da conoscere: la maggior parte degli strumenti, incluso Lighthouse, non propaga al punteggio del documento padre gli spostamenti di layout degli iframe, anche se CrUX può rifletterli; inoltre il RUM basato sulla Layout Instability API eredita lo stesso punto cieco sugli iframe, quindi il tuo monitoraggio degli utenti reali può spiegare solo in parte un numero CrUX peggiore di quanto mostri l’attribuzione di prima parte.

Le cause comuni

In ordine approssimativo di frequenza con cui le vedo:

1. Immagini e video senza dimensioni. Senza un’altezza riservata, tutto ciò che sta sotto salta quando il contenuto multimediale si carica.
2. Annunci, embed e iframe senza spazio riservato. Le reti pubblicitarie distribuiscono dimensioni dinamiche e gli embed non dichiarano la propria altezza prima di caricarsi.
3. Contenuti inseriti dinamicamente sopra contenuti esistenti. Banner dei cookie, barre di notifica, widget “correlati”, promozioni caricate tardi: tutto ciò che spinge verso il basso quello che è già sullo schermo.
4. Font web (FOIT/FOUT). Quando il font personalizzato sostituisce il fallback, il testo si ridistribuisce se le metriche sono diverse.
5. Animazioni su proprietà che attivano il layout. Animare top, left, margin, box-shadow o box-sizing obbliga il browser a ricalcolare il layout della pagina a ogni frame.

Le correzioni

Ogni correzione rispecchia la propria causa:

• Immagini/video — riserva lo spazio. Imposta gli attributi width e height così il browser calcola il rapporto d’aspetto e mantiene il riquadro; abbinali a img { height: auto; width: 100%; } per il comportamento responsive, oppure usa la proprietà CSS aspect-ratio. Nella maggior parte dei siti è la correzione CLS con il maggior effetto.
• Annunci/embed/iframe — riserva lo spazio anche qui. Usa min-height o aspect-ratio sul contenitore; per gli spazi pubblicitari, la guida Google Publisher Tag è netta: “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” Per gli spazi con più dimensioni, riserva quella della dimensione configurata più grande. Sposta più in basso i contenuti caricati tardi, così ogni spostamento residuo resta sotto la piega.
• Contenuti dinamici — non inserirli nel flusso. Riserva un segnaposto della dimensione finale oppure sovrapponi il contenuto invece di inserirlo. Gli skeleton loader aiutano solo se corrispondono esattamente alle dimensioni finali: anche uno skeleton più corto di pochi pixel rispetto al contenuto reale provoca uno spostamento. Preferisci caricamenti attivati dall’utente (“Carica altro”) alle inserzioni a sorpresa.
• Font — abbina le metriche. font-display: optional è l’unico valore con un rischio CLS effettivamente nullo; swap riduce al minimo il testo invisibile ma può provocare uno spostamento durante il cambio. Meglio ancora, usa gli override delle metriche CSS — size-adjust, ascent-override, descent-override, line-gap-override — per dimensionare il font fallback in modo che corrisponda al web font e rendere il cambio impercettibile. Precarica i font critici.
• Animazioni — solo transform. Anima con transform (translate, scale, rotate) invece di top/left/margin. Le animazioni basate su transform vengono composte e non attivano il layout, quindi non spostano nulla.

Come il CLS si inserisce nel ranking (con la giusta proporzione)

CLS è uno degli input del segnale page experience di Google. Google dice che i Core Web Vitals sono usati dai suoi sistemi di ranking, ma la documentazione attuale della Ricerca non pubblica un peso CLS preciso, una regola di spareggio o una garanzia di ranking; quindi considera ogni meccanismo specifico (incluso “è uno spareggio”) un’approssimazione operativa, non un fatto documentato. Il mio consiglio costante su tutto ciò che scrivo sui Core Web Vitals è: entra nella fascia “good” e vai avanti. La maggior parte dei siti non vedrà un aumento significativo di ranking o di risultati aziendali portando 0,08 a 0,02, e un singolo punteggio raramente spiega da solo un risultato di ricavi o conversioni. Il CLS è una condizione minima: vuoi superare la soglia, ma non dovrebbe diventare il fulcro del programma SEO a discapito di LCP, INP o, francamente, dei tuoi contenuti.

Due note operative che evitano molta confusione:

• CrUX è indietro di circa 28 giorni. È una finestra mobile di 28 giorni, quindi una correzione distribuita oggi non si registrerà completamente in PageSpeed Insights o Search Console per settimane. Non allarmarti se il numero non cambia la mattina dopo.
• L’elemento attribuito spesso non è la causa principale. La Layout Shift Attribution API indica quale elemento si è spostato, ma come osserva web.dev, “it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” Il testo che salta è di solito la vittima di un’immagine senza dimensioni sopra che si carica tardi: correggi la causa, non il sintomo. Trattalo come un ciclo timestamp-trigger: annota l’ora d’inizio dello spostamento, poi controlla che cos’altro sia cambiato nella stessa finestra — una richiesta di rete completata, l’arrivo di un’immagine o di un font, un ridimensionamento o una modifica di classe/stile — e considera il nodo attribuito un indizio, non una prova, finché non lo hai collegato a quel trigger.

Riepilogo AI

Una sintesi della versione Advanced:

• CLS = stabilità visiva, il Core Web Vital per il movimento inatteso dei contenuti visibili. Si affianca a Largest Contentful Paint e Interaction to Next Paint.
• È un punteggio senza unità, non un tempo. 0,05 è un rapporto, non 50 ms.
• Formula per ogni spostamento: impact fraction × distance fraction — quanta parte della viewport si è mossa, moltiplicata per quanto si è spostata rispetto alla dimensione maggiore della viewport.
• La metrica è la finestra di sessione più grande (≤ 1 s tra gli spostamenti, ≤ 5 s per l’intera finestra), non la somma sulla vita della pagina. Il cambiamento è avvenuto nel giugno 2021 per smettere di penalizzare le pagine longeve e le SPA; è stato scelto il massimo invece della media.
• Soglie (75° percentile, dati sul campo): Good ≤ 0,1 · Needs improvement ≤ 0,25 · Poor > 0,25.
• Esclusioni: gli spostamenti sotto la piega non contano; quelli entro 500 ms da un input discreto (tocco/clic/tasto) sono esclusi — lo scrolling non è esente.
• Cause: immagini/video/annunci/iframe/embed senza dimensioni; contenuti inseriti sopra contenuti esistenti; font web; animazioni su proprietà che attivano il layout.
• Correzioni: imposta width/height o aspect-ratio; riserva spazio per i contenuti dinamici (gli skeleton devono avere dimensioni esatte); font-display + size-adjust; anima solo con transform.
• Laboratorio ≠ campo. Lighthouse legge spesso valori vicini a 0 perché non interagisce con la pagina e non esegue l’intero ciclo di vita; i dati sul campo (CrUX/PageSpeed Insights) sono quelli su cui Google fa il ranking. Gli spostamenti degli iframe di solito non si propagano al punteggio del documento padre né negli strumenti di laboratorio né in quelli RUM.
• Ranking: è uno degli input che Google dice di usare nella page experience; non esistono un peso o una regola di spareggio documentati, quindi raggiungi “good” e vai avanti invece di inseguire un meccanismo specifico. CrUX è indietro di circa 28 giorni; l’elemento attribuito spesso non è la causa principale.

Documentazione ufficiale

Documentazione primaria di Google e del team Chrome.

Documenti CLS principali

• Cumulative Layout Shift (CLS) — definizione canonica, formula impatto × distanza, finestre di sessione, soglie ed esclusione hadRecentInput (Milica Mihajlija e Philip Walton).
• Ottimizzare Cumulative Layout Shift — guida ufficiale a cause e correzioni: immagini, annunci/embed, contenuti inseriti, font e animazioni.
• Eseguire il debug dei layout shift — come trovare gli spostamenti in Chrome DevTools, overlay Layout Shift Regions e API LayoutShiftAttribution (Katie Hempenius e Barry Pollard).

Contesto e misurazione

• L’evoluzione di Cumulative Layout Shift negli strumenti web — perché la metrica è passata dalla somma di tutti gli spostamenti alla finestra di sessione più grande nel giugno 2021 (Annie Sullivan e Hongbo Song, Chrome Speed Metrics Team).
• Come sono state definite le soglie delle metriche Core Web Vitals — ricerca sugli utenti e dati di raggiungibilità alla base delle fasce 0,1 / 0,25.
• Iniziare a misurare i Web Vitals — dati di laboratorio e sul campo e motivo per cui il CLS di laboratorio può risultare artificialmente basso.
• Best practice per i font — font-display, override delle metriche e precaricamento per il CLS legato ai font.

Annunci e Ricerca

• Ridurre al minimo il layout shift — indicazioni Google Publisher Tag per riservare spazio agli slot pubblicitari.
• Capire i Core Web Vitals e i risultati di Google Search — come i CWV (incluso CLS) entrano nella Ricerca.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e del team Chrome. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente.

Google — che cos’è il 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.” Vai alla citazione
• “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” Vai alla citazione

Google — la formula

• “layout shift score = impact fraction * distance fraction” Jump to quote
• “The impact fraction measures how unstable elements impact the viewport area between two frames.” Jump to quote
• “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).” Jump to quote

Google — la finestra di sessione

• “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.” Vai alla citazione

Google — soglie e input dell’utente

• “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.” Vai alla citazione
• “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” Vai alla citazione
• “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.” Vai alla citazione

Google — come sono state scelte le soglie

• “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.” Vai alla citazione

Google — riservare spazio agli slot pubblicitari

• “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” Vai alla citazione

Google — elemento attribuito e causa principale

• “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.” Jump to quote

Checklist cause → correzioni del CLS

Procedi dall’alto verso il basso: i primi due elementi risolvono la maggior parte dei CLS reali.

• Ogni <img> e <video> ha width + height (o un aspect-ratio CSS), con img { height: auto; width: 100%; } per i layout responsive.
• Gli slot pubblicitari, gli iframe e gli embed riservano spazio tramite min-height / aspect-ratio; gli slot con più dimensioni riservano quella della dimensione configurata più grande.
• I contenuti caricati tardi restano sotto la piega quando possibile, così ogni spostamento residuo non conta.
• I contenuti inseriti (banner cookie, promozioni, widget “correlati”) vengono sovrapposti o pre-riservati, non inseriti sopra contenuti esistenti.
• I placeholder skeleton corrispondono alle dimensioni esatte del contenuto finale (anche pochi pixel di differenza causano uno spostamento).
• I font web usano font-display: optional quando accettabile, oppure swap con size-adjust / ascent-override per allineare le metriche del fallback; i font critici vengono precaricati.
• Le animazioni usano solo transform, mai top, left, margin, box-shadow o box-sizing.
• Hai controllato il punteggio nei dati sul campo (PageSpeed Insights / Search Console / CrUX), non solo in Lighthouse.
• Hai riprodotto gli spostamenti interagendo con la pagina — scrolling, apertura dei menu, attivazione dei caricamenti lazy — non solo durante il caricamento iniziale.
• Gli spostamenti di annunci/iframe sono verificati sul campo (gli strumenti di laboratorio spesso non li propagano al punteggio del documento padre).

Scheda rapida CLS

I numeri

La definizione, in una riga

• layout shift score = impact fraction × distance fraction (per ogni spostamento).
• CLS = la finestra di sessione più grande degli spostamenti — ≤ 1 s tra gli spostamenti, ≤ 5 s per l’intera finestra. Non la somma sulla vita della pagina (era così prima di giugno 2021).
• È un punteggio senza unità, non un tempo.

Che cosa è escluso

• Spostamenti sotto la piega (non nella viewport corrente).
• Spostamenti entro 500 ms da un input discreto (tocco/clic/pressione di un tasto) — hadRecentInput.
• Non sono esclusi: spostamenti durante lo scrolling o il pinch (gesti continui).

Cause → correzioni

Insidie della misurazione

• Lighthouse (laboratorio) legge spesso circa 0: non interagisce con la pagina e non esegue l’intero ciclo di vita. CrUX / PageSpeed Insights (campo) è ciò su cui Google fa il ranking.
• CrUX è indietro di circa 28 giorni: le correzioni impiegano settimane per comparire.
• Gli iframe di solito non propagano gli spostamenti al punteggio del documento padre negli strumenti di laboratorio.
• L’elemento attribuito è quello che si è spostato, non necessariamente la causa principale.

Strumenti per misurare e diagnosticare il CLS

Dati sul campo (quelli usati da Google per il ranking)

• PageSpeed Insights — CLS CrUX sul campo a livello di pagina e di origin, più un’esecuzione Lighthouse di laboratorio affiancata. È il modo più rapido per vedere di persona la differenza laboratorio-campo.
• Search Console — report Core Web Vitals — CLS sul campo per gruppi di URL nell’intero sito, raggruppati per stato.
• CrUX (Chrome User Experience Report) — il dataset sottostante sul campo; esplora lo storico tramite dashboard CrUX / BigQuery.

Dati di laboratorio (per il debugging)

• Chrome DevTools — pannello Performance — registra una traccia e poi leggi la traccia Layout Shifts; facendo clic su uno spostamento evidenzi gli elementi mossi e ne vedi il punteggio. Live Metrics aggiorna il CLS in tempo reale mentre interagisci.
• Overlay Layout Shift Regions — DevTools → Impostazioni → Altri strumenti → Rendering → Layout Shift Regions. Ricarica la pagina e le aree che si spostano lampeggiano, così puoi vederle.
• Lighthouse — CLS di laboratorio rapido, ma ricorda che cattura solo gli spostamenti del caricamento iniziale.
• WebPageTest — CLS di laboratorio con filmstrip e traccia.

RUM (i tuoi dati sul campo)

• Libreria JavaScript web-vitals — onCLS() riporta il CLS degli utenti reali dai tuoi visitatori (circa 2 KB); è il quadro più accurato di ciò che le persone sperimentano davvero.
• PerformanceObserver (layout-shift) — l’API grezza avvolta dalla libreria, più le sources di LayoutShiftAttribution che indicano quali elementi si sono spostati.

Come si valutano gli strumenti stessi

Ecco un esempio reale della metrica descritta in questa pagina: servizi noti di velocità e monitoraggio ordinati in base al loro CLS mobile reale degli utenti (dati CrUX sul campo del Chrome UX Report):

Quale correzione CLS dovresti fare per prima?

Errori CLS che nascondono il vero problema

Trattare un’esecuzione Lighthouse pulita come una prova

Lighthouse può terminare prima che si verifichi uno spostamento causato da un banner di consenso, da un annuncio o da un’interazione. Usa l’esecuzione di laboratorio per diagnosticare il problema, ma controlla CrUX o il tuo monitoraggio degli utenti reali prima di dichiararlo risolto.

Correggere solo l’elemento che DevTools dice essersi spostato

L’elemento spostato è spesso la vittima. La causa può essere un elemento caricato tardi sopra di esso. Riproduci la traccia e controlla che cosa è entrato o si è ridimensionato subito prima del movimento.

Riservare spazio con un’altezza fissa arbitraria

Un placeholder fisso può creare un secondo spostamento quando il contenuto responsive è più alto o più basso. Usa dimensioni intrinseche o aspect-ratio quando conosci le proporzioni del contenuto.

Animare le proprietà del layout

Cambiare top, left o i margini può spostare il contenuto circostante. Anima con transform quando l’effetto non deve modificare il flusso del documento.

Diagnosticare un problema CLS dal sintomo

Il CLS sul campo è scarso ma il punteggio di laboratorio è quasi zero

Probabile causa: lo spostamento avviene dopo un’interazione, durante una sessione più lunga o solo per un sottoinsieme di utenti. Correzione: riproduci il percorso reale registrando il pannello Performance, poi aggiungi l’attribuzione web-vitals nel monitoraggio degli utenti reali. Conferma: l’interazione responsabile e l’elemento spostato compaiono nella traccia o nel record RUM.

Il testo salta quando arriva il font personalizzato

Probabile causa: font fallback e web font usano metriche diverse. Correzione: precarica solo il font critico quando opportuno e adatta il fallback con gli override delle metriche del font. Conferma: ripeti il test con la cache disattivata e verifica che la traccia Layout Shifts non registri più il cambio.

Un banner o un annuncio spinge la pagina verso il basso

Probabile causa: lo slot non ha dimensioni riservate prima che arrivi il contenuto. Correzione: assegna un contenitore stabile o posiziona il messaggio dove non sposta il contenuto visibile. Conferma: rallenta il caricamento e osserva che lo slot mantenga la propria impronta.

Il CLS migliora nei test ma non in PageSpeed Insights

Probabile causa: CrUX è un dataset sul campo mobile, non un controllo immediato del deploy. Correzione: verifica prima la modifica in laboratorio e nel RUM, poi aspetta il ricambio della finestra sul campo. Conferma: la distribuzione sul campo dopo il rilascio migliora nel tuo monitoraggio prima che segua l’aggregato CrUX pubblico.

Catturare i layout shift nel browser

Incolla questo nella Console di DevTools prima di riprodurre il problema. Ignora gli spostamenti collegati a input recenti dell’utente e stampa il punteggio insieme agli elementi attribuiti dal browser.

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 });

Il nodo attribuito è un indizio, non una prova automatica della causa. Confronta il suo timestamp con le richieste di rete, il caricamento dei font e gli inserimenti nel DOM nella stessa traccia.

Dimostrare che una correzione CLS ha funzionato

Test dello spazio riservato

Test da eseguire: disabilita la cache, rallenta la connessione, ricarica e registra la traccia Layout Shifts del pannello Performance. Risultato atteso: il contenuto multimediale o l’embed mantiene la stessa impronta prima e dopo il caricamento. Interpretazione del fallimento: il contenitore dipende ancora dal contenuto tardivo per le proprie dimensioni. Finestra di monitoraggio: immediata nella traccia. Trigger di rollback: il nuovo placeholder crea ritagli, spazio bianco eccessivo o un nuovo spostamento a un breakpoint responsive.

Test del cambio di font

Test da eseguire: ricarica con la cache disabilitata mentre osservi il testo e la traccia Layout Shifts. Risultato atteso: il passaggio dal font fallback al web font non crea uno spostamento misurabile. Interpretazione del fallimento: le metriche del fallback sono ancora diverse oppure il font critico arriva troppo tardi. Finestra di monitoraggio: immediata nelle esecuzioni di laboratorio ripetute. Trigger di rollback: la modifica nasconde il testo più a lungo o rende la tipografia finale materialmente errata.

Conferma sul campo

Test da eseguire: confronta i dati onCLS() dopo il rilascio per il template modificato con la baseline precedente, poi osserva CrUX. Risultato atteso: il p75 degli utenti reali migliora senza una coda peggiore nei percorsi chiave. Interpretazione del fallimento: resta un’altra causa tardiva o attivata da un’interazione. Finestra di monitoraggio: RUM mentre arriva traffico; CrUX sulla sua finestra mobile di 28 giorni. Trigger di rollback: CLS o gli errori di interazione peggiorano in modo costante dopo il rilascio.

Metriche CLS da seguire

CLS degli utenti reali al p75

Metrica: CLS al 75° percentile per ogni template importante e classe di dispositivo. Cosa indica: se la maggior parte delle visite raggiunge l’obiettivo di stabilità visiva. Come recuperarla: CrUX, PageSpeed Insights o RUM web-vitals. Benchmark / intervallo realistico: buono è 0,1 o meno; da 0,1 a 0,25 necessita miglioramenti; oltre 0,25 è scarso. Cadenza: monitora i rilasci nel RUM e rivedi mensilmente la tendenza mobile sul campo.

Tasso di visite scarse

Metrica: quota di visite reali con CLS superiore a 0,25. Cosa indica: se un p75 accettabile nasconde una coda dannosa. Come recuperarla: raggruppa gli eventi onCLS() per template e percorso. Benchmark / intervallo realistico: stabilisci una baseline del sito e riduci la fascia scarsa; la composizione del traffico rende fuorviante un obiettivo universale. Cadenza: settimanale per i template ad alto traffico e dopo i rilasci di layout.

Attribuzione degli spostamenti per causa

Metrica: voci di layout shift raggruppate per elemento o componente. Cosa indica: quale implementazione ricorrente possiede la quota maggiore di instabilità. Come recuperarla: build con attribuzione di web-vitals o PerformanceObserver. Benchmark / intervallo realistico: non esiste un intervallo universale; confronta i componenti per impatto totale e visite interessate. Cadenza: rivedi il dato a ogni rilascio di template o componente.

Risorse che meritano il tuo tempo

Ufficiali, approfondite

• Cumulative Layout Shift (CLS) — il riferimento canonico.
• Ottimizzare Cumulative Layout Shift — la guida ufficiale alle correzioni.
• Eseguire il debug dei layout shift — il flusso di lavoro DevTools.
• L’evoluzione di Cumulative Layout Shift negli strumenti web — il cambiamento alla finestra di sessione del giugno 2021, spiegato dal team che lo ha realizzato.

Da professionisti

• Come correggere i problemi di Cumulative Layout Shift (CLS) — Barry Pollard, Smashing Magazine. Approfondisce i descrittori dei font e il problema per cui “l’elemento che si è spostato non è la causa principale”.
• Cumulative Layout Shift nella pratica — Nic Jansma (Cloudflare; W3C Web Performance WG). Il miglior approfondimento sulle sfumature della misurazione: lacune nell’attribuzione degli iframe, campione di attribuzione dei 5 elementi e discrepanze tra strumenti.
• Misurare e ottimizzare Cumulative Layout Shift — DebugBear.
• La guida quasi completa a Cumulative Layout Shift — Jess Peck. Tratta in dettaglio i casi limite, inclusi gli spostamenti durante la navigazione SPA e le sfumature dell’esclusione dei gesti continui.
• Cause dei layout shift — documentazione Chrome DevTools sul pannello dell’insight CLS culprit, utile insieme alla guida di debug di web.dev.
• Come correggere Cumulative Layout Shift (CLS) — Kinsta. Procedura pratica orientata ai CMS, con le cause specifiche di WordPress (immagini delle gallerie, widget caricati tardi e banner dei cookie).
• Layout Instability API — specifica WICG. L’API del browser alla base del CLS, utile per costruire un RUM personalizzato o avere la semantica esatta di hadRecentInput.

Dove si colloca nel mio lavoro

• Il CLS è una metrica “di base” in tutta la mia copertura dei Core Web Vitals: monitoralo, portalo nella fascia good e mantienilo proporzionato rispetto a LCP, INP e ai tuoi contenuti. Google non pubblica un peso CLS preciso né una regola di spareggio, quindi è un input da osservare, non l’intera partita.

Statistiche da citare

• La soglia di 0,1 si basa sulla ricerca della percezione. Gli studi sugli utenti di Google hanno rilevato: “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.” (in italiano: gli spostamenti di 0,15 e oltre venivano percepiti costantemente come fastidiosi, mentre quelli di 0,1 o meno erano percepibili ma non eccessivamente disturbanti). Fonte
• Il CLS è il Core Web Vital più facile da superare. Nei miei audit enterprise il modello è costante: una grande maggioranza dei siti supera la soglia CLS (spesso circa l’80 % o più), ma solo poco più della metà supera tutti e tre i vital insieme; raramente è il CLS a bloccarti.
• Il cambiamento del giugno 2021 ha aiutato, non danneggiato. Quando CLS è passato alla finestra di sessione più grande, nessun origin ha ricevuto un punteggio peggiore, la maggior parte non ha visto cambiamenti e una parte delle pagine con scrolling infinito o UI lenta è migliorata. Fonte
• I contenuti multimediali senza dimensioni sono ancora ovunque. I crawl del settore (Web Almanac) trovano costantemente una grande quota di pagine che pubblicano immagini senza dimensioni esplicite: la causa CLS più comune e la più semplice da correggere.
• Il 72 % dei siti web nel mondo raggiunge oggi un CLS buono (dati Web Almanac / HTTP Archive 2025), rendendo CLS il Core Web Vital più facile da superare; tuttavia il 62 % delle pagine mobile pubblica ancora almeno un’immagine senza dimensioni esplicite, la causa più comune. Fonte: HTTP Archive / Web Almanac
• Impatto aziendale: Rakuten 24 ha riportato un aumento del 53,37 % dei ricavi per visitatore per gli utenti con CLS basso rispetto a quelli con CLS alto: un caso di studio citato spesso, non una prova che un determinato numero CLS causi uno specifico risultato commerciale su altri siti. Fonte: casi di studio corewebvitals.io

Video

• Google Search Central / Chrome for Developers (YouTube) — video su Core Web Vitals e Debug layout shifts, inclusi i walkthrough DevTools della traccia Layout Shifts e dell’overlay Layout Shift Regions. Canale

Mettiti alla prova: Cumulative Layout Shift

Cinque domande rapide sulla misurazione e sulla correzione dell’instabilità visiva. Scegli una risposta per ciascuna e poi controlla.

Cronologia modifiche