Widget de chat avec des Core Web Vitals parfaits

Comment charger correctement un widget de chat

Je l'ai dit et répété. Certains scripts sont plus importants que d'autres. Personne dans l'histoire de l'internet n'a jamais été contrarié qu'un widget de chat ne se soit pas chargé dans les 500 premières millisecondes du chargement de la page. Ce moment où la page est encore blanche.

Il ne serait pas logique de charger un widget de chat avant même que le contenu principal de la page n'ait commencé à se charger, n'est-ce pas ? Non, il serait beaucoup plus logique de charger d'abord les éléments les plus importants (votre logo, votre image principale, vos feuilles de style, vos polices, peut-être quelques scripts super importants qui gèrent la navigation et la conversion).

Les études montrent que seulement 3 à 10 % des visiteurs utilisent réellement un widget de chat au cours de leur session. Différer le script de chat ne vous coûte rien en termes de user experience mais vous fait tout gagner en termes de vitesse de page.

Malheureusement, ce n'est pas ainsi que la plupart des sites web procèdent. Je vois quotidiennement des scripts sans importance (comme les scripts de chat) se charger avec la priorité la plus élevée immédiatement au début du chargement de la page.

Dans cet article, je vais expliquer comment charger correctement un script de chat et comment cela affecte des métriques importantes telles que le Largest Contentful Paint et l'Interaction to Next Paint.

Dernière révision par Arjen Karel en février 2026

Contexte : comment fonctionnent les widgets de chat

Un widget de chat fonctionne généralement en chargeant un petit script sur votre page. Ce script va charger quelques styles et injecter une iframe sur votre page. Une iframe est une petite page web isolée à l'intérieur d'une page web. Et cette iframe gérera tout ce dont elle a besoin pour discuter avec vos clients.

Comment les widgets de chat affectent-ils les Core Web Vitals ?

Les widgets de chat affectent les Core Web Vitals de plusieurs manières :

1. Ils affectent le First Contentful Paint et le Largest Contentful Paint en se disputant les ressources réseau initiales.

2. Ils affectent l'Interaction to Next Paint en bloquant le thread principal et parfois en se mettant à jour lentement après l'interaction.

3. Ils peuvent provoquer des layout shifts lorsqu'ils ne s'affichent pas correctement sur la page.

L'impact varie beaucoup selon les fournisseurs. Les widgets de chat les plus lourds (Zendesk, Tawk.to) chargent de 500 à 750 Ko de JavaScript. Les alternatives plus légères comme Zoho Desk et Crisp restent sous la barre des 155 Ko. En moyenne, un widget de chat ajoute 300 à 600 ms de temps de blocage du thread principal. C'est suffisant pour faire passer un score INP qui serait autrement acceptable dans la catégorie "needs improvement".

Problèmes de Largest Contentful Paint causés par les widgets de chat

Un widget de chat peut affecter les Core Web Vitals lorsqu'il est en concurrence pour les ressources réseau. Les fichiers JavaScript sont généralement mis en file d'attente pour le téléchargement plus tôt que les images. Cela signifie que, dans le pire des cas (lorsque le script de chat bloque le rendu), le navigateur doit attendre que le script de chat soit téléchargé et exécuté avant de pouvoir continuer avec autre chose. Un widget de chat bloquant le rendu peut doubler le First Contentful Paint de 1,0 seconde à plus de 2,3 secondes.

Même lorsque le script de chat est différé, il peut toujours impacter les métriques de peinture de plusieurs manières. Laissez-moi d'abord vous expliquer ce que font les scripts différés. Le navigateur peut télécharger des scripts différés en parallèle et le navigateur peut continuer le rendu jusqu'à l'événement DOMContentLoaded. Après cela, il exécutera les scripts. Le problème est que pour les visiteurs récurrents, l'élément LCP ne sera probablement pas chargé lors de l'événement DOMContentLoaded, mais le script de chat (mis en cache) s'exécutera, provoquant un retard dans les métriques LCP.

Problèmes d'Interaction to Next Paint (INP) causés par les widgets de chat

Un widget de chat peut et va impacter l'Interaction to Next Paint de 2 manières. La première manière est en bloquant le thread principal pendant une courte période pendant que le widget de chat exécute ses scripts ou recherche des mises à jour. C'est simplement ainsi que les choses fonctionnent. Tout ce que vous ajoutez à une page ralentira un peu la page.

