Per la maggior parte dei visitatori europei, la prima cosa che compare su un sito non è il contenuto, ma il banner dei cookie. È un obbligo legato alla normativa sulla privacy, ed è anche un elemento dell’interfaccia con conseguenze precise sulle prestazioni: viene caricato a ogni prima visita, occupa una parte importante dello schermo, e il clic su «Accetta» o «Rifiuta» è spesso la prima interazione dell’utente con la pagina.
Proprio per questo, un banner dei cookie realizzato male può peggiorare tutte e tre le Core Web Vitals: può diventare l’elemento LCP, può spostare il contenuto e generare CLS, e può rendere lenta la prima interazione, peggiorando l’INP. In questo articolo vediamo come succede e come implementare il consenso in modo conforme senza sacrificare le prestazioni. Non è una guida legale: le scelte sul contenuto del banner vanno fatte con chi si occupa della conformità, ma il modo in cui viene caricato e mostrato è una questione tecnica.
Il banner come elemento LCP
Il Largest Contentful Paint misura il momento in cui viene disegnato l’elemento più grande visibile nello schermo iniziale. Su uno smartphone, un banner dei cookie con un testo lungo, che occupa metà dello schermo o più, può facilmente essere più grande dell’immagine principale o del titolo della pagina. In quel caso l’elemento LCP non è il contenuto, ma il testo del banner.
Il problema diventa serio quando il banner arriva tardi. Molte piattaforme di gestione del consenso caricano il banner tramite uno script esterno, che il browser scarica dopo l’HTML, a volte dopo altri script, e che a sua volta richiede la configurazione e i testi da un server remoto. Il banner viene disegnato solo alla fine di questa catena, spesso con un’animazione di comparsa. Se è l’elemento più grande, l’LCP della pagina coincide con il suo arrivo, anche quando il contenuto era pronto molto prima.
Le soluzioni agiscono su due fronti. Il primo è la dimensione: un banner compatto, con un testo breve e un link alle informazioni complete, occupa meno spazio del contenuto principale e non diventa l’elemento LCP. È anche più rispettoso dell’utente, che vede subito la pagina che ha cercato. Il secondo è la tempestività: se il banner deve essere grande, deve almeno comparire presto. Il suo markup e il suo CSS possono essere inclusi direttamente nell’HTML, o lo script della piattaforma può essere caricato con priorità, con un preconnect al dominio da cui proviene e senza dipendere da altri script.
Un dettaglio spesso trascurato riguarda le animazioni. Un banner che compare con una dissolvenza partendo da opacità zero viene considerato dal browser solo quando diventa visibile, e un’animazione lenta ritarda di conseguenza l’LCP se il banner è l’elemento più grande. Una comparsa immediata, o un’animazione basata solo sulla posizione, evita il problema.
Il banner e il CLS
Il secondo problema è lo spostamento del layout. Un banner inserito nel flusso della pagina, per esempio una barra in cima che spinge in basso tutto il contenuto quando compare, genera uno spostamento che si somma al CLS. Lo stesso accade, in modo opposto, quando il banner scompare dopo il clic e il contenuto risale.
La soluzione è semplice: il banner deve essere sovrapposto al contenuto, con posizionamento fisso, e non inserito nel flusso della pagina. Un pannello fisso in basso, o una finestra modale, non sposta nulla quando compare né quando scompare. Va evitato anche il blocco dello scorrimento applicato al corpo della pagina mentre il banner è aperto: su desktop, la scomparsa della barra di scorrimento allarga la pagina di qualche pixel e sposta tutto il contenuto. Se il blocco è necessario, la proprietà CSS scrollbar-gutter: stable riserva lo spazio della barra ed evita lo spostamento.
.banner-consenso {
position: fixed;
inset: auto 0 0 0; /* ancorato in basso, sopra il contenuto */
max-height: 40vh; /* non occupa tutto lo schermo */
overflow: auto;
z-index: 1000;
}
html {
scrollbar-gutter: stable; /* nessuno spostamento se si blocca lo scorrimento */
}Il clic su «Accetta» e l’INP
Il terzo problema, e spesso il più grave, riguarda l’INP. Quando l’utente accetta i cookie, la piattaforma di consenso deve attivare tutti gli strumenti che erano in attesa: analytics, pixel pubblicitari, mappe di calore, chat, video incorporati. In molte implementazioni tutto questo avviene nello stesso gestore dell’evento del clic: il browser inserisce decine di script, li esegue, e solo alla fine può disegnare la chiusura del banner. L’utente tocca il pulsante e per mezzo secondo non succede nulla.
Poiché è spesso la prima interazione e, per molti utenti, una delle poche della visita, questo clic può determinare da solo l’INP di una pagina. La soluzione segue il principio visto nell’articolo sul main thread: dare subito un riscontro visivo, cedere il passo al browser e solo dopo eseguire il lavoro pesante.
pulsanteAccetta.addEventListener( 'click', async () => {
banner.hidden = true; // 1. riscontro immediato
salvaConsenso( 'accettato' );
await new Promise( ( r ) => setTimeout( r, 0 ) ); // 2. lascia disegnare
attivaStrumenti(); // 3. analytics, pixel e altri tag
} );Se si usa una piattaforma commerciale, conviene verificare se offre questa modalità o se attiva i tag in modo differito. In molti casi il problema non è nella piattaforma ma nella quantità di strumenti che si attivano al consenso: è un’ulteriore occasione per rivedere quali script di terze parti servono davvero.
La modalità di consenso di Google
Per chi usa gli strumenti di Google, la modalità di consenso offre un approccio diverso: i tag vengono caricati fin dall’inizio in una modalità limitata, senza cookie, e al momento del consenso ricevono solo un aggiornamento dello stato, invece di essere caricati da zero. Dal punto di vista delle prestazioni questo sposta il lavoro dal clic al caricamento: il clic diventa più leggero, ma gli script vengono comunque scaricati ed eseguiti durante il caricamento della pagina. Va quindi valutato insieme al resto della strategia di caricamento, per esempio differendo il tag manager fino a dopo il primo disegno.
Il peso della piattaforma
Le piattaforme di gestione del consenso variano molto per peso e comportamento. Alcune caricano pochi kilobyte e mostrano il banner quasi immediatamente; altre scaricano centinaia di kilobyte di JavaScript, liste di fornitori, traduzioni, fogli di stile e font propri, anche per gli utenti che hanno già espresso il consenso nelle visite precedenti. Nella scelta vale la pena confrontare, oltre alle funzioni e alla conformità, anche il peso dello script, il numero di richieste, la possibilità di ospitare le risorse sul proprio dominio e il comportamento per chi torna sul sito.
Per chi ha già dato il consenso, l’ideale è che la piattaforma legga la scelta da un cookie o dalla memoria locale e non mostri né carichi nulla di superfluo. È il caso più frequente sui siti con molti visitatori di ritorno, e quello in cui un banner pesante è più ingiustificato.
Il caso WordPress
Su WordPress il banner è di solito gestito da un plugin, che può mostrare un banner proprio o integrare una piattaforma esterna. Le impostazioni da controllare sono sempre le stesse: posizione e dimensione del banner, animazioni di comparsa, modo in cui vengono bloccati e poi sbloccati gli script, caricamento del plugin su tutte le pagine o solo dove serve. Alcuni plugin generano il banner lato server, direttamente nell’HTML, e sono in genere i più rapidi a mostrarlo; altri lo costruiscono via JavaScript dopo il caricamento.
Un punto delicato è l’interazione con le cache di pagina. Se il banner viene inserito nell’HTML dal server, la pagina memorizzata in cache deve essere la stessa per chi ha già dato il consenso e per chi no: il banner va quindi incluso sempre e mostrato o nascosto dal browser in base al cookie, oppure caricato separatamente. Configurazioni che generano versioni diverse della pagina in base al cookie di consenso riducono l’efficacia della cache e peggiorano il TTFB proprio per i nuovi visitatori.
Un esempio tipico
Un sito editoriale nota nei dati di campo un LCP da mobile di 3,2 secondi, mentre i test di laboratorio indicano 1,6. Il RUM rivela che l’elemento LCP più frequente è il paragrafo del banner dei cookie, lungo e caricato da una piattaforma esterna dopo gli script pubblicitari. Il clic su «Accetta», inoltre, attiva una dozzina di tag e registra un INP superiore ai 400 millisecondi. Gli interventi sono tre: testo del banner ridotto a due righe con un link all’informativa, script della piattaforma caricato per primo con un preconnect, attivazione dei tag rimandata a dopo la chiusura del banner. Nel giro di un mese i dati di campo mostrano un LCP da mobile sotto i 2,5 secondi e un INP della prima interazione nello stato buono, senza alcuna modifica alle scelte di consenso.
Attenzione ai test di laboratorio
C’è un’insidia importante nel misurare questi effetti. Molte piattaforme mostrano il banner solo ai visitatori dell’Unione europea, in base alla posizione. I test di laboratorio di PageSpeed Insights e di altri strumenti vengono spesso eseguiti da server situati fuori dall’Europa: il banner non compare, e il test mostra una pagina diversa da quella che vede la maggior parte degli utenti italiani. Il risultato è un LCP e un CLS apparentemente ottimi in laboratorio, e dati di campo molto peggiori, come abbiamo visto nell’articolo sul motivo per cui CrUX e test di laboratorio servono entrambi.
Per valutare correttamente l’impatto del banner conviene quindi usare strumenti che permettono di scegliere una località europea, eseguire i test da un browser locale con i DevTools, avendo cura di cancellare i cookie per simulare una prima visita, e soprattutto osservare i dati degli utenti reali. Un sistema di Real User Monitoring con attribuzione mostra rapidamente se l’elemento LCP più frequente è il testo del banner e se l’interazione più lenta è il clic sui suoi pulsanti.
Una checklist per il banner
- Il banner è compatto e non supera in dimensioni il contenuto principale dello schermo iniziale.
- Compare subito, senza dissolvenze lente e senza dipendere da una lunga catena di script.
- È sovrapposto con posizionamento fisso e non sposta il contenuto quando compare o scompare.
- Il clic sui pulsanti chiude subito il banner e attiva i tag solo dopo il disegno.
- Per chi ha già scelto, non carica nulla di superfluo.
- Viene testato da una località europea, con i cookie cancellati, e verificato sui dati di campo.
In sintesi
Il banner dei cookie è il primo elemento che la maggior parte dei visitatori europei vede e tocca, e per questo può influire su tutte e tre le Core Web Vitals: diventando l’elemento LCP quando è grande e arriva tardi, generando CLS quando spinge il contenuto, peggiorando l’INP quando il clic di consenso attiva tutti gli strumenti in un colpo solo.
Un banner compatto, disegnato subito, sovrapposto al contenuto e con un gestore del clic che risponde prima di attivare i tag risolve la gran parte di questi problemi, senza alcuna rinuncia sul piano della conformità. Conformità normativa e prestazioni non sono in conflitto: lo diventano solo quando il consenso viene implementato senza pensare a chi deve darlo, cioè agli utenti che stanno aspettando di vedere la pagina.
