Widget di chat con Core Web Vitals perfetti

Come caricare un widget di chat nel modo giusto

L'ho detto e ripetuto. Alcuni script sono più importanti di altri. Nessuno nella storia di internet si è mai infastidito se un widget di chat non si è caricato nei primi 500ms del caricamento della pagina. Quel momento in cui la pagina è ancora bianca.

Non avrebbe senso, vero, caricare un widget di chat prima ancora che il contenuto principale della pagina abbia iniziato a caricarsi? No, avrebbe molto più senso caricare prima le parti più importanti (il tuo logo, la tua immagine principale, i tuoi fogli di stile, i tuoi font, magari alcuni script super importanti che gestiscono la navigazione e la conversione).

Gli studi dimostrano che solo dal 3 al 10 percento dei visitatori utilizza effettivamente un widget di chat durante la loro sessione. Differire lo script di chat non ti costa nulla in termini di user experience ma ti fa guadagnare molto in termini di page speed.

Sfortunatamente questo non è il modo in cui la maggior parte dei siti web fa le cose. Quotidianamente vedo script non importanti (come gli script di chat) caricarsi con la massima priorità immediatamente all'inizio del caricamento della pagina.

In questo articolo spiegherò come caricare correttamente uno script di chat e come questo influisca su metriche importanti come il Largest Contentful Paint e l'Interaction to Next Paint.

Ultima revisione a cura di Arjen Karel a Febbraio 2026

Background: come funzionano i widget di chat

Un widget di chat di solito funziona caricando un piccolo script sulla tua pagina. Quello script caricherà alcuni stili e inietterà un iframe sulla tua pagina. Un iframe è una piccola pagina web isolata all'interno di una pagina web. E quell'iframe gestirà tutto ciò di cui ha bisogno per chattare con i tuoi clienti.

In che modo i widget di chat influenzano i Core Web Vitals?

I widget di chat influenzano i Core Web Vitals in diversi modi:

1. Influenzano il First Contentful Paint e il Largest Contentful Paint competendo per le risorse di rete iniziali.

2. Influenzano l'Interaction to Next Paint bloccando il main thread e talvolta aggiornandosi lentamente dopo l'interazione.

3. Possono causare layout shift quando non vengono renderizzati correttamente sulla pagina.

L'impatto varia molto tra i fornitori. I widget di chat più pesanti (Zendesk, Tawk.to) caricano dai 500 ai 750 KB di JavaScript. Alternative più leggere come Zoho Desk e Crisp rimangono sotto i 155 KB. In media, un widget di chat aggiunge dai 300 ai 600 ms di tempo di blocco del main thread. Questo è sufficiente per spingere un punteggio INP altrimenti positivo nella fascia "needs improvement" (necessita di miglioramenti).

Problemi di Largest Contentful Paint causati dai widget di chat

Un widget di chat può influenzare i Core Web Vitals quando compete per le risorse di rete. I file JavaScript sono solitamente messi in coda per il download prima delle immagini. Questo significa che, nello scenario peggiore (quando lo script di chat è render blocking), il browser deve aspettare che lo script di chat venga scaricato ed eseguito prima di poter continuare con qualsiasi altra cosa. Un widget di chat render-blocking può raddoppiare il First Contentful Paint da 1,0 secondi a oltre 2,3 secondi.

Anche quando lo script di chat è differito, può comunque avere un impatto sulle metriche di paint in diversi modi. Prima di tutto, lasciami spiegare cosa fanno gli script differiti. Il browser può scaricare gli script differiti in parallelo e può continuare il rendering fino all'evento DOMContentLoaded. Dopodiché eseguirà gli script. Il problema è che per i visitatori di ritorno, l'elemento LCP probabilmente non sarà caricato all'evento DOMContentLoaded ma lo script di chat (in cache) verrà eseguito causando un ritardo nelle metriche LCP.

Problemi di Interaction to Next Paint (INP) causati dai widget di chat

Un widget di chat può e influenzerà l'Interaction to Next Paint in 2 modi. Il primo modo è bloccando il main thread per un breve periodo mentre il widget di chat esegue i suoi script o verifica la presenza di aggiornamenti. Questo è semplicemente come funzionano le cose. Tutto ciò che aggiungi a una pagina rallenterà la pagina di un po'.

Il secondo modo in cui può causare problemi di INP è attraverso un codice scritto male (e credimi, ci sono alcuni widget di chat codificati male in giro). Quando si tratta di widget di chat "più popolare" non significa "codificato meglio". Quando un codice scadente impiega molto tempo ad aggiornare la presentazione, otterrai automaticamente problemi di INP. Immagino che alcuni fornitori di chat debbano migliorare il loro lavoro. Questa parte è purtroppo fuori dal mio controllo. Se hai scelto un widget di chat codificato male, non c'è modo per me di rendere quel codice migliore.

