Les sites web sont de plus en plus lourds, et ce n’est plus une impression. Le chapitre Page Weight du Web Almanac 2025 mesure une page d’accueil médiane de 2,56 Mo sur mobile et 2,86 Mo sur desktop, en hausse de 8 % en un an, et rappelle qu’en juillet 2015 la même page mobile pesait 845 Ko. En dix ans, le poids d’une page mobile a triplé, et ce n’est plus l’image qui tire la courbe.
Un script tiers est un fichier JavaScript servi depuis un domaine qui n’est pas le vôtre, et qui s’exécute dans vos pages avec les mêmes droits que votre propre code : outil de mesure, tag manager, régie, chat, avis clients, test A/B, bandeau de consentement. Le Web Almanac 2025 relève que plus de neuf pages sur dix en embarquent au moins un, pour une médiane de 79 requêtes tierces par page mobile. Ces scripts s’ajoutent au fil des besoins de chaque équipe et ne sont presque jamais retirés.
Ce guide pose le cadre commun à toute cette famille : pourquoi son poids a changé de nature, ce qu’un script tiers coûte réellement au-delà de ses kilooctets, comment le mesurer chez vous, et comment le gouverner dans la durée. Chaque famille d’outils a ensuite son propre guide sur ce blog, du tag manager aux widgets de chat. Combien de scripts tiers s’exécutent sur votre page d’accueil, et combien d’entre eux servent encore à quelqu’un ?
Pourquoi le JavaScript tiers pèse-t-il de plus en plus ?
Parce que la nature du poids des pages a changé. Pendant dix ans, la hausse venait des images ; elle vient désormais du JavaScript, dont le Web Almanac 2025 mesure 632 Ko par page d’accueil mobile, soit un quart du poids total, et pour une large part du JavaScript tiers. Ces scripts s’empilent sans propriétaire ni date de retrait, au rythme des besoins du marketing.
De jQuery aux frameworks, puis aux outils
Longtemps, le JavaScript d’une page se résumait à jQuery, quelques extensions et un Google Analytics. À partir de 2015, les frameworks se sont démocratisés, les applications monopage sous React ou Angular sont devenues la norme des refontes, et JavaScript est devenu incontournable pour tout éditeur. Cette première vague était du code de première partie, écrit ou choisi par l’équipe technique, et maîtrisable par elle.
La seconde vague est venue des outils, posés le plus souvent par un tag manager : suivi de fréquentation, retargeting publicitaire et social, voix du client, A/B testing, analyse comportementale, surcouches d’accessibilité, anti-robots. Puis le RGPD a rendu incontournables les plateformes de gestion du consentement, elles aussi construites en JavaScript pour interagir avec les cookies, comme le détaille notre guide pour bien choisir sa CMP. Cette seconde vague est du code de tiers, que l’équipe technique ne lit pas et ne contrôle pas, et c’est elle qui domine aujourd’hui.
Un conteneur qui charge des conteneurs
Le tag manager a rendu la pose d’un script indolore, et son retrait improbable, puisqu’il ne passe plus par un déploiement. Le projet third-party-web, qui agrège les audits Lighthouse de l’HTTP Archive, place Google Tag Manager en tête de tous les tiers du web par temps d’exécution cumulé, avec 1 066 ms d’impact moyen par page. Nous reviendrons sur ce chiffre dans un guide dédié au conteneur ; ce qu’il faut retenir ici, c’est que le conteneur n’est pas neutre, il est le premier script tiers de la page.
Quel est l’impact des scripts tiers sur la performance ?
Leur coût dépasse largement leur poids. Un script tiers doit être téléchargé, décompressé, analysé, compilé puis exécuté sur le thread principal, celui-là même qui affiche la page et répond aux clics. C’est le temps d’exécution qui dégrade l’INP, bien plus que les kilooctets transférés, et il se paie à chaque page, cache ou pas.
Le thread principal, un fil unique
Le navigateur n’a qu’un seul fil d’exécution pour analyser le HTML, calculer les styles, mettre en page, peindre et exécuter le JavaScript. Chaque script tiers qui s’exécute y prend sa place, et pendant ce temps rien d’autre n’avance : ni le rendu de l’image principale, ni la réponse au clic du visiteur. Ce temps de blocage se lit dans le Total Blocking Time de Lighthouse au chargement, et dans l’Interaction to Next Paint des Core Web Vitals pendant toute la visite.
Le poids ne dit rien de ce temps. Quarante kilooctets qui parcourent le DOM et posent des observateurs peuvent bloquer plus longtemps qu’un fichier trois fois plus lourd qui ne fait qu’attendre.
L’INP a remplacé le First Input Delay comme Core Web Vital le 12 mars 2024, et ce changement a durci la mesure : là où le FID ne regardait que le délai de la première interaction, l’INP retient la pire interaction de toute la visite, jusqu’à la peinture suivante. Un script tiers qui se réveille à chaque clic, comme un tag manager qui réévalue ses déclencheurs à chaque événement, est devenu visible dans la métrique là où il ne l’était pas. Notre guide sur l’INP et comment l’optimiser détaille cette mécanique.
Les écueils que nous retrouvons dans presque chaque audit
Cette prolifération va de pair avec une mauvaise compréhension des enjeux, et les mêmes erreurs reviennent d’un site à l’autre. Nos clients chargent couramment deux ou trois conteneurs Google Tag Manager, un pour eux et un par prestataire, alors qu’une seule balise Google sait envoyer les données vers plusieurs destinations. D’autres écueils sont tout aussi fréquents :
- une CMP mal configurée, avec des scripts tiers qui se chargent avant tout consentement, ce qui la rend inutile et expose l’éditeur ;
- un script d’A/B testing actif alors qu’aucun test n’est en cours, avec son masquage de page qui pénalise le LCP pour rien ;
- des pixels de retargeting Facebook, TikTok ou LinkedIn qui tournent alors qu’aucune campagne publicitaire n’est active ;
- des widgets de chat, d’avis ou de prise de rendez-vous chargés sur toutes les pages, y compris celles où ils n’ont aucun rôle ;
- une mauvaise priorisation, avec des scripts tiers qui s’exécutent avant les scripts nécessaires au fonctionnement du site, parfois avant l’image principale.
Chacun de ces cas mérite son guide détaillé : celui sur l’impact de Google Analytics est en ligne, ceux sur le vrai prix de l’anti-flicker en A/B testing et sur le coût des widgets de chat, d’avis et d’enquêtes suivront. Le point commun est toujours le même : le coût est payé par tous les visiteurs pour l’usage de quelques-uns, et personne ne l’a mesuré.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Comment mesurer le coût réel d’un script tiers ?
Trois chiffres suffisent à qualifier un script : son poids transféré, son temps d’exécution sur le thread principal, et le nombre de connexions supplémentaires qu’il ouvre. Le deuxième est le plus déterminant et le moins regardé, alors qu’il se lit directement dans l’onglet Performance des outils de développement, trié par origine.
La méthode tient en quelques minutes. Ouvrez le panneau Performance de Chrome, enregistrez un chargement, puis groupez l’activité par domaine : chaque tiers apparaît avec son temps d’analyse et d’exécution cumulé, et l’insight Third parties de Lighthouse 13 en donne la même lecture depuis octobre 2025. Le test décisif reste la comparaison avec et sans. Bloquez le domaine du script, rechargez, relevez l’écart sur le LCP et sur le temps de blocage. Le chiffre obtenu est celui à présenter à l’équipe qui a demandé l’outil :
# Reference : page telle quelle
lighthouse https://www.exemple.fr/ --preset=desktop --output=json --output-path=./avec.json
# Meme page, un domaine tiers bloque (repeter pour chaque script, un a la fois)
lighthouse https://www.exemple.fr/ --preset=desktop --output=json --output-path=./sans.json \
--blocked-url-patterns="*static.hotjar.com*"
# Ecart LCP et TBT entre les deux rapports
jq '.audits["largest-contentful-paint"].numericValue, .audits["total-blocking-time"].numericValue' avec.json sans.jsonMesurez un script à la fois, jamais tous ensemble : les coûts ne s’additionnent pas linéairement quand plusieurs scripts se disputent le thread principal, et un blocage global masque lequel pèse le plus. Mesurez aussi sur une page représentative du parcours, fiche produit ou article, pas seulement sur la page d’accueil. Le laboratoire ne verra pas l’INP, que seul le terrain révèle, mais il suffit à désigner le script à traiter en premier.
Comment réduire l’impact des scripts tiers ?
Trois gestes dans l’ordre : retirer ce qui ne sert plus, différer ce qui n’est pas nécessaire au premier écran, et charger à l’interaction ce qui n’est utile qu’après une action. Le premier geste est de loin le plus rentable, et c’est celui qu’on saute presque toujours, parce qu’il demande une décision plutôt qu’une ligne de code.
Async et defer, ce qu’ils font et ne font pas
Les attributs async et defer modifient profondément le comportement de chargement d’un script, mais aucun des deux ne réduit son coût d’exécution. Avec async, le téléchargement ne bloque plus l’analyse du HTML, mais le script s’exécute dès qu’il arrive, à un moment imprévisible, souvent au milieu du rendu. Avec defer, l’exécution attend la fin de l’analyse du document et respecte l’ordre des balises. Les deux déplacent l’exécution, ils ne l’allègent pas : un script de 800 ms reste un script de 800 ms.
async et defer modifie profondément le comportement de chargement des scripts, pas leur coût d’exécution.La position compte autant que l’attribut. Un script en defer posé en tête du <head> s’exécute avant tous ceux qui le suivent, même différés ; posé juste avant </body> avec fetchpriority="low", il passe réellement après le contenu. C’est la forme que nous donnons à tout script tiers non critique, à une exception près, la CMP, qui conditionne les autres et doit arriver en premier :
<!-- Dans le <head> : seulement ce qui conditionne le reste -->
<script src="https://cmp.exemple.com/consent.js" async></script>
<!-- Juste avant </body> : tous les autres tiers, en defer et priorite basse -->
<script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX" defer fetchpriority="low"></script>
<script src="https://static.exemple-avis.com/widget.js" defer fetchpriority="low"></script>
</body>Charger à l’interaction, pas au défilement
Pour les scripts dont le chargement est transparent pour le visiteur, la mesure ou le retargeting, il est pertinent d’en retarder l’exécution à la première interaction, clic, touche ou pointeur, avec un délai plafond pour les visiteurs qui n’interagissent jamais. Le report au défilement, que proposent plusieurs extensions, est un faux ami : il déplace le pic d’exécution exactement là où l’INP se mesure.
Pour un chat ou un widget de réassurance, la façade, un bouton statique qui charge le vrai widget au premier clic, reste la technique la plus efficace, même si Lighthouse 13 a retiré l’audit qui la recommandait. Notre guide sur les widgets en donne une version complète et copiable.
Faut-il supprimer tous les scripts tiers ?
Non, et poser la question ainsi mène à l’impasse. Un outil d’analyse d’audience, un système de paiement ou un moteur de recherche interne rendent un service que le site ne peut pas produire seul. La question utile est celle du rapport valeur sur coût, script par script, pas celle d’une suppression en bloc que personne ne validera.
Trois cas se distinguent nettement. Les scripts indispensables au fonctionnement se gardent et s’optimisent ; ceux dont la valeur est réelle mais différable se chargent après le premier écran ou à l’interaction ; ceux dont plus personne ne réclame les données se retirent. Le consultant britannique Andy Davies rapporte le cas d’une compagnie aérienne européenne dont l’audit a révélé qu’environ un tiers des tags avaient un abonnement expiré, certains continuant de servir leur script complet. Ce tiers se retrouve sur presque tous les sites de plus de trois ans, et il en résume la tension.
Il y a aussi une tension entre la valeur qu’apportent les tags et les coûts qu’ils imposent en matière de vie privée, de sécurité et de vitesse.
Andy Davies, consultant en web performance, dans son article Reducing the Site-Speed Impact of Third-Party Tags, publié le 2 octobre 2020
L’inventaire est le préalable qui manque presque toujours. Lister les domaines tiers appelés par une page représentative prend dix minutes et produit systématiquement des surprises : outils d’une campagne terminée, doublons de mesure, script d’un prestataire dont le contrat s’est achevé. Chacun continue de s’exécuter chez tous vos visiteurs, et chacun a été validé un jour par quelqu’un qui n’y pense plus.
Comment gouverner les scripts tiers dans la durée ?
En traitant chaque ajout comme une dépense soumise à arbitrage : qui le demande, pour quel usage, pour combien de temps, et qui vérifie qu’il sert encore. Sans propriétaire nommé, un script n’est jamais retiré, car personne ne prend le risque de désactiver ce qu’il n’a pas installé, et une date de retrait inscrite à la pose est la seule règle qui tienne.
Au sein de l’agence, nous faisons face quotidiennement à ces problématiques. Dans le cadre de nos audits et de nos optimisations, la repriorisation du chargement des tiers est toujours une étape décisive, quand ils ne peuvent pas être simplement supprimés, et elle produit régulièrement les gains les plus visibles sur le LCP et l’INP.
Mais un site optimisé se dégrade seul, et le conteneur est le canal par lequel il se dégrade, parce qu’il permet d’ajouter sans déployer, donc sans mesurer. C’est pour cela que nos prestations de monitoring de la performance surveillent le nombre de domaines tiers comme une métrique à part entière : c’est celle qui bouge en premier, bien avant les Core Web Vitals.
Si vous rencontrez ce type de symptômes, interfaces peu réactives, INP en orange dans la Search Console, taux de rebond élevé sur mobile, un audit de performance web commence précisément par cet inventaire, script par script, avec le chiffre de chacun. Mener ce chantier sur un site existant permet couramment de multiplier le score PageSpeed Insights par deux ou plus, et la différence est d’autant plus appréciable que le site était lent au départ. Le script tiers le plus rapide reste celui qu’on a retiré, et il mérite qu’on se pose la question à chaque ajout.
