# Banner dei cookie e Core Web Vitals: LCP, CLS e INP sempre verdi

> Come i banner dei cookie peggiorano LCP, CLS e INP e come rimediare: script di consenso asincroni, niente layout shift, preference center differito.

Source: https://www.cookiesh.eu/it/blog/cookie-banners-core-web-vitals  
Published: 2026-07-30

## Key takeaways

- Un banner dei cookie può influire su tutti e tre i Core Web Vitals: LCP, CLS e INP.
- Carica lo script di consenso in modo asincrono e mantieni inerti i tag non essenziali, così il banner non blocca mai il rendering dei contenuti principali.
- Mostra il banner come overlay fisso, oppure riservagli lo spazio, così non sposta mai i contenuti della pagina.
- Mantieni leggeri gli handler di Accetta e Rifiuta: aggiorna prima l'interfaccia, poi cedi il controllo al main thread prima di caricare i tag.
- Esegui i test in una sessione nuova, da un'area geografica in cui il banner viene mostrato, perché è lì che emerge il suo costo in termini di prestazioni.

Un banner dei cookie può peggiorare tutti e tre i Core Web Vitals: può ritardare il Largest Contentful Paint (LCP) o diventarne l'elemento, spostare i contenuti e far salire il Cumulative Layout Shift (CLS), e rendere lento il pulsante Accetta, cosa che emerge nell'Interaction to Next Paint (INP). Le soluzioni sono note: carica lo script di consenso in modo asincrono, mostra il banner come overlay fisso, differisci l'interfaccia secondaria e mantieni leggeri gli handler dei clic.

## Perché i banner dei cookie influiscono sui Core Web Vitals?

Il banner è spesso la prima cosa che vede un nuovo visitatore, ed è fatto di JavaScript, CSS e testo che competono con i tuoi contenuti reali per la banda e per il tempo del main thread. I Core Web Vitals misurano proprio questa competizione, valutata al 75° percentile dei caricamenti di pagina reali.

| Metrica | Che cosa misura | Soglia “buona” | Come un banner può peggiorarla |
| --- | --- | --- | --- |
| LCP | Quando viene visualizzato l'elemento di immagine o di testo più grande | 2,5 s o meno | Uno script di consenso che blocca il rendering, o il banner stesso che diventa l'elemento più grande |
| CLS | Quanto si spostano inaspettatamente i contenuti visibili | 0,1 o meno | Un banner inserito nel flusso della pagina che spinge i contenuti verso il basso |
| INP | Quanto rapidamente la pagina risponde a clic, tocchi e pressioni dei tasti | 200 ms o meno | Elaborazioni pesanti nell'handler di Accetta o Rifiuta |

A marzo 2024 l'INP ha sostituito il First Input Delay (FID), e per il consenso questo conta. Il FID misurava solo il ritardo prima che venisse gestita la prima interazione; l'INP misura l'intero tempo che va da qualsiasi interazione al frame successivo, e “Accetta tutto” è spesso la prima cosa su cui un visitatore fa clic.

## Come evito che lo script di consenso blocchi l'LCP?

Caricalo con `async` e mantienilo leggero. Uno script sincrono nell'`<head>` blocca il parser HTML finché non è stato scaricato ed eseguito, ritardando il titolo, l'immagine hero e tutto il resto.

```html
<head>
  <script src="https://consent.example.com/loader.js" async></script>

  <!-- Inerte finché lo script di consenso non lo attiva dopo un opt-in -->
  <script type="text/plain" data-consent="analytics"
          src="https://analytics.example.com/script.js"></script>
</head>
```

Il caricamento asincrono è sicuro quando i tag non essenziali sono inerti come in questo caso: non viene eseguito nulla finché lo script di consenso non lo consente. Gli approcci di “blocco automatico”, che intercettano gli script man mano che vengono aggiunti, di solito devono essere eseguiti in modo sincrono prima di qualsiasi altro script, con un costo in termini di tempo di rendering. La nostra guida su [come bloccare gli script fino al consenso](/it/blog/block-scripts-until-consent) mette a confronto i diversi metodi.

