Risolvere e Identificare i Problemi di Cumulative Layout Shift (CLS)

Prima di cambiare qualsiasi cosa, conferma di avere effettivamente un problema di CLS. Accedi a Google Search Console, vai su Core Web Vitals e controlla sia dispositivi mobili che desktop.

Se Google segnala URL con "Problema CLS: superiore a 0.25" o "Problema CLS: superiore a 0.1", hai la conferma dal Chrome User Experience (CrUX) Report che gli utenti reali stanno subendo spostamenti di layout sul tuo sito.

A differenza di LCP e INP, dove la potenza di calcolo grezza e la velocità di rete contano, i problemi di CLS possono essere specifici per dispositivo o per dimensione dello schermo. Quando un problema simile riguarda dispositivi mobili e desktop (immagini senza dimensioni, scambi di font, contenuti iniettati), a causa delle dimensioni dello schermo, il desktop potrebbe segnalare un valore CLS molto più alto (perché potrebbe essere interessata una parte più ampia del viewport visibile). Search Console raggruppa gli URL insieme, quindi ti dice quali tipi di pagina sono interessati ma non quali elementi si stanno spostando. Per quello ti serve il Real User Monitoring.

Search Console conferma l'esistenza del problema ma non ti dà quasi nulla su cui lavorare. Devi scoprire quali elementi si spostano, su quali pagine e in quali condizioni. Per questo ti serve uno strumento RUM.

Ho creato CoreDash per rispondere esattamente a queste domande. Aggiungi un tag script e inizia a raccogliere i dati di attribuzione del CLS da ogni visitatore reale. Il punto dati chiave per il debug del CLS è l'elemento che si sposta: il vero nodo DOM che si è mosso. Senza queste informazioni stai facendo debug alla cieca.

Trovare gli elementi che si spostano

Inizia guardando i tuoi dati CLS raggruppati per elemento. In CoreDash, vai alla pagina del CLS e visualizza la tabella dati ordinata per "CLS per Elemento". Questo mostra quali elementi causano il maggior spostamento di layout tra tutti i tuoi visitatori. Clicca su quello peggiore per filtrare tutte le metriche per le pagine in cui quell'elemento si è spostato.

Trovare quali pagine sono interessate

Dopo aver filtrato in base all'elemento che si sposta con il maggiore impatto, controlla la ripartizione degli URL. I problemi di CLS potrebbero riguardare l'intero sito o interi template. Ora sappiamo se il CLS è concentrato su tipi di pagina specifici: pagine di prodotto con gallerie di immagini, articoli di blog con slot pubblicitari o landing page con animazioni hero. Sapere quali pagine falliscono ti dice dove concentrarti.

Controllare i nuovi visitatori rispetto ai visitatori di ritorno

Questo è un altro controllo rapido che faccio e conta molto più di quanto la maggior parte delle persone pensi. Il CLS dovuto allo scambio di font si verifica solo quando il font non è nella cache. Il CLS delle immagini dovuto a width: auto si verifica solo quando l'immagine non è nella cache del browser. Se il tuo CLS è molto peggiore per i visitatori per la prima volta, hai a che fare con uno spostamento dipendente dalla cache che tu, come sviluppatore, non vedrai mai sulla tua macchina a meno che non disabiliti la cache (suggerimento: disabilita sempre la cache di Chrome... ma questa è un'altra storia per un altro giorno).

Controllare i tipi di dispositivo e le dimensioni del viewport

Il CLS in genere mostra un altro modello mobile/desktop rispetto a LCP e INP. I layout responsivi possono introdurre spostamenti che compaiono solo a larghezze e altezze specifiche del viewport. Uno slot pubblicitario che ha causato problemi su desktop potrebbe non essere nemmeno nel viewport mobile. Un menu di navigazione potrebbe animarsi in modo diverso nei breakpoint più piccoli. Raggruppa i tuoi dati CLS per tipo di dispositivo per sapere dove si verificano.

I tuoi dati RUM ti hanno detto quali elementi si spostano e perché. Ora riproduci il problema localmente e scopri cosa lo sta causando.

Utilizzare il Core Web Vitals Visualizer

Il modo più veloce per vedere gli spostamenti di layout è con l'estensione Chrome Core Web Vitals Visualizer. Carica la pagina, clicca sull'icona dell'estensione e ricarica. Ogni spostamento di layout viene evidenziato con una sovrapposizione colorata che mostra esattamente cosa si è mosso e di quanto. Lo uso come mio primo passo prima di aprire il pannello Performance perché dà una risposta visiva immediata.

Replicare le condizioni in Chrome e controllare gli screenshot di rete

