# Un chatbot HubSpot ajoutait 400 ms à chaque page : le correctif appliqué

> Symptôme, diagnostic d'un widget chargé avant interaction, correctif par chargement au premier scroll, pour un site vitrine chargé en outils marketing.

- Auteur : Clément Hadrot
- Publié le : 2024-04-28
- Mis à jour le : 2024-04-28
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/chatbot-hubspot-400ms-chargement-differe/

## L’essentiel

- Un widget de chat tiers charge souvent son script avant toute interaction réelle de l'utilisateur
- Retarder le chargement jusqu'au premier geste utilisateur ne change rien à la disponibilité perçue du chat
- Le gain se voit directement sur le LCP et le temps de blocage principal

+ 400 millisecondes de « Total Blocking Time » sur le rapport Lighthouse, apparues du jour au lendemain sans qu'aucune modification n'ait été apportée au thème ou aux plugins du site. L'enquête a rapidement mené vers l'ajout, la semaine précédente, d'un widget de chat conversationnel HubSpot sur l'ensemble des pages du site vitrine.

Le site, déjà chargé en outils marketing (suivi analytics, pixel publicitaire, gestionnaire de consentement), a vu son score de performance Lighthouse chuter de dix points après cet ajout, avec un impact particulièrement net sur le Largest Contentful Paint et le temps de blocage principal du thread principal.

## Diagnostic : un script chargé de façon anticipée et bloquante

Le code d'intégration fourni par HubSpot, inséré via le champ « code de suivi » du thème, chargeait le script du widget dès le chargement initial de la page, sans attribut `defer` ni `async` :

```
<script type="text/javascript" id="hs-script-loader"
        src="//js.hs-scripts.com/000000.js"></script>
```

Ce script, une fois exécuté, initialise l'ensemble du widget de conversation : chargement de ses propres feuilles de style, de ses polices, et l'établissement d'une connexion pour vérifier la disponibilité d'un conseiller. Tout ce travail s'exécutait immédiatement au chargement de la page, y compris pour les visiteurs qui ne consultaient qu'un article de blog sans jamais avoir l'intention d'ouvrir la conversation.

## Pourquoi retarder le chargement ne dégrade pas l'expérience

> L'essentiel à retenir : Un widget de chat tiers charge souvent son script avant toute interaction réelle de l'utilisateur ; Retarder le chargement jusqu'au premier geste utilisateur ne change rien à la disponibilité perçue du chat ; Le gain se voit directement sur le LCP et le temps de blocage principal

L'hypothèse testée reposait sur un constat comportemental simple : un visiteur qui arrive sur une page ne clique quasiment jamais sur la bulle de chat dans la première seconde. Retarder le chargement du script jusqu'à un signal d'engagement réel — un défilement de la page, un mouvement de souris, ou après un délai de secours de quelques secondes — ne change rien pour l'immense majorité des visiteurs, tout en libérant le fil principal pendant le chargement initial, la phase la plus critique pour le Largest Contentful Paint.

## Le correctif appliqué

```
<script>
(function () {
    var charge = false;
    function chargerWidgetChat() {
        if ( charge ) { return; }
        charge = true;
        var script = document.createElement( 'script' );
        script.src = '//js.hs-scripts.com/000000.js';
        document.body.appendChild( script );
        window.removeEventListener( 'scroll', chargerWidgetChat );
        document.removeEventListener( 'mousemove', chargerWidgetChat );
    }
    window.addEventListener( 'scroll', chargerWidgetChat, { passive: true } );
    document.addEventListener( 'mousemove', chargerWidgetChat );
    setTimeout( chargerWidgetChat, 5000 );
})();
</script>
```

Ce snippet écoute trois signaux distincts : un défilement, un mouvement de souris, ou à défaut un délai de secours de cinq secondes garantissant que le widget finit toujours par se charger, y compris pour un visiteur parfaitement immobile sur la page (lecture attentive d'un long article, par exemple).

## Résultats mesurés

| Mesure Lighthouse | Chargement immédiat | Chargement différé |
| --- | --- | --- |
| Temps de blocage principal | + 400 ms | + 15 ms |
| Largest Contentful Paint | 2,9 s | 2,1 s |
| Score de performance Lighthouse | 68 | 89 |

Le suivi du taux d'ouverture du widget de chat, comparé sur les deux semaines encadrant le changement, n'a montré aucune baisse statistiquement notable, confirmant que le délai introduit n'a pas dissuadé les visiteurs réellement intéressés par la conversation.

### Un point de vigilance sur le gestionnaire de consentement

- Le chargement différé du widget doit rester compatible avec la logique de consentement aux cookies : le script ne doit se charger qu'après acceptation, pas uniquement après le premier scroll, si le widget dépose des cookies non essentiels.
- Un délai de secours trop long peut frustrer un visiteur qui cherche activement le widget de chat sans faire défiler la page ; cinq secondes a été retenu comme compromis raisonnable après plusieurs essais.
- Ce correctif ne modifie en rien le paramétrage conversationnel du chatbot lui-même, uniquement son moment de chargement technique.

> Un widget marketing tiers n'a aucune raison de peser sur le chargement d'une page tant que personne n'a manifesté la moindre intention de s'en servir.

## En résumé

Le chargement différé jusqu'au premier signal d'engagement a permis de récupérer l'essentiel du score de performance perdu, sans renoncer au widget ni modifier son comportement conversationnel. Ce type de correctif, applicable à la plupart des scripts de widgets tiers du même genre, mérite d'être vérifié systématiquement avant d'accepter qu'un outil marketing dégrade silencieusement l'expérience de chargement d'un site.