Le poids caché des scripts tiers : les tags qui sabotent la vitesse que tu paies ailleurs

Tu ajoutes une balise, c'est une ligne de code, collée en deux minutes, et tout le monde te dit que ça ne coûte rien. C'est faux. Chaque script tiers que tu poses, analytics, pixel publicitaire, widget de chat, outil de test, s'exécute sur l'appareil de ton visiteur, pas sur ton serveur. Tu passes des semaines à optimiser tes images, tes polices, ton hébergement, puis tu rends tout ce gain à un empilement de tags que personne ne surveille.

Le pire, c'est que ce coût est invisible pour toi. Sur ta machine de développeur, fibre et processeur récent, la stack de tags passe inaperçue. Sur le téléphone milieu de gamme de ton client, elle bloque le fil d'exécution au moment précis où il décide de rester ou de partir. Voici comment un script tiers pèse vraiment, pourquoi la plupart des tiens ne gagnent pas leur place, et comment reprendre le tri.

Le mécanisme : un tag ne se télécharge pas, il s'exécute

Un script tiers n'est pas une image passive que le navigateur affiche et oublie. C'est du code exécutable. Quand tu colles un snippet, le navigateur ouvre une connexion vers un serveur qui n'est pas le tien, négocie le DNS et le chiffrement, télécharge un premier fichier, qui en réclame souvent d'autres, puis exécute le tout sur le fil principal. Ce fil principal est une file à voie unique. Tant qu'un tag s'y exécute, ni ton contenu ni les clics de ton visiteur ne passent.

Multiplie ça par huit tags, chacun ouvrant sa propre connexion vers son propre domaine, chacun réclamant sa part du fil principal. Le navigateur ne les traite pas gratuitement en arrière-plan, il jongle, et pendant qu'il jongle, ton titre attend, ton bouton ne répond pas encore. C'est le même fil qui sert le rendu bloqué par le JavaScript : un tag tiers est du JavaScript comme un autre, sauf que tu ne l'as pas écrit et que tu ne le contrôles pas.

Le détail qui aggrave tout, c'est la réaction en chaîne. Beaucoup de tags en chargent d'autres à ton insu. Un gestionnaire de balises se présente comme un seul script, puis en injecte dix. Un widget de chat charge sa police, ses images, son moteur d'émojis. Tu crois avoir ajouté une ligne, tu as ouvert une porte. Et comme ces ressources viennent de domaines tiers, ton navigateur découvre tard qu'il doit s'y connecter, ce qui rallonge encore la file. C'est aussi ce qui dégrade la réactivité aux clics que mesure l'INP, parce qu'un fil principal saturé par les tags ne répond pas assez vite quand le doigt appuie.

La prise de position : la plupart de tes tags ne gagnent pas leur place

Je vais être direct. Une stack de tags s'accumule par inertie, jamais par décision. Chaque balise a été ajoutée un jour pour une bonne raison, une campagne, un test, un outil qu'on voulait essayer. Puis la campagne s'est terminée, le test a conclu, l'outil a été abandonné, et le tag est resté. Personne ne retire jamais rien, parce que retirer demande de vérifier, et que vérifier fait peur. Alors la couche s'épaissit, et son coût est payé par ton visiteur, pas par l'équipe qui a posé la balise.

Le vrai calcul n'est presque jamais fait. Un tag te rapporte une donnée, une fonctionnalité, un signal marketing. Ce bénéfice a un prix en temps machine, en fil principal bloqué, en conversions perdues sur mobile. Tant que tu ne poses pas les deux côtés de la balance, tu gardes tout par défaut, et le défaut te ruine lentement. C'est exactement le raisonnement d'un budget de performance : si ajouter un tag ne force personne à en retirer un autre, ta page n'a aucune limite, et une page sans limite finit toujours lente.

La question à te poser sur chaque balise n'est pas « est-ce que ça sert ? », presque tout sert un peu. C'est « est-ce que ça sert assez pour mériter le temps qu'elle vole à mon visiteur ? ». La plupart de tes tags ne passent pas ce test dès qu'on le pose vraiment.

Le teardown : les scripts qui n'ont jamais gagné leur place sur Copyboost