La deuxième façon dont il peut causer des problèmes d'INP est par un mauvais codage (et croyez-moi, il y a des widgets de chat mal codés). En ce qui concerne les widgets de chat, "plus populaire" ne signifie pas "mieux codé". Lorsqu'un mauvais code met du temps à mettre à jour la présentation, vous obtiendrez automatiquement des problèmes d'INP. Je suppose que certains fournisseurs de chat doivent améliorer leur jeu. Cette partie est malheureusement hors de mon contrôle. Si vous avez choisi un widget de chat mal codé, je n'ai aucun moyen d'améliorer ce code.

Problèmes de Cumulative Layout Shift (CLS) causés par les widgets de chat

Parfois, les widgets de chat provoquent un layout shift. Il y a 3 suspects habituels que je recherche lors de la vérification des layout shifts liés aux widgets de chat.

• Les layout shifts qui se produisent à chaque fois lors du chargement du chat
• Les layout shifts qui se produisent lors d'une "ouverture de chat" retardée
• Les layout shifts qui se produisent lorsqu'un historique de chat est chargé (visiteur récurrent)

Comment résoudre les problèmes de Core Web Vitals causés par les scripts de chat

Heureusement, il est assez facile de minimiser l'impact qu'un widget de chat peut avoir sur les métriques de peinture (LCP et FCP) et sur certaines parties de l'Interaction to Next Paint (INP). Dans ma déclaration d'ouverture, je vous ai dit que les scripts ont un moment et un endroit. Et pour les scripts de chat, ce n'est pas "tout de suite et à tout prix". J'aime charger les scripts de chat après l'événement load, lorsque la page ne répond pas aux entrées de l'utilisateur et j'aime aussi contourner le scanner de préchargement pour éviter la concurrence sur le réseau.

Alors, comment faisons-nous cela ? Nous utilisons l'événement load car lorsque l'événement load a été déclenché, l'élément LCP aura été peint sur la page (à moins que vous ne l'ayez chargé paresseusement avec du JavaScript). Nous utilisons requestIdleCallback pour attendre un moment inactif (idle) lorsque le navigateur ne répond pas aux entrées de l'utilisateur. Et nous utilisons JavaScript pour injecter le script de chat afin de s'assurer que le scanner de préchargement ne reconnaît pas immédiatement le src du script et ne déclenche pas un téléchargement précoce (et c'est exactement ce que nous voulons éviter). C'est le même modèle de report de script utilisé pour les intégrations YouTube et 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>

Notez que requestIdleCallback n'est pas pris en charge dans Safari. Utilisez un fallback : const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1)); et remplacez requestIdleCallback par idle dans l'exemple ci-dessus.

Avec ce modèle d'événement load plus requestIdleCallback, l'impact du score Lighthouse d'un widget de chat chute de 9 à 16 points à 0 à 1 point.

Alternative : chargement basé sur l'interaction

Au lieu de charger le widget de chat automatiquement après l'événement load, vous pouvez attendre que le visiteur interagisse réellement avec la page. Écoutez mousemove, scroll ou touchstart et chargez le script de chat lors du premier événement. Cela garantit un impact nul sur tous les Core Web Vitals pour les visiteurs qui ne font jamais défiler ou n'interagissent jamais.

<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>

Résoudre les problèmes de Cumulative Layout Shift causés par les widgets de chat

Les widgets de chat provoqueront généralement un petit layout shift. Cela ne doit pas être un énorme problème. Mais parfois, le rendu des widgets de chat est tout simplement médiocre. Heureusement, nous pouvons (en quelque sorte) résoudre ce problème également en masquant le mauvais rendu jusqu'à ce que le widget ait terminé son rendu.

Pour ce faire, nous devons lire la documentation du widget de chat (il existe de nombreux fournisseurs de chat différents et ils fonctionnent tous d'une manière légèrement différente). Dans la documentation, recherchez les fonctions de rappel (callbacks) qui sont appelées à différentes étapes du rendu du chat. Comme je ne sais pas quel widget de chat vous utilisez, pour illustrer le mécanisme, nous utiliserons la fonction chat.ready().

Maintenant, avec un style intelligent, nous pouvons masquer et afficher le chat avec la propriété CSS opacity. Tout d'abord, nous ajoutons quelques classes pour masquer le widget de chat par défaut (modifiez les sélecteurs pour qu'ils correspondent à votre widget de chat). Ensuite, dans le rappel chat.ready(), nous ajoutons "showchat" à la liste des classes du body pour activer la deuxième ligne CSS qui affiche à nouveau le 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>

C'est tout ! Bonne chance pour accélérer votre widget de chat. Pour vérifier vos modifications avec de vrais visiteurs, configurez le Real User Monitoring. Les scores de laboratoire sont utiles pour le débogage, mais ce sont les données de terrain des vrais utilisateurs que Google utilise pour le classement.