La seconda trappola per l'LCP è il banner stesso. L'LCP rileva il blocco di immagine o di testo più grande visualizzato nel viewport prima che il visitatore interagisca. Su uno smartphone piccolo, un banner con un paragrafo lungo può essere più grande del titolo, e se viene visualizzato tardi, anche l'LCP arriva tardi. Mantieni conciso il testo del primo livello, usa un font di sistema così non deve mai attendere un web font e non pubblicare mai il banner sotto forma di immagine.

Ritardare il banner non aiuta: un banner mostrato in ritardo può comunque diventare l'elemento LCP, solo più tardi.

## Come evito che il banner causi layout shift?

Mostralo come overlay fisso. Il CLS conteggia gli spostamenti dei contenuti già presenti, quindi un elemento con `position: fixed` che compare sopra la pagina non sposta nulla. L'errore classico è una barra inserita all'inizio del `<body>` dopo il primo rendering, che spinge in basso l'intera pagina.

```css
.consent-banner {
  position: fixed;
  inset: auto 0 0 0; /* ancorato in basso, fuori dal flusso del documento */
  z-index: 1000;
  font: 1rem/1.5 system-ui, sans-serif; /* nessun web font da attendere */
  animation: consent-in 200ms ease-out;
}

@keyframes consent-in {
  from { transform: translateY(100%); }
}

@media (prefers-reduced-motion: reduce) {
  .consent-banner { animation: none; }
}
```

Se usi animazioni, anima `transform` o `opacity`. Animare `top`, `height` o `margin` modifica il layout e può essere registrato come spostamento. Se il tuo design richiede davvero un banner nel flusso della pagina, riservagli lo spazio nell'HTML generato dal server: funziona bene solo se il server legge il cookie di consenso e non riserva lo spazio per i visitatori di ritorno.

Pianifica anche cosa succede dopo il consenso. Gli spostamenti che avvengono entro 500 ms da un clic o dalla pressione di un tasto sono esclusi dal CLS, ma uno spazio pubblicitario, un video incorporato o un widget di chat che si carica qualche secondo dopo no. Assegna a quei contenitori dimensioni fisse o un `aspect-ratio`.

## Come differisco l'interfaccia del banner senza compromettere la conformità?

Pubblica subito il primo livello e carica il preference center su richiesta. Il primo livello è un breve messaggio con qualche pulsante; il secondo livello, con interruttori per categoria, elenchi dei fornitori e tabelle dei cookie, è di solito la parte più pesante.

Ciò che non devi mai differire è la scelta. “Rifiuta tutto” va nel primo livello, con la stessa evidenza di “Accetta tutto”. Nel dicembre 2021 la CNIL francese ha sanzionato Google per 150 milioni di euro e Facebook per 60 milioni di euro perché rifiutare i cookie era più difficile che accettarli. Leggi [dark pattern nei banner dei cookie](/it/blog/cookie-banner-dark-patterns) e le nostre [best practice per il design dei banner](/it/blog/cookie-banner-design-best-practices).

## Come mantengo reattivi Accetta e Rifiuta per l'INP?

Fai il minimo indispensabile prima del rendering successivo, poi cedi il controllo. Un handler lento in genere scrive il cookie di consenso, invia un log del consenso, aggiorna Google Consent Mode e inserisce diversi script dei fornitori in un unico task lungo, così il pulsante sembra bloccato.

