Scripts tiers : le budget que personne ne tient

Faisons l'addition sur une page d'un produit ordinaire. L'équipe a passé un trimestre à ramener le JavaScript applicatif de la page d'accueil à 140 Ko compressés. Sur la même page tournent un gestionnaire de balises, une mesure d'audience, un outil de relecture de sessions, un widget de support et un bandeau de consentement. Avec des tailles ordinaires pour ces cinq-là (90, 45, 110, 180 et 60 Ko), on arrive à 485 Ko, trois fois et demie ce qu'il a fallu un trimestre pour optimiser, et pas une ligne n'est passée par la revue de code.

Ce code-là n'a pas de budget parce qu'il n'a pas de propriétaire technique. Celui qui l'a demandé ne voit pas son coût, celui qui voit son coût n'a pas le pouvoir de le retirer. Tant que cette asymétrie reste en place, aucune optimisation du chargement ne tient plus de six mois.

Pourquoi un script tiers coûte plus que son poids

Le poids n'est que la partie visible. Le reste du coût tient à des propriétés que votre propre code n'a pas.

Le script s'exécute sur votre thread principal, avec les mêmes droits que votre application. Une balise <script> venue d'un autre domaine n'est pas isolée ; elle lit le DOM, pose des écouteurs sur document, observe chaque mutation. Un outil de relecture de sessions qui sérialise le DOM à chaque changement travaille exactement au moment où l'interface se met à jour, donc au moment où l'utilisateur vient d'agir.

Il change aussi sans que vous déployiez. L'URL intégrée pointe vers « la dernière version ». Le fournisseur pousse une mise à jour un mardi, le temps de réponse aux interactions se dégrade le mardi, et l'historique de déploiements ne montre rien ce jour-là.

Enfin, il en charge d'autres. Un gestionnaire de balises est un mécanisme de déploiement parallèle, qui permet d'ajouter du code en production depuis une interface web, sans revue, sans test, sans rollback lié au repo. Le widget de support charge sa propre bibliothèque de composants, ses polices, parfois son propre outil de mesure.