vendredi 25 septembre 2026

À propos

Contact

Performance

Scripts tiers sur WordPress : limiter l’impact d’analytics, chat et pubs

Analytics, chat en direct, régie publicitaire : ces scripts tiers plombent souvent le TBT. Chargement après interaction, façades et consentement, mode d'emploi.

Par Clément Hadrot • 19 février 2021 • 4 min de lecture • Aucun commentaire
Scripts tiers sur WordPress : limiter l'impact d'analytics, chat et pubs

Un client vendait un site rapide, propre en Lighthouse sur son environnement de recette. En production, le score chutait de trente points. La différence : trois scripts tiers absents de la recette mais bien présents en production, un outil d’analytics, un widget de chat, et un script de régie publicitaire. Aucun des trois n’était sous notre contrôle direct, et pourtant leur impact retombait entièrement sur l’expérience du site.

Le problème des scripts qu’on ne maîtrise pas

Contrairement au code du thème, un script tiers échappe largement à l’optimisation classique : on ne peut ni le minifier soi-même, ni changer sa logique interne. Ce qu’on peut en revanche contrôler, c’est quand et comment il se charge. C’est là que se joue l’essentiel du gain de performance sur ce type de dépendance.

Technique 1 : charger après interaction

Un widget de chat n’a aucune utilité tant que le visiteur ne l’a pas ouvert. Plutôt que de le charger dès l’arrivée sur la page, on peut différer son chargement jusqu’au premier signe d’interaction (défilement, mouvement de souris, ou clic sur une pastille de façade) :

let chatLoaded = false;

function loadChatWidget() {
  if (chatLoaded) return;
  chatLoaded = true;
  const script = document.createElement('script');
  script.src = 'https://widget.chat-fictif.test/embed.js';
  document.body.appendChild(script);
}

['scroll', 'mousemove', 'touchstart'].forEach((evt) => {
  window.addEventListener(evt, loadChatWidget, { once: true, passive: true });
});

document.getElementById('chat-facade')?.addEventListener('click', loadChatWidget);

Pour les visiteurs qui ne défilent jamais et ne touchent jamais la pastille (une minorité, mais elle existe), ajoutez un délai de repli, par exemple cinq secondes après le chargement complet de la page.

Technique 2 : la façade légère

Une façade est une image ou un élément statique qui imite visuellement le widget final, sans charger son code. C’est la technique popularisée pour les lecteurs vidéo YouTube, mais elle s’applique tout aussi bien à un widget de chat ou à une carte interactive :

<div id="chat-facade" class="chat-bulle-statique">
  <span>Discuter avec nous</span>
</div>

Le poids d’une façade se mesure en kilo-octets, contre plusieurs centaines de kilo-octets pour la plupart des widgets de chat complets une fois leurs dépendances chargées.

L'essentiel à retenir : Une façade légère remplace un widget lourd tant qu'il n'est pas sollicité ; Le chargement après interaction élimine le coût pour les visiteurs qui ne cliquent jamais ; Le consentement RGPD peut devenir un levier de performance

Technique 3 : Partytown pour isoler les scripts sur un worker

Certains scripts, en particulier les balises publicitaires, doivent se charger tôt pour ne pas perdre en revenu. Partytown propose une approche différente : exécuter ces scripts dans un worker web, un fil d’exécution séparé du fil principal du navigateur, pour qu’ils ne bloquent plus le rendu ni l’interactivité de la page :

<script type="text/partytown" src="https://regie-pub-fictive.test/tag.js"></script>

Cette approche exige un peu de configuration côté build (Partytown copie ses fichiers de service worker dans le dossier public) et ne convient pas à tous les scripts : ceux qui manipulent directement le DOM de la page en continu s’adaptent mal à l’isolation dans un worker. Testez systématiquement le comportement du script concerné après la bascule.

Technique 4 : conditionner le chargement au consentement

Sur un site soumis au consentement RGPD, la plupart des scripts d’analytics et de publicité ne devraient de toute façon pas se charger avant que le visiteur n’ait donné son accord. C’est une contrainte légale, mais aussi une opportunité de performance : tant qu’aucun consentement n’est donné, ces scripts n’existent simplement pas dans la page.

  • Chargez le script de gestion du consentement en priorité, léger et rapide.
  • N’injectez le script de mesure qu’après un événement de consentement explicite, jamais en pari anticipé.
  • Documentez cette dépendance : un changement de bannière de consentement peut casser silencieusement le chargement différé.

Un script qu’on ne charge pas est toujours plus rapide qu’un script bien optimisé : la première question à poser est « en a-t-on vraiment besoin ici ».

Notre verdict

Aucune de ces quatre techniques ne remplace une négociation avec l’éditeur du script pour réduire son poids à la source, mais elles restent souvent hors de portée d’un client final. Charger après interaction, façader, isoler dans un worker et conditionner au consentement forment un ensemble d’outils applicables dès aujourd’hui, sans attendre qu’un fournisseur tiers change son code.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi