« C’est la pub. » « Non c’est Tag Manager. » « C’est le chat, on l’a toujours eu. » Tant que tu ne sais pas faire un vrai avant/après en isolant un script tiers, la discussion tourne en rond. Et en perf, les débats “au ressenti” finissent souvent avec le pire compromis possible : on garde tout, on “optimise” trois images, et les Core Web Vitals restent rouges.
Ce que je te propose ici, c’est une méthode d’attribution simple et défendable. Tu vas pouvoir dire : « Sur cette page, bloquer tel domaine fait gagner X ms de LCP, réduit CLS de Y, et enlève Z ms de main thread. » Et ensuite seulement, tu arbitres.
Le problème des scripts tiers : tu ne peux pas optimiser ce que tu n’attribues pas
Un script tiers ne plombe pas toujours la perf de la même manière. Parfois il retarde le rendu (LCP qui dérive), parfois il injecte du layout (CLS qui grimpe), parfois il monopolise le thread principal et flingue l’interactivité (INP qui explose sur mobile). Et souvent, il fait un mix des trois selon le timing, le réseau, le consentement, les A/B tests, la géoloc, le device… bref, selon l’utilisateur réel.
Le piège classique, c’est de s’accrocher à un score PageSpeed Insights en one-shot et de le brandir comme preuve. PSI est utile, mais en tant qu’arme de réunion c’est fragile : ça bouge beaucoup, ça dépend du run, et ça mélange des signaux lab/field. Pour “accuser” un tiers, tu veux un protocole qui tient quand quelqu’un te répond « refais le test ».
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le protocole d’attribution que j’utilise : un avant/après WebPageTest, reproductible
Le cœur du truc, c’est WebPageTest. Pourquoi ? Parce qu’il te donne à la fois le filmstrip (ce que l’utilisateur voit), le waterfall (qui télécharge quoi, quand), et des métriques lab stables si tu configures correctement. Et surtout : tu peux faire un vrai A/B en bloquant des requêtes vers un tiers, sans toucher au code et sans “croire” quelqu’un sur parole.
Choisis une page qui compte (landing SEO, page catégorie, page produit). Fixe un profil réaliste (mobile + 4G, ou ce qui correspond à ton audience). Garde les mêmes conditions entre tes runs : même localisation, même device, même connexion, même nombre de répétitions. L’objectif n’est pas d’avoir “le meilleur score”, c’est d’avoir un avant/après comparable.
Ensuite tu fais deux campagnes :
La baseline (rien bloqué), puis une variante où tu bloques le script tiers suspecté. Dans l’idéal tu bloques au niveau domaine (ou pattern d’URL), pas un fichier unique, parce qu’un tiers c’est souvent un grappin de sous-requêtes, pixels, endpoints, CDN, etc.
Bloquer un tiers proprement (sans bricoler le code)
Tu peux le faire via les options de blocage dans WebPageTest, ou via un script WebPageTest si tu veux versionner ton protocole. Exemple simple :
navigate https://example.com/ta-page
# Bloquer un tag manager ou un vendor
block https://www.googletagmanager.com/*
block https://connect.facebook.net/*
block https://www.google-analytics.com/*
block https://*.doubleclick.net/*Évidemment, n’en bloque pas dix d’un coup si tu veux attribuer. Un test = un suspect, sinon tu prouves juste « moins de scripts = mieux », ce qui n’aide personne à décider.
Pourquoi PSI en one-shot te raconte n’importe quoi (et comment le rendre utile)
Les scripts tiers sont bruités par nature. Ils changent, ils A/B testent, ils s’auto-mettront parfois en “slow mode”, ils dépendent de la charge serveur, ils déclenchent des requêtes conditionnelles. Résultat : un run isolé peut être “chanceux” ou “catastrophique” et tu peux soutenir deux thèses opposées avec deux captures.
La parade est bête, mais c’est ce qui transforme une opinion en preuve : tu répètes et tu prends une valeur robuste. Sur WebPageTest, tu peux lancer plusieurs runs et regarder la médiane (et pas le meilleur run, qui est souvent celui où le tiers s’est fait discret). Si tu utilises PSI pour une vérif rapide, fais pareil : répète et prends une médiane manuelle, en gardant les mêmes conditions et la même URL.
Autre point qui compte : fais attention au cache. Un script tiers peut être quasi “gratuit” en repeat view et très coûteux en first view. Si ton problème est “les nouveaux visiteurs SEO”, regarde le first view. Si ton problème est “nos utilisateurs reviennent tous les jours”, tu as besoin des deux.
Lire le waterfall comme un dev (et attribuer LCP, CLS, INP au bon coupable)
Le filmstrip te dit si le site “paraît” lent, mais le waterfall te dit pourquoi. Concrètement, ce que je cherche quand je suspecte un script tiers :
Pour le LCP, je regarde si le tiers crée de la contention réseau (beaucoup de requêtes tôt, ou de gros fichiers) ou s’il retarde du rendu via JS bloquant. Si bloquer le tiers décale le moment où la ressource LCP est demandée, ou si ça libère la bande passante et que l’image LCP finit plus tôt, tu as un signal clair. Dans les cas bien sales, le LCP n’est même pas l’image mais un élément injecté (hero remplacé, widget qui pousse le contenu). Là, le filmstrip rend le verdict en 3 secondes.
Pour le CLS, je cherche des injections tardives : bandeau, iframe pub qui se resize, widget de chat qui “ouvre” une zone, recommandations produit qui chargent après le rendu. Le pattern typique : la page semble stable, puis tu vois un micro-saut quand le tiers s’initialise. En lab tu peux aussi le rater si le timing change. C’est pour ça que le blocage ciblé est si puissant : tu ne “devines” pas, tu supprimes une cause et tu observes si la stabilité revient.
Pour l’INP, c’est rarement « une requête réseau lente ». C’est plus souvent « le main thread est occupé ». Un tiers qui parse un gros bundle, qui fait du DOM en boucle, qui écoute des events partout, ça peut ajouter des long tasks pile au mauvais moment. Dans WebPageTest tu peux recouper avec les timings et, côté navigateur, tu peux confirmer avec un enregistrement Performance dans Chrome DevTools sur un device représentatif. Si, en bloquant le tiers, tu réduis clairement les périodes où le thread principal est saturé, tu tiens une explication crédible.
Lab ≠ Field : valider le gain dans CrUX ou ton RUM (sinon c’est du théâtre)
Un avant/après lab te dit « ce script peut coûter cher ». Il ne te dit pas forcément « il coûte cher à tes utilisateurs ». La validation finale, c’est le terrain.
Si tu as assez de trafic, CrUX (via PageSpeed Insights partie “données de terrain”, ou via BigQuery/CrUX API) te permet de vérifier si les distributions bougent vraiment, pas juste une moyenne. Tu veux voir des améliorations sur les percentiles qui comptent (souvent p75 pour les CWV). Et tu veux segmenter intelligemment : mobile vs desktop, pages concernées, pays si ton audience varie, etc.
Encore mieux si tu as un RUM maison (ou via un outil) : tu peux tagger la présence du tiers (chargé ou non, version, consentement obtenu ou non) et comparer des populations. Ça, c’est l’arme nucléaire contre les débats : tu ne discutes plus d’un score, tu montres une corrélation en prod, sur ton trafic, sur tes pages, avec tes vrais devices.
Le piège que je vois tout le temps : on “corrige” un truc en lab, puis on n’attend pas la fenêtre de collecte field (28 jours sur CrUX), et on conclut trop vite. Si tu as un RUM, tu peux mesurer dès le lendemain. Sinon, tu dois accepter que le field est plus lent à réagir. C’est frustrant, mais c’est la règle du jeu.
Arbitrer sans se mentir : budget tiers, self-host, delay… ou suppression
Une fois que tu as attribué, tu peux décider. Et là, mon avis est assez tranché : si un tiers te coûte cher sur une page business, ce n’est pas « un sujet technique », c’est un choix produit.
Parfois la suppression est évidente. Un widget “testé vite fait” il y a deux ans, jamais challengé, qui prend 200 ms de main thread et te colle du CLS, ça dégage. Parfois tu ne peux pas supprimer, mais tu peux décaler : charger après interaction, après LCP, ou derrière un consentement réel. Parfois tu peux self-host certains assets (quand c’est autorisé) ou au minimum limiter les dépendances, réduire les appels, couper des features. Et parfois tu assumes : la pub rapporte tant, on accepte un coût perf, mais on le documente et on le borne.
Ce qui marche bien, c’est de formaliser un budget tiers par type de page. Pas un truc théorique, un budget lié à tes SLO : « sur mobile, sur la page produit, on vise LCP p75 < 2,5 s et CLS p75 < 0,1 ; tout tiers qui met en risque ces seuils doit être justifié ». Ce cadre évite les discussions infinies et oblige chacun à parler en impact mesurable.
Éviter la guerre avec marketing/ads : un contrat de perf, pas une croisade
Le meilleur moyen de perdre, c’est d’arriver avec « vos tags cassent tout » et zéro données. L’autre meilleur moyen, c’est d’arriver avec des données et une attitude de flic. Le bon chemin, c’est de proposer un arbitrage lisible : “voilà ce que ça coûte, voilà ce que ça rapporte, voilà les options”.
Ce que j’ai vu fonctionner : un petit document partagé où chaque script tiers a un propriétaire, un objectif, une date de revue, et un niveau de criticité. Si quelqu’un veut ajouter un nouveau vendor, il sait qu’il devra prouver que ça rentre dans le budget, ou qu’on met une exception temporaire, avec une date de fin. Ça ressemble à de la gouvernance, oui. Mais c’est juste la version adulte de « on a 47 scripts et personne ne sait pourquoi ».
Et surtout, ça évite l’hypocrisie. Les équipes acquisition ont des objectifs. Toi aussi. Si tu apportes un protocole reproductible et un espace pour décider, tu transformes une guerre de religion en choix mesuré.
La suite logique : automatiser la preuve, puis empêcher la régression
Une fois que tu as fait 2 ou 3 attributions propres, tu n’as plus envie de revenir en arrière. La suite, c’est d’industrialiser un minimum : garder tes tests WebPageTest “référence”, versionner les patterns de blocage, et surtout mettre un filet anti-régression. Pas besoin de promettre la lune. Juste empêcher qu’un nouveau tag se glisse un vendredi soir et te flingue ton LCP pendant trois semaines.
La perf, ce n’est pas une quête de pureté. C’est un système de contraintes. Et les scripts tiers sont exactement le genre de contrainte qui mérite une preuve, pas une intuition.