I problemi di CLS sono spesso invisibili con una cache calda. Apri DevTools, disabilita la cache nella scheda Network (Rete) e limita la connessione a "Slow 4G" (la mia preferita, ti mostrerà il CLS causato dalle race conditions). Ora fai clic sull'icona a forma di ingranaggio e disabilita la cache (mentre DevTools è aperto). Questo simula le condizioni sperimentate dai tuoi visitatori per la prima volta. Vai alla scheda network e abilita gli screenshot. Ora ricarica la pagina e osserva gli spostamenti.

Utilizzare il pannello Performance di Chrome

La maggior parte degli spostamenti di layout è facile da individuare quando sai come fare, ma a volte ti sfuggiranno. Quello è il momento di aprire Chrome DevTools (Ctrl+Shift+I) e andare al pannello Performance per un debug dettagliato. Premi Ctrl+Shift+E per ricaricare e registrare. Dopo il caricamento della pagina, scorri su e giù un paio di volte. Ferma la registrazione.

Cerca la traccia "Layout Shifts". Ogni spostamento appare come un blocco colorato. Clicca su uno spostamento per vedere:

• Il nodo che si sposta: l'elemento DOM che si è mosso
• Il punteggio dello spostamento: la frazione di impatto moltiplicata per la frazione di distanza
• hadRecentInput: se l'input dell'utente ha preceduto lo spostamento (i clic e i tocchi ottengono un periodo di grazia di 500ms, ma lo scorrimento no)

Presta attenzione a quando avvengono gli spostamenti. Gli spostamenti durante il caricamento della pagina puntano a immagini senza dimensioni, scambi di font o transizioni CSS. Gli spostamenti durante lo scorrimento puntano a animazioni attivate dallo scorrimento che utilizzano proprietà di layout.

Test rapido: disabilita tutte le transizioni

Le transizioni CSS che animano le proprietà di layout sono una causa subdola di CLS perché si spostano solo durante la fase di caricamento e sono difficili da riprodurre. Incolla questo snippet nella console, esegui un hard-reload della pagina con la cache disabilitata e confronta il CLS:

document.head.insertAdjacentHTML('beforeend',
  '<style>*{transition-property:none!important}</style>');

Se il tuo CLS scende dopo aver disabilitato le transizioni, hai trovato la causa. Usa la guida al debug delle transizioni CSS per trovare le transizioni specifiche responsabili.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log('Layout shift:', {
        value: entry.value,
        sources: entry.sources?.map(s => ({
          node: s.node,
          previousRect: s.previousRect,
          currentRect: s.currentRect
        }))
      });
    }
  }
});
observer.observe({ type: 'layout-shift', buffered: true });

Sai quali elementi si spostano e perché. È il momento di risolverli. Il CLS non ha fasi sequenziali come il LCP. Piuttosto, gli spostamenti di layout hanno distinte categorie di cause. Ecco le più comuni, nell'ordine in cui le incontro durante gli audit.

1. Immagini, Video e Iframe Senza Dimensioni

Questa è la causa numero uno del CLS sul web. Il Web Almanac 2025 riporta che il 62% delle pagine mobili ha almeno un'immagine senza dimensioni. La soluzione: includi sempre gli attributi width e height sui tag <img>, <video> e <iframe>.

<img src="hero.jpg" width="800" height="450" alt="Descrizione">

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

Fai attenzione a width: auto nel tuo CSS. Questa singola dichiarazione sovrascrive il calcolo delle proporzioni del browser e causa spostamenti di layout anche quando hai impostato larghezza e altezza nell'HTML. L'ho visto su decine di siti. Lo sviluppatore ha fatto tutto bene nel markup, ma una regola CSS globale come img { width: auto; height: auto; max-width: 100%; } ha annullato tutto. Per la spiegazione completa, vedi risolvere gli spostamenti di layout causati da immagini con auto-dimensionamento. Per una guida completa che copre tutte le cause di CLS di immagini e media (video, iframe, art direction, immagini responsive, lazy loading, placeholder), vedi Come le Immagini e i Media Causano Spostamenti di Layout.

2. Scambi di Web Font

Quando un web font viene caricato e sostituisce il font di fallback, la differenza di dimensioni causa uno spostamento di layout. Il Web Almanac 2025 mostra che solo l'11% delle pagine precarica i web font. Questo significa che la stragrande maggioranza dei siti è vulnerabile al CLS da scambio di font.

La soluzione ha due parti. Primo, fai in modo che il font di fallback corrisponda alle dimensioni del web font utilizzando i metric overrides:

<style>
@font-face {
    font-family: 'Il Mio Font di Fallback';
    src: local('Arial');
    size-adjust: 105.2%;
    ascent-override: 93%;
    descent-override: 24%;
    line-gap-override: 0%;
}