Problemi di Layout shift (CLS) causati dai widget di chat

A volte i widget di chat causano un layout shift. Ci sono 3 soliti sospetti che cerco quando controllo i layout shift correlati ai widget di chat.

• Layout shift che si verificano ogni volta al caricamento della chat
• Layout shift che si verificano su una "apertura chat" ritardata
• Layout shift che si verificano quando viene caricata una cronologia chat (visitatore chat di ritorno)

Come risolvere i problemi dei Core Web Vitals causati dagli script di chat

Fortunatamente è abbastanza facile minimizzare l'impatto che un widget di chat può avere sulle metriche di paint (LCP e FCP) e su alcune parti dell'Interaction to Next Paint (INP). Nella mia dichiarazione di apertura ti ho detto che gli script hanno un tempo e un luogo. E per gli script di chat non è "subito e a tutti i costi". Mi piace caricare gli script di chat dopo l'evento load, quando la pagina non risponde all'input dell'utente e mi piace anche aggirare il preload scanner per evitare la competizione di rete.

Quindi come facciamo? Usiamo l'evento load perché quando l'evento load è stato attivato l'elemento LCP sarà stato disegnato sulla pagina (a meno che tu non lo abbia caricato in lazy loading con JavaScript). Usiamo requestIdleCallback per aspettare un momento inattivo in cui il browser non risponde all'input dell'utente. E usiamo JavaScript per iniettare lo script di chat per assicurarci che il preload scanner non riconosca immediatamente lo script src e inneschi un download anticipato (e questo è esattamente ciò che vogliamo evitare). Questo è lo stesso pattern di differimento degli script usato per gli embed di YouTube e Google Maps.

<script>
window.addEventListener('load', function(){
  requestIdleCallback(function(){
    var s = document.createElement('script');
    s.src = 'https://your-chat-widget-url.com/chat.js';
    document.body.appendChild(s);
  })
})
</script>

Nota che requestIdleCallback non è supportato in Safari. Usa un fallback: const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1)); e sostituisci requestIdleCallback con idle nell'esempio sopra.

Con questo pattern evento load più requestIdleCallback, l'impatto sul punteggio Lighthouse di un widget di chat scende da 9-16 punti a 0-1 punto.

Alternativa: caricamento basato sull'interazione

Invece di caricare il widget di chat automaticamente dopo l'evento load, puoi aspettare fino a quando il visitatore non interagisce effettivamente con la pagina. Ascolta mousemove, scroll, o touchstart e carica lo script di chat al primo evento. Questo garantisce un impatto zero su tutti i Core Web Vitals per i visitatori che non scrollano o interagiscono mai.

<script>
function loadChat() {
  var s = document.createElement('script');
  s.src = 'https://your-chat-widget-url.com/chat.js';
  document.body.appendChild(s);
  ['mousemove','scroll','touchstart'].forEach(function(e){
    document.removeEventListener(e, loadChat);
  });
}
['mousemove','scroll','touchstart'].forEach(function(e){
  document.addEventListener(e, loadChat, {once: true});
});
</script>

Risolvere i problemi di Cumulative Layout Shift causati dai widget di chat

I widget di chat di solito causano un piccolo layout shift. Questo non deve essere un problema enorme. Ma a volte i widget di chat vengono semplicemente renderizzati male. Fortunatamente possiamo (più o meno) risolvere anche questo nascondendo il cattivo rendering fino a quando il widget non ha finito il rendering.

Per fare questo dobbiamo leggere la documentazione del widget di chat (ci sono molti fornitori di chat diversi e funzionano tutti in modo leggermente diverso). Nella documentazione cerca le funzioni di callback che vengono chiamate nelle diverse fasi del rendering della chat. Dato che non so quale widget di chat stai utilizzando, per illustrare il meccanismo useremo la funzione chat.ready().

Ora con un po' di stile intelligente possiamo nascondere e mostrare la chat con la proprietà CSS opacity. Per prima cosa aggiungiamo alcune classi per nascondere il widget di chat di default (cambia i selettori per farli corrispondere al tuo widget di chat). Quindi nel callback chat.ready() aggiungiamo "showchat" alla classlist del body per attivare la seconda riga CSS che mostra di nuovo la chat.

<style>
/*hide chat widget by default*/
.chatwidget{opacity:0}
/*show chat widget after .showchat body class*/
body.showchat .chatwidget {opacity:1}
</style>

<script>
chat.ready(function(){
  document.documentElement.classList.add('showchat');
})
</script>

Questo è tutto! Buona fortuna a velocizzare il tuo widget di chat. Per verificare i tuoi cambiamenti con visitatori reali, imposta il Real User Monitoring. I punteggi di laboratorio sono utili per il debugging, ma i dati sul campo di utenti reali sono ciò che Google usa per il ranking.