Se hai mai iniziato a leggere una pagina e, un attimo dopo, un banner, un’immagine o un altro elemento ha spinto improvvisamente il testo verso il basso, hai già sperimentato il problema che il Cumulative Layout Shift (CLS) cerca di misurare.
Il CLS è uno dei Core Web Vitals e descrive la stabilità visiva di una pagina. Non misura quanto velocemente viene caricata, ma quanto il contenuto visibile cambia posizione in modo inatteso mentre l’utente sta utilizzando la pagina. Google considera buono un valore pari o inferiore a 0,1, valutato sul 75° percentile delle visite e distinguendo mobile e desktop. La definizione corrente è però più precisa della vecchia idea secondo cui il CLS sarebbe semplicemente la somma di tutti gli spostamenti avvenuti sulla pagina.
Capire questa differenza è importante perché un valore alto non ti dice automaticamente cosa devi ottimizzare. Immagini prive di dimensioni, font, iframe, banner, contenuti caricati successivamente e animazioni possono produrre lo stesso sintomo attraverso meccanismi differenti. La procedura utile è quindi: misurare il problema reale, riprodurlo, individuare l’elemento o il comportamento che genera lo spostamento, correggerne la causa e verificare di nuovo.
Cos’è il Cumulative Layout Shift e cosa misura davvero
Il Cumulative Layout Shift è una metrica senza unità di misura che quantifica gli spostamenti inattesi degli elementi visibili nel viewport. La definizione ufficiale di CLS su web.dev considera il burst di layout shift con il punteggio cumulativo più elevato che si verifica durante l’intero ciclo di vita della pagina.
La parola importante è inattesi.
Se un paragrafo scende perché sopra di esso compare improvvisamente un annuncio che non aveva spazio riservato, stai osservando un layout shift problematico. Se invece premi un controllo e l’interfaccia cambia immediatamente come conseguenza prevedibile della tua azione, il comportamento può essere trattato diversamente dalla metrica.
Questo spiega anche perché il CLS non è sinonimo di “pagina che cambia”. Le interfacce moderne devono cambiare: menu si aprono, prodotti vengono caricati, messaggi compaiono e componenti reagiscono alle azioni dell’utente. Il problema nasce quando il browser deve riposizionare contenuti già visibili senza che la persona se lo aspetti.
Quando uno spostamento del layout entra nel CLS
Un layout shift viene registrato quando un elemento visibile cambia la propria posizione iniziale fra due frame renderizzati. Anche l’inserimento di un nuovo componente può quindi generare CLS indirettamente: il nuovo elemento non è necessariamente quello “instabile”, ma può spostare ciò che si trovava sotto di lui.
È una distinzione molto utile durante il debugging.
Se Chrome segnala un paragrafo che si è spostato, quel paragrafo potrebbe essere la vittima e non la causa. La causa reale può trovarsi qualche elemento più in alto: un’immagine che non aveva dimensioni conosciute, un font che modifica la geometria del testo, un iframe che aumenta altezza oppure un banner inserito dopo il rendering iniziale. web.dev sottolinea esplicitamente che gli elementi riportati dagli strumenti diagnostici possono essere quelli interessati dallo spostamento e non necessariamente quelli che lo hanno originato.
Layout shift previsto e imprevisto: la differenza che conta
La metrica cerca di separare gli spostamenti subiti dall’utente da quelli che fanno parte di un’interazione prevista.
Gli shift che si verificano abbastanza vicino a determinati input dell’utente possono essere esclusi dal CLS. La documentazione web.dev utilizza una finestra di 500 millisecondi per questi casi. Non significa però che qualsiasi cosa accada dopo un’interazione sia automaticamente innocua: uno spostamento durante lo scroll, un contenuto lazy loaded che compare mentre scendi nella pagina o un caricamento di rete troppo lento possono comunque produrre CLS inatteso.
La regola pratica è più semplice della formula: l’interfaccia deve cambiare quando l’utente se lo aspetta e senza spostare inutilmente ciò che sta già usando.
Come viene calcolato il punteggio CLS
Per capire perché due spostamenti apparentemente simili possono produrre punteggi molto diversi, bisogna scendere un livello sotto la metrica.
Ogni singolo layout shift viene calcolato combinando due valori:
layout shift score = impact fraction × distance fraction
L’impact fraction descrive quanta parte del viewport viene interessata dal movimento. La distance fraction considera invece quanto lontano si è spostato l’elemento instabile rispetto alla dimensione maggiore del viewport.
Un piccolo componente che si muove di pochi pixel avrà quindi un peso differente rispetto a un grande blocco di contenuto che attraversa una parte consistente dello schermo.
Impact fraction e distance fraction
Immagina che un elemento occupi una parte importante dell’area visibile e venga improvvisamente spostato verso il basso. Il browser considera sia la zona precedente sia quella successiva occupata dall’elemento per determinare l’impact fraction. Misura poi la distanza percorsa rispetto alla dimensione del viewport per ottenere la distance fraction.
Il prodotto dei due valori genera lo score del singolo layout shift.
Non è necessario calcolare manualmente queste frazioni durante una normale ottimizzazione WordPress. Servono però a costruire il modello mentale corretto: CLS non conta semplicemente quante cose si muovono, ma tiene conto dell’impatto visivo e dell’entità dello spostamento.
Le session window: perché CLS non somma semplicemente tutti gli spostamenti
Qui troviamo la differenza più importante rispetto alle vecchie spiegazioni della metrica.
CLS non somma più indiscriminatamente tutti i layout shift accumulati durante l’intera permanenza sulla pagina. Gli shift vengono raggruppati in session window: una finestra comprende spostamenti successivi separati da meno di un secondo e può durare al massimo cinque secondi. Il valore CLS corrisponde alla finestra con il punteggio cumulativo più elevato.
Questo cambiamento evita di penalizzare in modo sproporzionato pagine utilizzate a lungo, come applicazioni single-page o contenuti con infinite scroll, che avrebbero altrimenti potuto accumulare shift semplicemente perché rimanevano aperte più a lungo.
Qual è un buon valore di Cumulative Layout Shift
Le soglie correnti sono:
| CLS | Valutazione |
|---|---|
| ≤ 0,1 | Buono |
| > 0,1 e ≤ 0,25 | Da migliorare |
| > 0,25 | Scarso |
web.dev raccomanda di raggiungere 0,1 o meno per almeno il 75% delle visite alla pagina.
Questo significa che l’obiettivo non dovrebbe essere ottenere ossessivamente 0,000 durante un singolo test. Uno zero stabile è naturalmente ottimo, ma inseguire la perfezione in laboratorio può diventare un uso poco efficace del tempo se gli utenti reali sono già ampiamente nella fascia buona.
Perché conta il 75° percentile di mobile e desktop
Una pagina non ha un unico comportamento universale.
Dispositivo, dimensione dello schermo, contenuti personalizzati, cache, connessione, font e modalità di interazione possono modificare l’esperienza. Per questo i Core Web Vitals utilizzano dati aggregati e Google indica il 75° percentile come riferimento per valutare l’esperienza della maggior parte degli utenti, distinguendo mobile e desktop.
Un test perfetto eseguito sul tuo computer non dimostra quindi che il sito sia stabile per chi lo visita realmente.
CLS e SEO: quanto conta realmente per Google
Qui conviene evitare due estremi: dire che il CLS non conta per la SEO oppure trattarlo come un interruttore che fa salire o scendere automaticamente una pagina.
GOOGLE_CONFIRMED: Google dichiara che i Core Web Vitals sono utilizzati dai suoi sistemi di ranking. CLS appartiene quindi al gruppo di metriche che Google considera nel quadro della page experience.
Questo, però, non significa che ridurre CLS da 0,15 a 0,05 produca automaticamente un miglioramento misurabile della posizione.
Google precisa che non esiste un singolo “page experience signal”, che ottenere buoni Core Web Vitals non garantisce le prime posizioni e che la pertinenza del contenuto continua a essere fondamentale. Puoi approfondire questa distinzione anche nella guida Creativemotions sui fattori di ranking Google.
Il motivo per correggere un CLS problematico resta quindi concreto anche senza promettere ranking: una pagina stabile evita di interrompere la lettura, riduce il rischio di clic involontari e offre un’esperienza più prevedibile. E quando più risultati sono utili e pertinenti, Google afferma che una buona page experience può contribuire al successo nella ricerca.
Come misurare il CLS senza confondere dati reali e test di laboratorio
Uno degli errori più frequenti è confrontare due numeri CLS provenienti da strumenti differenti e concludere che uno dei due sia sbagliato.
Spesso stanno semplicemente misurando situazioni diverse.
PageSpeed Insights è particolarmente utile perché mette nello stesso report dati real-user provenienti da CrUX e una diagnostica di laboratorio eseguita con Lighthouse. La documentazione ufficiale di PageSpeed Insights distingue esplicitamente questi due livelli.
PageSpeed Insights e Chrome UX Report: il CLS degli utenti reali
Quando esistono dati sufficienti, la sezione field di PageSpeed Insights mostra ciò che utenti Chrome reali hanno sperimentato. I dati CrUX utilizzati da PSI rappresentano una finestra mobile degli ultimi 28 giorni e possono essere disponibili a livello di URL oppure, quando i dati specifici non sono sufficienti, a un livello aggregato differente.
Questo dato è particolarmente importante per CLS perché la metrica può continuare a crescere dopo il caricamento iniziale.
Una pagina può essere stabile nei primi secondi e iniziare a spostarsi durante lo scroll, quando viene caricata una sezione lazy loaded, quando appare un contenuto dinamico oppure durante una transizione applicativa.
Lighthouse e Chrome DevTools: trovare la causa in laboratorio
Il laboratorio risolve un problema differente: riprodurre e diagnosticare.
La guida a Google Lighthouse spiega perché il risultato di un test controllato non va confuso con l’esperienza aggregata degli utenti. Per CLS questa distinzione è ancora più evidente: molti test di laboratorio eseguono soprattutto il caricamento della pagina e possono quindi non intercettare gli shift che compaiono successivamente.
Chrome DevTools consente di andare più a fondo. Nel pannello Performance i layout shift vengono mostrati nella relativa track, raggruppati in cluster; selezionandoli puoi vedere punteggio, timing, elementi coinvolti e possibili responsabili.
Questa è la parte operativa che manca quando guardi soltanto il numero: CLS = 0,28 segnala il problema; la trace ti aiuta a capire quando e dove è nato.
Search Console: quando usare il report Core Web Vitals
Search Console serve soprattutto a capire se il problema emerge su gruppi di URL attraverso dati real-user.
Non è lo strumento ideale per aprire una singola pagina e individuare il div che si sposta. È invece utile per stabilire priorità: capire quali gruppi risultano Poor, quali sono Need improvement e se il problema interessa molte pagine che condividono lo stesso template.
Google consiglia infatti di correggere prima i problemi Poor, testare il fix con strumenti esterni e poi monitorarne la validazione nel report Core Web Vitals.
Perché field CLS e lab CLS possono essere diversi
Se CrUX mostra CLS elevato e Lighthouse no, non partire dalla conclusione che CrUX sia “sbagliato”.
La documentazione corrente di web.dev avverte che il CLS misurato in laboratorio può risultare artificialmente più basso, perché molti strumenti non interagiscono con la pagina e registrano soprattutto ciò che accade durante il caricamento iniziale. Le misurazioni real-user possono invece osservare layout shift inattesi durante l’intera vita della pagina.
La differenza fra field e lab è quindi un indizio diagnostico.
Come trovare cosa provoca un CLS elevato
La procedura più efficace non parte dal plugin da installare. Parte dal momento in cui avviene lo shift.
Un workflow pratico è: controlla prima i dati reali; verifica se il problema compare anche in laboratorio; registra la pagina con DevTools; individua il cluster di layout shift più pesante; osserva gli elementi che si spostano; cerca cosa è cambiato immediatamente prima; applica un fix mirato; ripeti lo stesso test.
Questo approccio evita di modificare font, cache, JavaScript e immagini contemporaneamente senza sapere quale intervento abbia realmente risolto il problema.
Layout shift durante il caricamento
Se il CLS di CrUX e quello del test Lighthouse sono abbastanza vicini, è ragionevole iniziare dai problemi che avvengono durante il caricamento.
Le cause tipiche sono immagini senza spazio riservato, font che cambiano dimensione, iframe ed embed caricati in ritardo o contenuti inseriti nel flusso dopo che il browser ha già costruito il layout.
Apri DevTools, registra una trace dal pannello Performance e concentrati sui cluster più grandi. Ricorda però di risalire alla causa: se compare un titolo spostato verso il basso, guarda cosa è stato inserito o ridimensionato sopra quel titolo.
Post-load CLS durante scroll e interazioni
Quando il laboratorio sembra pulito ma il field CLS rimane alto, cerca ciò che accade dopo il primo caricamento.
Scorri l’intera pagina, apri menu, accordion e componenti interattivi, carica altri prodotti, attiva filtri, lascia comparire eventuali messaggi e verifica ciò che accade quando entrano nel viewport elementi lazy loaded.
La vista live del pannello Performance di Chrome permette di osservare CLS mentre interagisci con la pagina e può quindi aiutare a riprodurre questi problemi.
Come individuare gli elementi instabili in Chrome DevTools
Nella track Layout shifts del pannello Performance, Chrome rappresenta gli spostamenti come indicatori raggruppati in cluster. Passando o facendo clic sugli eventi puoi visualizzare gli elementi interessati e i dettagli dello shift. Le versioni moderne degli strumenti Chrome includono inoltre insight dedicati ai possibili responsabili del CLS.
Il dato più utile non è necessariamente “questo elemento si è mosso”, ma la sequenza:
evento precedente → modifica del layout → elemento spostato
È lì che normalmente trovi la causa.
Le cause più comuni del Cumulative Layout Shift
Non tutti i siti presentano gli stessi problemi, ma alcune categorie ricorrono abbastanza spesso da costituire una buona checklist diagnostica. La guida ufficiale di web.dev indica fra le cause principali immagini prive di dimensioni, annunci, embed e iframe caricati successivamente e web font.
Immagini e video senza spazio riservato
Se il browser non conosce in anticipo le proporzioni di un’immagine, può inizialmente costruire il layout senza riservarle lo spazio necessario. Quando il file arriva, il contenuto successivo viene spostato.
La soluzione moderna consiste nel fornire width e height corretti nel markup e lasciare che il browser ricavi l’aspect ratio mentre il CSS gestisce il ridimensionamento responsive. In alternativa, quando necessario, puoi riservare esplicitamente lo spazio attraverso aspect-ratio.
<img src="immagine.jpg" width="1200" height="675" alt="Descrizione dell'immagine" >
Il CSS può continuare a renderla responsive:
img {
max-width: 100%;
height: auto;
}
Su WordPress non dare per scontato che “ci pensi sempre il CMS”. Controlla l’HTML realmente prodotto dal tema, dal page builder e dai plugin, soprattutto per componenti personalizzati, slider, immagini caricate via script e markup costruito manualmente.
Iframe, embed, banner pubblicitari e widget
Video YouTube, mappe, social embed, annunci e altri widget esterni spesso conoscono le proprie dimensioni solo quando vengono caricati. Se il contenitore parte da altezza zero e cresce successivamente, tutto ciò che si trova sotto può spostarsi.
Il principio è lo stesso delle immagini: riserva lo spazio prima che arrivi il contenuto.
Per un video 16:9 puoi, per esempio, utilizzare un contenitore con aspect ratio:
.embed-container {
width: 100%;
aspect-ratio: 16 / 9;
}
Per componenti la cui altezza non è completamente prevedibile puoi valutare min-height, placeholder o altre strategie coerenti con il layout. web.dev avverte anche di non collassare lo spazio riservato se il contenuto non viene restituito, perché rimuoverlo può produrre uno shift simile a quello che stavi cercando di evitare.
Font web e cambio del font di fallback
I font sono un caso più sottile.
Quando il browser mostra inizialmente un fallback e lo sostituisce con il web font definitivo, le due famiglie possono avere metriche differenti. Cambiano larghezza dei caratteri, altezza delle righe e dimensione complessiva dei blocchi di testo. Il risultato può essere uno spostamento del contenuto circostante.
Precaricare il font può aiutare, ma non è la soluzione universale al CLS dei font.
web.dev indica più leve: scegliere un fallback appropriato, utilizzare correttamente font-display, ridurre le differenze metriche attraverso proprietà come size-adjust, ascent-override, descent-override e line-gap-override, e caricare anticipatamente i font realmente critici.
Il preload ha quindi senso quando anticipare una risorsa critica permette al font definitivo di essere disponibile abbastanza presto. Precaricare indiscriminatamente tutti i file tipografici può invece consumare banda e competere con altre risorse importanti.
Contenuti dinamici, cookie banner e barre di notifica
Un banner che compare sopra l’header, un form inserito sopra il testo o un avviso che entra nel normale document flow dopo il rendering possono spostare gran parte della pagina.
Le possibilità principali sono riservare lo spazio necessario già nel layout iniziale oppure, quando il design lo consente, utilizzare una sovrapposizione che non sposti il contenuto sottostante. web.dev tratta esplicitamente banner, form e cookie notice fra gli scenari da progettare con attenzione.
In WordPress questi problemi meritano attenzione particolare quando arrivano da CMP, plugin popup, barre promozionali, moduli marketing e componenti caricati da servizi esterni.
Animazioni e proprietà CSS che modificano il layout
Non tutte le animazioni sono equivalenti.
Animare proprietà che costringono il browser a modificare il layout, come spostamenti basati su top e left, può generare layout shift. Quando il risultato visivo lo permette, le trasformazioni tramite transform possono evitare il re-layout degli altri elementi e sono quindi una soluzione più adatta.
Non significa sostituire automaticamente ogni animazione del sito. Significa identificare quelle che cambiano realmente la geometria del documento e chiedersi se lo stesso effetto possa essere ottenuto senza spostare il layout.
Come ridurre il Cumulative Layout Shift in WordPress
Su WordPress il problema raramente è “WordPress” in astratto. Il CLS che arriva al browser è il risultato combinato di tema, blocchi, page builder, plugin, CSS, JavaScript, font, pubblicità e servizi esterni.
Per questo partire da un plugin di ottimizzazione prima di aver identificato la causa può produrre modifiche inutili o, in alcuni casi, nuove regressioni.
Impostare correttamente width, height e aspect-ratio
Apri una pagina problematica e controlla prima gli elementi visuali.
Le immagini dovrebbero esporre dimensioni coerenti nel markup. I componenti responsive devono mantenere proporzioni prevedibili. I background e le immagini inserite da widget personalizzati meritano un controllo separato perché non sempre seguono il comportamento delle normali immagini del contenuto.
Se utilizzi <picture> per art direction responsive, verifica anche che le varianti non introducano rapporti d’aspetto incompatibili senza dimensioni correttamente definite. La documentazione web.dev descrive esplicitamente l’uso moderno di width, height e aspect-ratio anche per immagini responsive.
Riservare spazio a video, iframe, banner e contenuti lazy loaded
Un placeholder non è necessariamente un espediente estetico. Può rappresentare lo spazio che il contenuto occuperà quando sarà disponibile.
Questo vale per player video, mappe, annunci, recensioni esterne, feed social e blocchi AJAX. Se non conosci l’altezza esatta, puoi lavorare con un aspect ratio previsto, una min-height ragionevole o un contenitore stabile progettato per adattarsi senza spingere improvvisamente il resto della pagina.
Il compromesso da valutare è fra stabilità e spazio vuoto: riservare troppo spazio può creare buchi visivi, riservarne troppo poco può ridurre ma non eliminare lo shift.
Ridurre il CLS causato dai font
Prima di aggiungere preload, controlla quale font viene mostrato inizialmente e quanto differisce da quello definitivo.
Se il fallback produce righe sensibilmente più corte o più alte, anticipare di qualche millisecondo il download non risolve necessariamente il meccanismo. Potrebbe essere più efficace migliorare il matching metrico fra fallback e web font.
Se invece un font essenziale viene richiesto molto tardi nonostante sia necessario immediatamente above the fold, allora il preload può diventare una parte sensata della soluzione.
La sequenza corretta è quindi diagnosi → causa → tecnica, non CLS alto → preload tutti i font.
Gestire popup, cookie banner e contenuti dinamici
Controlla soprattutto ciò che viene inserito vicino alla parte superiore del viewport.
Un banner alto 60 pixel aggiunto prima del contenuto può spostare quasi tutto ciò che l’utente sta guardando. Lo stesso banner mostrato come overlay progettato correttamente può evitare lo shift, anche se dovrà comunque rispettare accessibilità, usabilità e gli altri requisiti dell’interfaccia.
Per componenti che devono entrare nel flusso della pagina, riserva invece il loro spazio prima del caricamento.
Evitare regressioni introdotte da tema, page builder e plugin
Una pagina stabile oggi può tornare instabile dopo un aggiornamento o una modifica apparentemente innocua.
Un nuovo slider può cambiare altezza dopo l’inizializzazione JavaScript. Una barra promozionale può comparire solo per utenti non autenticati. Un plugin di cookie consent può comportarsi diversamente dopo la prima visita. Un widget esterno può restituire contenuti di dimensioni variabili.
Per questo, dopo un intervento importante, testa almeno il template coinvolto nelle condizioni che riproducono il problema originale. Se il difetto interessa più pagine dello stesso tipo, correggere il componente condiviso è generalmente più sensato che applicare workaround pagina per pagina.
Come verificare che la correzione del CLS abbia funzionato
La verifica deve avvenire su due tempi differenti.
Il primo è immediato: ripeti il test nelle stesse condizioni di laboratorio e controlla che il layout shift responsabile non compaia più. Il secondo richiede dati real-user: osserva se il miglioramento emerge progressivamente anche nei dati CrUX e nel report Core Web Vitals.
Questa distinzione evita una delle situazioni più frustranti: “Ho corretto il sito oggi, perché Search Console mostra ancora il problema?”.
Prima il test ripetibile, poi i dati reali
Se hai identificato un’immagine senza dimensioni, correggila e registra nuovamente la pagina con DevTools.
Se il cluster scompare e il CLS locale migliora, hai una prima conferma del meccanismo.
Poi osserva i dati field. Non aspettarti però che una singola visita dopo il deploy sostituisca immediatamente l’aggregazione precedente: PageSpeed Insights utilizza field data basati su una finestra mobile di 28 giorni.
Questo significa che laboratorio e field hanno anche tempi di reazione differenti.
Perché Search Console non cambia immediatamente dopo il fix
Il report Core Web Vitals di Search Console utilizza dati CrUX e non funziona come un crawler al quale basta richiedere una nuova indicizzazione.
La documentazione Google descrive una procedura di validazione con una sessione di monitoraggio di 28 giorni. Avviare la validazione non forza una nuova scansione o indicizzazione: avvia il periodo nel quale Search Console osserva i dati necessari a stabilire se il problema è effettivamente scomparso.
Quindi:
fix tecnico riuscito oggi ≠ report Search Console verde domani
Non è un’anomalia. Sono strumenti e finestre di osservazione differenti.
Errori da evitare quando ottimizzi il CLS
Il primo errore è ottimizzare il numero senza identificare il meccanismo. Un CLS alto non dice automaticamente che devi installare un plugin, precaricare un font o disattivare il lazy loading.
Il secondo è fidarsi di un solo test. Lighthouse è eccellente per riprodurre problemi, ma un normale caricamento di laboratorio può non vedere ciò che accade dopo diversi secondi di utilizzo. I dati real-user completano la diagnosi.
Il terzo è cercare obbligatoriamente CLS zero. Google stesso chiarisce, più in generale, che inseguire punteggi perfetti esclusivamente per ragioni SEO può non essere il miglior impiego del tempo. La soglia utile per CLS è una pagina stabile per la grande maggioranza degli utenti, non un numero decorativo ottenuto in condizioni irripetibili.
Il quarto è precaricare troppe risorse. Il preload assegna priorità e deve quindi essere riservato a risorse realmente critiche. Nel caso dei font, inoltre, il problema può essere la differenza metrica rispetto al fallback e non soltanto il momento in cui parte il download.
Il quinto è correggere l’elemento segnalato senza cercare cosa lo ha spostato. Se un paragrafo salta perché un banner viene inserito sopra di lui, fissare il paragrafo significa intervenire sull’effetto. Devi stabilizzare il banner o il suo contenitore.
Conclusione
Il Cumulative Layout Shift diventa molto più semplice da ottimizzare quando smetti di considerarlo un semplice punteggio PageSpeed.
CLS misura la stabilità visiva. Il valore ti segnala che esiste un problema; field data, Lighthouse e DevTools ti aiutano invece a capire quando avviene e quale meccanismo lo produce.
Il workflow più affidabile è quindi:
dati reali → riproduzione → layout shift → causa → intervento mirato → nuovo test → verifica nel field
Su WordPress le correzioni più frequenti riguardano spazio non riservato per immagini ed embed, contenuti dinamici, font e componenti che modificano il layout dopo il rendering iniziale. Ma non esiste un fix universale da applicare a tutti i siti.
Se il tuo CLS è già buono nei dati reali, inseguire qualche decimale in meno in un test isolato raramente è la priorità migliore. Se invece il problema compare per utenti reali o interessa interi template, allora conviene risalire alla causa tecnica e risolverla alla fonte.
Quando la diagnosi mostra problemi distribuiti fra CLS, Largest Contentful Paint, risorse frontend, tema, plugin e infrastruttura, il problema non è più una singola metrica. In quel caso ha più senso affrontare le prestazioni come un sistema e costruire un intervento di ottimizzazione del sito web basato sui colli di bottiglia realmente misurati.