![\"Comment](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/\/load-testing-third-party-scripts-1024x682.webp\")
<\/p>\n<\/p>\n
Les scripts tiers sont devenus, en silence, l’une des plus grandes sources de bruit, de distorsion et de faux \u00e9checs dans les tests de charge. Chaque outil marketing, pixel d’analyse, framework d’optimisation et widget ajoute une d\u00e9pendance distante que votre application ne contr\u00f4le pas. Sous un trafic r\u00e9el, la plupart d’entre eux se comportent \u00ab assez bien \u00bb. Sous une charge synth\u00e9tique, ils se comportent comme des mines, signalant souvent leurs \u00e9checs comme \u00e9tant les v\u00f4tres<\/em>.<\/p>\n Cet article r\u00e9duit le probl\u00e8me \u00e0 ce qui se passe r\u00e9ellement dans le navigateur, pourquoi le trafic synth\u00e9tique exag\u00e8re ces effets, et comment tester la charge intelligemment \u2014 sans laisser le code tiers d\u00e9tourner vos r\u00e9sultats. Il est \u00e9crit pour des \u00e9quipes utilisant LoadView, mais les principes s’appliquent partout o\u00f9 vous r\u00e9alisez des tests de performance bas\u00e9s sur le navigateur.<\/p>\n Les pages modernes ne sont pas seulement du HTML et votre propre JavaScript. Elles sont un assemblage de :<\/p>\n Chacun de ces scripts s’ex\u00e9cute selon sa propre chronologie, effectue ses propres appels r\u00e9seau et peut bloquer la page d’une mani\u00e8re que votre \u00e9quipe backend ne voit jamais.<\/p>\n Dans un test de charge, vous ne testez pas seulement votre syst\u00e8me \u2014 vous testez la disponibilit\u00e9 globale de 15 \u00e0 30 services que vous ne poss\u00e9dez pas et ne pouvez pas contr\u00f4ler. Certains sont rapides. D’autres sont lents. Certains paniquent lorsque vous g\u00e9n\u00e9rez des milliers de \u00ab visites \u00bb presque identiques par minute.<\/p>\n C’est pourquoi les \u00e9quipes observent souvent ce sch\u00e9ma :<\/p>\n Pour comprendre pourquoi les r\u00e9sultats des tests sont pollu\u00e9s, regardez ce que le navigateur doit faire :<\/p>\n Rien de tout cela n’est hypoth\u00e9tique. Ouvrez le waterfall des devtools et vous le verrez : des gestionnaires de balises engendrant une douzaine de scripts suppl\u00e9mentaires, des trackers r\u00e9cup\u00e9rant des configurations, des outils de relecture chargeant des ressources d’enregistrement, des analytics appelant des endpoints de batching.<\/p>\n Sous charge, ces cha\u00eenes externes ne deviennent pas plus rapides. Elles ralentissent. Parfois beaucoup.<\/p>\n Le plus important : le navigateur ne sait pas et ne se soucie pas que c’est un test de charge. Il ex\u00e9cute tout exactement comme il le ferait pour un utilisateur r\u00e9el. Si le fournisseur tiers ralentit, le navigateur ralentit.<\/p>\n Les tests synth\u00e9tiques en navigateur mesurent ce que les utilisateurs ressentent : LCP, DOMContentLoaded, \u00e9v\u00e9nement load, TTI et autres jalons d’ex\u00e9cution. Les scripts tiers d\u00e9forment tous ces indicateurs de mani\u00e8res telles que :<\/p>\n Si une balise script n’est ni async ni defer, le navigateur suspend le parsing du HTML jusqu’\u00e0 ce que le fournisseur distant r\u00e9ponde. Si ce fournisseur est lent \u2014 ou qu’il limite votre trafic \u2014 vos temps de test explosent.<\/p>\n La performance des tiers est intrins\u00e8quement erratique. Certaines requ\u00eates prennent 50 ms. D’autres 800 ms. Lorsque vous ex\u00e9cutez un test de charge complet, ces valeurs aberrantes s’accumulent dans vos percentiles 95 et 99, faisant para\u00eetre votre application instable alors qu’elle ne l’est pas.<\/p>\n M\u00eame s’il se charge de mani\u00e8re asynchrone, un analytics lourd ou des scripts de relecture exercent une pression sur l’ex\u00e9cution JS. Sous charge, cela s’amplifie.<\/p>\n Quand chaque script tiers g\u00e9n\u00e8re cinq requ\u00eates suppl\u00e9mentaires, identifier ce qui est \u00e0 vous et ce qui est externe devient douloureux. Beaucoup d’\u00e9quipes passent des heures \u00e0 courir apr\u00e8s un \u00ab probl\u00e8me de latence backend \u00bb qui est en r\u00e9alit\u00e9 un gestionnaire de balises bloqu\u00e9.<\/p>\n En fin de compte : votre syst\u00e8me peut \u00eatre sain, mais votre test de charge n’en donnera pas l’apparence.<\/p><\/blockquote>\n Les scripts tiers ne s’ex\u00e9cutent pas depuis votre infrastructure ; ils s’ex\u00e9cutent depuis des CDN r\u00e9pandus dans le monde. Ces CDN routent le trafic en fonction de la g\u00e9ographie, du congestionnement, des accords de peering, des maintenances en cours et de la logique dynamique de r\u00e9partition qu’ils appliquent \u00e0 ce moment-l\u00e0. Sous charge synth\u00e9tique, o\u00f9 vous lancez des requ\u00eates depuis plusieurs r\u00e9gions simultan\u00e9ment, cette variabilit\u00e9 est amplifi\u00e9e.<\/p>\n Des centaines de navigateurs frappant le m\u00eame script externe \u00e0 la fois peuvent \u00eatre rout\u00e9s vers des POP compl\u00e8tement diff\u00e9rents. Une r\u00e9gion peut tomber sur un n\u0153ud edge chaud et r\u00e9actif et renvoyer le fichier instantan\u00e9ment. Une autre r\u00e9gion peut atteindre un POP congestionn\u00e9 ou \u00ab froid \u00bb et \u00eatre bloqu\u00e9e pendant quelques centaines de millisecondes. Une troisi\u00e8me r\u00e9gion peut se d\u00e9grader temporairement ou \u00eatre rerout\u00e9e, ajoutant encore plus d’impr\u00e9visibilit\u00e9. Rien de tout cela ne refl\u00e8te la sant\u00e9 de votre application, mais tout cela appara\u00eet dans les r\u00e9sultats du test comme si c’\u00e9tait le cas.<\/p>\n La cons\u00e9quence est pr\u00e9visible : une zone de charge qui semble lente dans votre rapport ne lutte pas r\u00e9ellement contre vos serveurs \u2014 elle se d\u00e9bat avec un pixel marketing, une balise analytics ou un script de relecture h\u00e9berg\u00e9 sur un CDN dont le POP le plus proche traverse une mauvaise p\u00e9riode. Pendant ce temps, vos m\u00e9triques d’infrastructure racontent une autre histoire : CPU stable, m\u00e9moire stable, latence de base de donn\u00e9es inchang\u00e9e. Tout de votre c\u00f4t\u00e9 semble propre.<\/p>\n Mais votre waterfall est rempli de longues barres externes, d’ex\u00e9cutions de scripts retard\u00e9es et de jalons temporels gonfl\u00e9s. Ce d\u00e9calage est la signature caract\u00e9ristique du code tiers sous pression synth\u00e9tique.<\/p>\n Un des sch\u00e9mas d’\u00e9chec les plus trompeurs dans les tests de charge bas\u00e9s navigateur provient des services tiers qui se prot\u00e8gent, et non d’une d\u00e9faillance. Les plateformes analytics, gestionnaires de balises, outils de relecture et pixels marketing sont con\u00e7us pour g\u00e9rer un trafic utilisateur normal et organique \u2014 \u00e9tal\u00e9, irr\u00e9gulier et divers. Ce pour quoi ils ne sont pas<\/em> con\u00e7us, c’est des milliers de sessions synth\u00e9tiques presque identiques frappant exactement les m\u00eames endpoints dans une rafale serr\u00e9e et uniforme. Pour leurs syst\u00e8mes de d\u00e9tection, ce n’est pas un \u00ab test \u00bb. C’est une attaque.<\/p>\n Voici ce qui se passe :<\/p>\n Le r\u00e9sultat donne l’impression que votre application s’est effondr\u00e9e, alors qu’en r\u00e9alit\u00e9 rien dans votre infrastructure n’a chang\u00e9. Le CPU reste plat, la m\u00e9moire stable, la latence base de donn\u00e9es ne bouge pas. La lenteur n’est pas de votre c\u00f4t\u00e9 \u2014 c’est un service tiers qui limite le d\u00e9bit, estimant que le trafic est abusif. \u00c0 moins d’inspecter des fichiers HAR ou de tracer soigneusement les waterfalls externes, il est facile de mal diagnostiquer cela comme un probl\u00e8me interne. La correction n’est pas d’ajuster vos serveurs \u2014 c’est de reconna\u00eetre qu’une d\u00e9pendance externe se prot\u00e8ge contre votre trafic de test.<\/p>\n Un des plus grands \u00e9carts entre r\u00e9sultats synth\u00e9tiques et performance r\u00e9elle provient du simple fait que les utilisateurs r\u00e9els ne chargent pas tout ce que charge votre environnement de test. Une portion significative de votre audience utilise des bloqueurs de publicit\u00e9s ou des extensions de confidentialit\u00e9 qui emp\u00eachent l’ex\u00e9cution des analytics, pixels de suivi et scripts marketing. M\u00eame sans extensions, de nombreux sites exigent le consentement de l’utilisateur avant de charger ces scripts, ce qui les retarde ou les supprime compl\u00e8tement.<\/p>\n Les utilisateurs synth\u00e9tiques, par contraste, chargent toutes les d\u00e9pendances parce qu’ils se comportent comme des navigateurs propres, sans blocages, sans extensions et sans gate de consentement. Cela signifie que chaque script tiers \u2014 tags de suivi, outils de relecture, frameworks d’optimisation et plus \u2014 s’ex\u00e9cute \u00e0 chaque session synth\u00e9tique, alors qu’une grande partie des utilisateurs r\u00e9els ne les d\u00e9clenchent jamais.<\/p>\n Le r\u00e9sultat est un d\u00e9calage pr\u00e9visible : la production semble stable, tandis que le test de charge montre des temps gonfl\u00e9s et des waterfalls lourds. Le test n’a pas tort \u2014 il mesure un sc\u00e9nario o\u00f9 le poids total des scripts tiers est appliqu\u00e9 uniform\u00e9ment. Mais il ne refl\u00e8te pas non plus la distribution r\u00e9elle du comportement des utilisateurs, d’o\u00f9 ces \u00e9carts fr\u00e9quents.<\/p>\n Il n’existe pas d’approche unique. Cela d\u00e9pend de ce que vous mesurez.<\/p>\n Incluez les scripts tiers si vous vous souciez de :<\/strong><\/p>\n Excluez ou bloquez-les si vous vous souciez de :<\/strong><\/p>\n L’approche intelligente \u2014 ce que font la plupart des \u00e9quipes matures \u2014 est d’ex\u00e9cuter les deux :<\/p>\n L’\u00e9cart entre les deux vous indique exactement quel poids les fournisseurs tiers imposent \u00e0 votre exp\u00e9rience r\u00e9elle.<\/p>\n LoadView facilite cela : utilisez les fonctionnalit\u00e9s de blocklist\/allowlist pour ex\u00e9cuter les deux sc\u00e9narios sans r\u00e9\u00e9crire les scripts.<\/p><\/blockquote>\n Une id\u00e9e re\u00e7ue fr\u00e9quente dans les tests de charge est de supposer que les scripts tiers n’interagissent qu’avec des fournisseurs externes et n’ont donc aucun impact sur votre infrastructure. En pratique, c’est rarement vrai. De nombreux scripts r\u00e9cup\u00e8rent des donn\u00e9es, envoient des \u00e9v\u00e9nements ou demandent des configurations directement \u00e0 votre backend, cr\u00e9ant un trafic additionnel que les \u00e9quipes n\u00e9gligent souvent.<\/p>\n Exemples :<\/p>\n Le r\u00e9sultat est un effet d’amplification silencieux : un seul script tiers peut g\u00e9n\u00e9rer plusieurs appels backend suppl\u00e9mentaires par chargement de page. Sous charge, cela se multiplie de fa\u00e7on dramatique \u2014 ce qui semblait \u00eatre un test \u00ab uniquement frontend \u00bb produit soudainement un trafic backend significatif. Si vos m\u00e9triques d’infrastructure montrent des pics d’API inattendus ou une activit\u00e9 de base de donn\u00e9es \u00e9lev\u00e9e durant un sc\u00e9nario centr\u00e9 UI, ce sch\u00e9ma d’interaction en est souvent la cause.<\/p>\n Reconna\u00eetre ces points de contact backend cach\u00e9s est essentiel pour interpr\u00e9ter correctement les r\u00e9sultats du test de charge. Sans les prendre en compte, il est facile de bl\u00e2mer la mauvaise partie du syst\u00e8me ou de sous-estimer la demande r\u00e9elle que votre application subit dans un comportement de navigateur r\u00e9el.<\/p>\n Lorsque l’objectif est d’ex\u00e9cuter des tests de charge propres et fiables, l’objectif n’est pas de fabriquer une r\u00e9alit\u00e9 diff\u00e9rente \u2014 c’est d’isoler le syst\u00e8me sp\u00e9cifique que vous essayez de mesurer. Les d\u00e9pendances tierces introduisent du bruit, de l’impr\u00e9visibilit\u00e9 et des comportements de rate-limiting qui n’ont rien \u00e0 voir avec votre infrastructure. Contr\u00f4ler ces variables vous permet de mesurer votre propre performance sans h\u00e9riter de l’instabilit\u00e9 de services externes.<\/p>\n Une option consiste \u00e0 utiliser des overrides DNS, en routant des domaines tiers connus vers un endpoint mock local qui r\u00e9pond instantan\u00e9ment. Cela permet au navigateur de compl\u00e9ter la s\u00e9quence de requ\u00eates attendue sans attendre les CDNs distants ou les fournisseurs d’analytics. Le blocage de scripts atteint le m\u00eame r\u00e9sultat avec moins de configuration : dans LoadView, vous pouvez simplement bloquer des domaines tels que googletagmanager.com, hotjar.com ou optimizely.com afin que le navigateur ne perde pas de temps \u00e0 les ex\u00e9cuter ou les r\u00e9cup\u00e9rer pendant le test.<\/p>\n Les endpoints mock offrent une autre couche de contr\u00f4le en renvoyant des payloads minimaux et pr\u00e9visibles. Cela maintient l’ex\u00e9cution des scripts coh\u00e9rente entre les runs et \u00e9limine la latence en queue longue qui polluerait autrement les m\u00e9triques temporelles. Dans certains cas, des \u00e9quipes choisissent d’h\u00e9berger des copies de secours de biblioth\u00e8ques externes localement afin de contr\u00f4ler \u00e0 la fois la disponibilit\u00e9 et les temps sans alt\u00e9rer la logique applicative.<\/p>\n Toutes ces m\u00e9thodes pr\u00e9servent le comportement r\u00e9aliste du navigateur tout en \u00e9liminant les retards et \u00e9checs al\u00e9atoires que les fournisseurs tiers introduisent sous charge. Le r\u00e9sultat est un test qui refl\u00e8te la performance de votre application \u2014 pas la sant\u00e9 ou le niveau de congestion du CDN de quelqu’un d’autre.<\/p>\n Le test de charge bas\u00e9 navigateur de LoadView fournit la visibilit\u00e9 n\u00e9cessaire pour s\u00e9parer \u00ab votre code est lent \u00bb de \u00ab le service d’un autre s’est \u00e9trangl\u00e9 \u00bb.<\/p>\n Avantages cl\u00e9s :<\/p>\n C’est ce que requiert le testing de charge moderne : un contr\u00f4le fin sur le bruit.<\/p>\n Quand un test d\u00e9g\u00e9n\u00e8re, voici un sch\u00e9ma de triage rapide qui emp\u00eache les \u00e9quipes de courir apr\u00e8s la mauvaise cause racine.<\/p>\n Si les m\u00e9triques serveur sont stables mais que les r\u00e9sultats navigateur sont catastrophiques :<\/strong><\/p>\n C’est presque toujours des scripts tiers ou une surcharge d’ex\u00e9cution c\u00f4t\u00e9 client.<\/p>\n Si les percentiles 95\/99 gonflent tandis que les moyennes restent propres :<\/strong><\/p>\n C’est le comportement classique de queue longue des tiers.<\/p>\n Si une seule zone g\u00e9ographique de charge est lente :<\/strong><\/p>\n Vous avez atteint un POP de CDN externe qui passe une mauvaise journ\u00e9e.<\/p>\n Si des \u00e9checs montrent des erreurs DNS ou TLS pour des domaines externes :<\/strong><\/p>\n Vous \u00eates en train d’\u00eatre rate-limited ou bloqu\u00e9.<\/p>\n Si le trafic backend est plus \u00e9lev\u00e9 que pr\u00e9vu pendant un test \u201cfrontend\u201d :<\/strong><\/p>\n Un script \u00ab uniquement client \u00bb appelle secr\u00e8tement vos API.<\/p>\n Interpr\u00e9ter correctement les r\u00e9sultats n’est pas seulement une comp\u00e9tence \u2014 c’est une exigence pour des tests valides.<\/p><\/blockquote>\n Les scripts tiers ne vont pas dispara\u00eetre. Chaque \u00e9quipe marketing, fournisseur d’analytics et produit de personnalisation ajoute une d\u00e9pendance suppl\u00e9mentaire \u00e0 la page. C’est ainsi que fonctionne le web moderne.<\/p>\n Mais les tests de charge ne doivent pas laisser le serveur lent de quelqu’un d’autre vous convaincre que votre infrastructure \u00e9choue.<\/p>\n Des tests r\u00e9alistes signifient :<\/p>\n LoadView donne aux \u00e9quipes la visibilit\u00e9 et le contr\u00f4le pour faire exactement cela \u2014 tester le syst\u00e8me que vous ex\u00e9cutez r\u00e9ellement, et non l’empilement de scripts externes qui y sont coll\u00e9s.<\/p>\n","protected":false},"excerpt":{"rendered":" Les tests de charge \u00e9chouent souvent \u00e0 cause de scripts tiers, et non de votre application ou site. D\u00e9couvrez comment le code externe influence les m\u00e9triques et comment r\u00e9aliser des tests de performance propres.<\/p>\n","protected":false},"author":22,"featured_media":94163,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[511],"tags":[],"class_list":["post-94172","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tests-de-performance"],"yoast_head":"\nLe poids cach\u00e9 du code tiers<\/h2>\n
\n
\n
Que se passe-t-il r\u00e9ellement lorsque des scripts tiers s’ex\u00e9cutent pendant un test de charge<\/h2>\n
\n
Comment les scripts tiers gonflent et induisent en erreur les r\u00e9sultats<\/h2>\n
Les scripts bloquants arr\u00eatent le parsing<\/h3>\n
La latence en queue longue alt\u00e8re les percentiles<\/h3>\n
Le code asynchrone consomme quand m\u00eame du CPU et du temps de event loop<\/h3>\n
L’\u00e9talement du waterfall masque le v\u00e9ritable goulot d’\u00e9tranglement<\/h3>\n
Variabilit\u00e9 des CDN et latence en cascade sous charge synth\u00e9tique<\/h2>\n
Les fournisseurs tiers d\u00e9testent les tests de charge (probl\u00e8mes de rate-limiting)<\/h2>\n
\n
Pourquoi les utilisateurs r\u00e9els ne voient pas les m\u00eames ralentissements (ad blockers et consentement)<\/h2>\n
Quand inclure les scripts tiers dans les tests de charge \u2014 et quand les bloquer<\/h2>\n
\n
\n
\n
Les scripts tiers ne sont pas uniquement front-end<\/h2>\n
\n
Des tests plus intelligents : stubs, mocks, overrides et comportement externe contr\u00f4l\u00e9<\/h2>\n
Comment LoadView g\u00e8re le bruit des scripts tiers dans les tests de charge<\/h2>\n
\n
Lire les r\u00e9sultats : ne poursuivez pas des fant\u00f4mes tiers<\/h2>\n
Conclusion<\/h2>\n
\n