Sur Copyboost, une partie de la lenteur ne venait pas de mon code, mais de ce que j'avais empilé autour. Des scripts posés pendant le développement, gardés par réflexe, qui s'exécutaient au chargement alors qu'ils n'avaient aucune raison de partir si tôt. Le premier affichage attendait des choses dont le visiteur n'avait pas besoin pour décider de rester.

Le correctif n'a pas été un tour de magie technique. Il a été un tri. N'envoyer au chargement que ce qui sert la première seconde, repousser le reste après l'interaction, et supprimer ce dont plus personne ne se servait. C'est une partie de ce qui a fait passer le Lighthouse de Copyboost de 57 à plus de 75, sur le même principe que le tri du JavaScript : le gain n'était pas réparti partout, il venait de ce que j'ai cessé d'expédier.

La leçon vaut au-delà de Copyboost. Un site n'est presque jamais lent à cause d'une seule ressource énorme et évidente. Il est lent à cause de dix petites ressources tierces qui, chacune, semblaient anodines. C'est pour ça que la lenteur d'une stack de tags résiste aux corrections ponctuelles : il n'y a pas un coupable, il y en a dix, et tant que tu ne les regardes pas ensemble, tu n'en vois aucun. Le même piège que le score de labo qui te rassure pendant que tes vrais visiteurs rament.

L'artefact : le tri de tes tags en trois verdicts

Voici le protocole que j'applique. Il tient en un inventaire suivi d'un jugement par balise.

D'abord, l'inventaire. Ouvre l'onglet Réseau de Chrome, filtre par domaine, et liste tout ce qui ne vient pas de chez toi. Note pour chacun le poids transféré et le temps passé sur le fil principal, que l'onglet Performance te donne. Tu ne peux pas trier ce que tu n'as pas mesuré, donc ne devine pas, compte.

Ensuite, le jugement. Chaque tag reçoit un verdict parmi trois.

1. Garder, et servir tôt. Réserve ce statut aux scripts qui rendent un service que ton visiteur remarquerait s'il disparaissait, ou qui touchent directement au revenu. Ceux-là restent, mais tu leur donnes les moyens de ne pas bloquer, en async ou defer, jamais en synchrone en tête de page.
2. Différer. La plupart de tes tags tombent ici. Analytics, pixels, cartes de chaleur, chat : rien de tout ça n'a besoin de partir avant que la page soit affichée et utilisable. Charge-les après l'interaction, ou quand le fil principal est au repos. Ton visiteur ne verra aucune différence, ta première seconde en verra une énorme.
3. Supprimer. Tout tag sans propriétaire clair, sans usage vérifié depuis des mois, ou qui double un autre outil, part. Si personne ne peut dire quelle décision ce tag alimente, il ne coûte que du temps, il ne rapporte rien.

Un dernier levier, qui recoupe ta mesure autant que ta vitesse : le suivi côté serveur. Déplacer une partie de ta collecte analytics du navigateur vers ton propre serveur retire du fil principal de ton visiteur le poids de plusieurs tags, tout en rendant ta donnée plus fiable, parce qu'elle ne dépend plus des bloqueurs ni du navigateur. C'est le même mouvement que colmater les fuites de ton tunnel GA4 : tu mesures mieux en pesant moins.

Ce qu'il faut retenir

Un script tiers n'est pas gratuit parce qu'il est court à coller. Il s'exécute chez ton visiteur, sur le fil qui sert ton contenu et tes clics, et il y reste tant que personne ne le remet en cause. La plupart de tes tags ont été ajoutés pour une raison qui n'existe plus, et gardés parce que retirer fait peur. Inventorie-les sans en oublier un, pèse ce que chacun vole contre ce qu'il rapporte, puis tranche : garder et servir tôt, différer après l'interaction, ou supprimer. Ouvre l'onglet Réseau sur ta page la plus importante aujourd'hui, filtre les domaines qui ne sont pas les tiens, et compte-les. Le chiffre te surprendra, et la moitié de cette liste peut probablement attendre, ou disparaître, sans que personne ne s'en aperçoive, sauf ta première seconde. Si tu veux que je fasse ce tri pour toi et que je te dise quel tag te coûte le plus de conversions, c'est tout l'objet d'un diagnostic.