```js
function yieldToMain() {
  if (globalThis.scheduler?.yield) return globalThis.scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

acceptButton.addEventListener('click', async () => {
  banner.remove();                                    // 1. prima il riscontro visivo
  saveConsent({ analytics: true, marketing: true });  // 2. piccolo e sincrono
  await yieldToMain();                                // 3. lascia che il browser esegua il rendering
  activateTags(['analytics', 'marketing']);           // 4. il lavoro pesante in un task successivo
});

customizeButton.addEventListener('click', async () => {
  customizeButton.setAttribute('aria-busy', 'true');
  const { openPreferences } = await import('./preference-center.js'); // caricato su richiesta
  openPreferences();
});
```

Invia il log del consenso con `navigator.sendBeacon()`, così le operazioni di rete non rallentano mai l'interazione, e attiva i tag numerosi a blocchi, cedendo il controllo tra un blocco e l'altro. `scheduler.yield()` non è ancora disponibile in tutti i browser, da qui il fallback.

## Come devo testare l'impatto di un banner?

Testa come visitatore alla prima visita, poi come visitatore di ritorno. Gli strumenti di laboratorio come Lighthouse partono con lo storage vuoto, quindi vedono sempre il banner:

1. Apri la pagina in un profilo del browser nuovo, da un'area geografica in cui il banner viene mostrato.
2. Esegui Lighthouse o PageSpeed Insights e verifica quale elemento viene indicato come elemento LCP.
3. Registra una traccia nel pannello Performance di Chrome DevTools, fai clic su “Accetta tutto” e cerca task lunghi dopo il clic.
4. Nella stessa traccia, cerca layout shift durante la comparsa del banner e dopo il caricamento dei tag.
5. Ripeti come visitatore di ritorno con il consenso memorizzato, perché vengono eseguiti più tag.
6. In seguito confronta i dati sul campo in Search Console o PageSpeed Insights: coprono una finestra mobile di 28 giorni, quindi le modifiche emergono gradualmente.

## In sintesi

Un banner di consenso non deve per forza costarti i Core Web Vitals. Caricalo in modo asincrono, tienilo fuori dal flusso del documento, differisci il secondo livello più pesante e mantieni leggeri gli handler dei clic, lasciando ogni scelta ugualmente facile da compiere. Strumenti come Cookiesh possono gestire la parte di caricamento, con un loader asincrono di meno di 5 kB compresso con gzip, distribuito da una CDN edge globale e progettato per evitare il layout shift.

*Questo articolo ha carattere puramente informativo e non costituisce consulenza legale. Per decisioni relative alla tua situazione specifica, rivolgiti a un professionista qualificato in materia di privacy.*

## FAQ

### Nascondere il banner a Lighthouse migliora i miei Core Web Vitals?

No. La valutazione dei Core Web Vitals di Google si basa sui dati sul campo degli utenti reali di Chrome, molti dei quali vedono il tuo banner. Nasconderlo agli strumenti di laboratorio nasconde il problema solo a te, e servire una pagina diversa agli strumenti di test rende inaffidabile la diagnostica.

### Per le prestazioni è meglio una barra in basso o una finestra modale al centro?

Entrambe evitano il layout shift se usano il posizionamento fisso. Una modale grande copre una porzione maggiore del viewport ed è più probabile che venga indicata come elemento LCP su mobile, quindi una barra compatta in basso è di solito la scelta più sicura per le prestazioni, purché dia a tutte le scelte la stessa evidenza.

### Devo misurare separatamente i Core Web Vitals dei visitatori che hanno già prestato il consenso?

È utile. I visitatori di ritorno non vedono il banner ma eseguono più tag, quindi il loro profilo di caricamento e reattività è diverso da quello di chi visita il sito per la prima volta. Segmentare le misurazioni ti dice quale gruppo richiede interventi, ma ricorda che anche inviare dati di real-user monitoring a una terza parte può richiedere il consenso.

## Sources

- [web.dev: Web Vitals](https://web.dev/articles/vitals)
- [Directive 2002/58/EC (ePrivacy Directive), EUR-Lex](https://eur-lex.europa.eu/eli/dir/2002/58/oj)
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en)