@font-face {
    font-family: 'Il Mio Font';
    src: url('/fonts/myfont.woff2') format('woff2');
    font-display: swap;
}

body {
    font-family: 'Il Mio Font', 'Il Mio Font di Fallback', sans-serif;
}
</style>

Usa un Fallback Font Generator per calcolare i valori di override corretti per la tua combinazione di font. Secondo, velocizza la consegna: ospita tu stesso i tuoi font, precarica il tuo file di font critico e usa WOFF2 con il subsetting. Per una strategia completa, vedi caricamento responsivo dei web font e assicurarsi che il testo rimanga visibile durante il caricamento del web font.

3. Animazioni e Transizioni CSS

Secondo il Web Almanac 2025, il 40% delle pagine mobili esegue animazioni non composte (non-composited). Queste animano proprietà come width, height, top, left, margin e padding che innescano il ricalcolo del layout ad ogni frame.

Il colpevole più comune è transition: all. Quando uno sviluppatore scrive transition: all .3s ease, ogni modifica delle proprietà viene animata, incluse le proprietà di layout. Durante il caricamento della pagina, gli elementi che passano dal loro stato senza stile allo stato con stile producono spostamenti di layout che avvengono in modo intermittente e sono quasi impossibili da riprodurre con coerenza. Vedo questo schema di continuo.

La soluzione: sostituisci le proprietà che innescano il layout con proprietà composte.

• Usa transform: translateY() invece di top/bottom
• Usa transform: translateX() invece di left/right
• Usa transform: scale() invece di width/height
• Usa opacity invece di visibility in combinazione con i cambiamenti di altezza
• Non usare mai transition: all. Specifica l'esatta proprietà: transition: background-color .2s ease

transform e opacity vengono eseguiti interamente sul thread del compositore e non innescano mai il layout. Per il processo di debug completo, vedi spostamento di layout causato dalle transizioni CSS.

4. Annunci, Elementi Incorporati e Contenuti Iniettati Dinamicamente

Gli annunci caricano tardi e spingono il contenuto verso il basso. I banner per il consenso ai cookie appaiono e spostano la pagina. Le richieste AJAX iniettano nuovi contenuti senza prima riservare spazio. Sono tutti lo stesso problema: qualcosa appare sulla pagina che il browser non conosceva al momento del rendering.

La soluzione per tutti questi casi è riservare spazio. Per gli slot pubblicitari, imposta una min-height corrispondente alla dimensione prevista dell'annuncio:

<style>
.ad-slot {
    min-height: 250px;
    contain: layout style;
}
@media (min-width: 600px) {
    .ad-slot { min-height: 90px; }
}
</style>

La dichiarazione contain: layout style isola il contenitore dell'annuncio dal resto della pagina. Per i banner dei cookie, usa position: fixed per sovrapporli invece di spingere il contenuto verso il basso. Per i contenuti AJAX, riserva spazio con min-height. Non hai bisogno di un'ipotesi esatta: una discrepanza di 50px rappresenta un CLS molto inferiore rispetto a uno spostamento di 400px dovuto all'assenza di spazio riservato.

Per gli elementi incorporati di terze parti come YouTube, Google Maps e widget di chat, usa il pattern facade: mostra un placeholder statico e carica l'elemento reale solo quando l'utente vi interagisce. Zero CLS, zero risorse sprecate.

5. Spostamenti di Layout Attivati dallo Scorrimento

Questa è la causa di CLS che Lighthouse non individuerà mai. Lighthouse non scorre la pagina, quindi gli spostamenti di layout attivati dallo scorrimento sono completamente invisibili nei test di laboratorio. L'unico modo per trovarli è con i dati RUM o registrando una traccia nel pannello Performance durante lo scorrimento manuale.

L'esempio più comune è un'intestazione che si nasconde allo scorrimento e anima la proprietà top. Ecco la cosa che la maggior parte degli sviluppatori non sa: lo scorrimento non è un input escludente nella specifica Layout Instability. I clic e i tocchi ottengono un periodo di grazia di 500ms. Lo scorrimento no. Ogni spostamento di layout attivato dallo scorrimento conta per il tuo punteggio CLS.

La soluzione: usa transform: translateY() invece di top per qualsiasi animazione attivata dallo scorrimento. Lo stesso vale per gli effetti parallasse, le barre di navigazione che si rimpiccioliscono e le barre di avanzamento collegate allo scorrimento. Se si muove durante lo scorrimento, animalo con transform. Per la spiegazione completa con esempi video, vedi come le animazioni attivate dallo scorrimento causano il CLS.