Chargement du code JavaScript tiers...

Addy Osmani
Addy Osmani
Arthur Evans

Vous avez optimisé l'intégralité de votre code, mais votre site se charge encore trop lentement. Qui est le coupable ?

Souvent, les problèmes de performances qui ralentissent le chargement des pages sont dus à des scripts tiers : annonces, analyses, outils de suivi, boutons de réseaux sociaux, etc.

Les scripts tiers offrent un large éventail de fonctionnalités utiles, qui rendent le Web plus dynamique, interactif et interconnecté. Ces scripts peuvent être cruciaux pour la fonctionnalité de votre site Web ou votre source de revenus. Toutefois, les scripts tiers s'accompagnent également de nombreux risques qu'il faut prendre en compte pour minimiser leur impact tout en apportant de la valeur.

Pourquoi devez-vous faire attention aux scripts tiers ?

  • Elles peuvent poser des problèmes de performances.
  • Ils peuvent poser des problèmes de confidentialité.
  • Il peut s'agir d'un problème de sécurité.
  • Elles peuvent être imprévisibles et changer sans que vous le sachiez
  • Elles peuvent avoir des conséquences inattendues.

Idéalement, vous devez vous assurer que le script tiers n'a aucune incidence sur le chemin critique du rendu. Dans ce guide, nous vous expliquons comment identifier et résoudre les problèmes liés au chargement de JavaScript tiers.

Qu'entend-on par scripts tiers ?

Le code JavaScript tiers désigne souvent des scripts qui peuvent être intégrés à n'importe quel site directement à partir d'un fournisseur tiers. Ces scripts peuvent inclure des annonces, des analyses, des widgets et d'autres scripts qui rendent le Web plus dynamique et interactif.

Voici quelques exemples de scripts tiers:

  • Boutons de partage sur les réseaux sociaux (Twitter, Facebook, Google+)

  • Intégrations de lecteurs vidéo (YouTube, Vimeo)

  • Publicités iFrame

  • Scripts d'analyse et de métriques

  • Scripts de tests A/B pour les tests

  • Les bibliothèques d'aide (format de date, animations ou bibliothèques fonctionnelles, par exemple)

exemple d'intégration de vidéo YouTube

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

Par exemple, le script d'intégration du lecteur vidéo YouTube vous permet d'intégrer une vidéo à votre page.

Malheureusement, l'intégration de scripts tiers signifie que nous nous basons souvent sur leur rapidité pour éviter de ralentir le chargement de nos pages. Les scripts tiers sont la principale cause de ralentissement des performances et sont souvent causés par des ressources que vous ne contrôlez pas.

Voici quelques exemples:

  • Exécution d'un trop grand nombre de requêtes réseau vers plusieurs serveurs. Plus un site doit effectuer de requêtes, plus son chargement peut prendre du temps.

  • L'envoi d'trop de code JavaScript qui maintient le thread principal occupé. Une quantité trop importante de code JavaScript peut bloquer la construction DOM, ce qui retarde l'affichage des pages. L'analyse et l'exécution de scripts utilisant une utilisation intensive du processeur peuvent retarder les interactions utilisateur et décharger la batterie.

  • l'envoi de fichiers image ou de vidéos volumineux et non optimisés ; Cela peut consommer des données et coûter de l'argent aux utilisateurs.

  • Les scripts tiers chargés sans précaution peuvent constituer un point de défaillance unique (SPOF).

  • Mise en cache HTTP insuffisante, forçant souvent la récupération des ressources du réseau

  • Manque de compression de serveur suffisante des ressources

  • Blocage de l'affichage des contenus jusqu'à la fin de leur traitement Cela peut également être vrai pour les scripts de tests A/B asynchrones.

  • Utilisation d'anciennes API (document.write(), par exemple) connues pour nuire à l'expérience utilisateur

  • Nombre excessif d'éléments DOM ou de sélecteurs CSS coûteux

  • L'inclusion de plusieurs intégrations tierces peut entraîner l'extraction de plusieurs frameworks et bibliothèques. C'est une source de gaspillage qui aggrave les problèmes de performances.

  • Les scripts tiers utilisent souvent des techniques d'intégration pouvant bloquer window.onload si leurs serveurs répondent lentement, même si l'intégration utilise asynchrone ou différée.

Le contexte est important, et la solution aux tiers coûteux peut dépendre de votre site et de votre capacité à configurer la manière dont vous chargez du code tiers. Heureusement, il existe un certain nombre de solutions et d'outils pour détecter et résoudre les problèmes liés aux ressources tierces.

Comment identifiez-vous les scripts tiers sur une page ?

Si vous ne savez pas quels scripts tiers sont chargés par votre site et quel est leur impact sur les performances, il est impossible de savoir comment les optimiser. De nombreux outils sans frais de test de la vitesse sur le Web peuvent mettre en avant des outils tiers coûteux, comme les Outils pour les développeurs Chrome, PageSpeed Insights et WebPageTest. Ces outils affichent des informations de diagnostic détaillées. Elles vous indiquent le nombre de scripts tiers en cours de chargement sur votre site et ceux dont l'exécution prend le plus de temps.

La vue en cascade de WebPageTest peut mettre en évidence l'impact d'une utilisation intensive des scripts tiers. Vous trouverez ci-dessous un exemple de requêtes requises pour charger le contenu principal d'un site, par rapport aux scripts de suivi et de marketing (crédit: Tags Gone Wild).

vue en cascade d&#39;un test de page Web, montrant
un site Web réel par rapport au temps de chargement des scripts de suivi

La répartition des domaines de WebPageTest peut également être utile pour visualiser la quantité de contenu provenant d'origines tierces. Cette métrique est décomposée par nombre total d'octets et par nombre de requêtes:

la répartition du contenu par domaine (première vue).
Indique le pourcentage de requêtes et d&#39;octets pour chaque tiers

Lorsque vous voyez un script problématique, déterminez ce qu'il fait et demandez-vous s'il est vraiment nécessaire. Effectuez un test A/B pour équilibrer la valeur perçue par rapport à son impact sur les principales métriques d'engagement ou de performances des utilisateurs.

Comment mesurer l'impact des scripts tiers sur ma page ?

Audit du temps de démarrage de Lighthouse

L'audit du temps de démarrage JavaScript de Lighthouse met en évidence les scripts dont le temps d'analyse, de compilation ou d'évaluation est coûteux. Cela peut être utile pour détecter des scripts tiers qui utilisent de manière intensive le processeur.

Lighthouse permet d&#39;évaluer et d&#39;analyser les scripts

Audit des charges utiles du réseau Lighthouse

L'audit des charges utiles de réseau Lighthouse identifie les requêtes réseau (y compris celles provenant de tiers) susceptibles de ralentir le chargement des pages. Éviter ces requêtes ou mettre en évidence leur coût pour les réseaux publicitaires peut permettre aux utilisateurs d'économiser de l'argent qu'ils auraient dépensé pour les données mobiles.

Lighthouse montrant la compatibilité avec les charges utiles de réseau volumineuses

Outils pour les développeurs Chrome (blocage des requêtes réseau)

Les outils pour les développeurs Chrome vous permettent de savoir comment se comporte votre page lorsqu'un script, une feuille de style ou une autre ressource spécifique n'est pas disponible. Pour ce faire, utilisez le blocage des requêtes réseau, une fonctionnalité qui permet de mesurer l'impact du blocage (abandon) de ressources tierces spécifiques de votre page.

Pour activer le blocage des requêtes, effectuez un clic droit sur n'importe quelle requête dans le panneau "Réseau", puis sélectionnez "Bloquer l'URL de la requête". Un onglet de blocage des requêtes s'affiche dans le panneau "Outils de développement", ce qui vous permet de gérer les requêtes bloquées.

Bloquer les URL de requête depuis le panneau des outils de développement

Panneau "Performances des outils pour les développeurs Chrome"

Le panneau "Performance" des outils pour les développeurs Chrome permet d'identifier les problèmes liés aux performances de votre page sur le Web. Lorsque vous cliquez sur le bouton d'enregistrement et que vous chargez votre page, une cascade représentant les endroits où votre site passe du temps s'affiche. Au bas du panneau "Performances", vous verrez un panneau commençant par Summary (Résumé). Accédez à l'onglet "De bas en haut".

Ici, vous pouvez utiliser l'option "Grouper par produit" de l'onglet "Bottom-Up" pour regrouper des tiers en fonction du temps qu'ils ont passé. Cela permet d'identifier les produits tiers les plus coûteux. Le panneau "Network" (Réseau) propose également une option permettant de mettre en évidence les requêtes par produit.

Panneau &quot;Performances des outils de développement&quot; affichant la vue ascendante regroupée par produits (tiers)

Pour en savoir plus sur l'analyse des performances de chargement des pages avec les outils pour les développeurs Chrome, consultez Premiers pas avec l'analyse des performances d'exécution.

Voici un workflow adapté pour mesurer l'impact des scripts tiers:

  • Mesurez le temps de chargement de votre page à l'aide du panneau "Network".
    • Pour émuler des conditions réelles, nous vous recommandons d'activer la limitation du réseau et la limitation du processeur. Sur les connexions plus rapides et le matériel de bureau, l'impact de scripts coûteux peut ne pas être aussi représentatif que sur un téléphone mobile.
  • Bloquez les URL ou les domaines responsables des scripts tiers qui, selon vous, posent problème (consultez le panneau sur les performances des outils pour les développeurs Chrome pour savoir comment identifier les scripts coûteux).

  • Actualisez la page et mesurez à nouveau le temps qu'elle prend sans charger ces scripts tiers bloqués. Vous devriez constater une amélioration.

    • Il peut être intéressant d'effectuer trois exécutions de mesure ou plus et d'examiner la médiane pour obtenir des chiffres plus stables. Étant donné que le contenu tiers peut parfois intégrer différentes ressources par chargement de page, vous pouvez obtenir une répartition plus réaliste. DevTools accepte désormais plusieurs enregistrements dans le panneau des performances, ce qui facilite le processus.

Mesurer l'impact des balises tierces avec WebPageTest

WebPageTest permet de bloquer le chargement de requêtes individuelles (ce qui peut être utile pour bloquer du contenu tel que les annonces et les intégrations tierces) afin de mesurer leur impact.

Sous "Paramètres avancés", vous trouverez l'onglet "Bloquer". Cela permet de spécifier une liste de domaines à bloquer, ce qui simule le processus de chargement non effectué.

Paramètres avancés WebPageTest < Bloquer.
Affiche une zone de texte permettant de spécifier les domaines à bloquer.

Voici comment procéder pour utiliser cette fonctionnalité:

  • Tester une page normalement

  • Répéter le test avec certains tiers bloqués

  • Comparez les deux résultats (en faisant attention à la pellicule). Vous pouvez comparer les résultats en les sélectionnant dans l'historique des tests, puis en cliquant sur "Comparer".

WebPageTest affiche l&#39;option &quot;Comparer&quot;
pour comparer deux rapports

Vous pouvez voir ci-dessous la différence entre les filmstrip avec et sans ressources tierces bloquées. Il peut être utile de tester cette méthode pour des origines tierces individuelles afin d'identifier celles qui ont le plus d'impact sur les performances de chargement de vos pages:

Pellicule WebPageTest montrant l&#39;impact du chargement d&#39;un site avec et sans tiers désactivés

Impact du blocage de ressources tierces sur une page utilisant la fonctionnalité de blocage des requêtes de WPT grâce à l'article Using WebPageTest To Measure The Impact Of Third-Party Tags d'Andy Davies

  • qui accepte une liste de domaines à bloquer et blockDomainsExcept
  • prend une liste de domaines et bloque tout ce qui ne figure pas sur la liste.

WebPageTest comporte également un onglet SPOF (Single Point of faille, ou point de défaillance unique). Cela vous permet de simuler un délai avant expiration ou un échec total du chargement d'une ressource.

La différence entre "SPOF" et "Block" est qu'elle expire lentement. Cela peut s'avérer utile pour tester la résilience du réseau du contenu tiers afin de déterminer la capacité de vos pages à résister lorsque les services sont soumis à une charge importante ou temporairement indisponibles.

d&#39;échec des paramètres avancés WebPageTest > SPOF > hôtes.

Détecter les iFrame coûteux à l'aide de longues tâches

Lorsque les scripts dans des iFrames tiers prennent beaucoup de temps, ils peuvent bloquer le thread principal, ce qui retarde l'exécution d'autres tâches. Ces longues tâches peuvent nuire à l'expérience utilisateur et entraîner un ralentissement des gestionnaires d'événements ou une perte de frames.

Pour détecter les longues tâches liées à la surveillance des utilisateurs réels (RUM), nous pouvons utiliser l'API JavaScript PerformanceObserver et observer les entrées de type longtask. Comme ces entrées contiennent une propriété d'attribution, nous pouvons identifier le contexte de frame à l'origine de la tâche.

Vous trouverez ci-dessous un exemple qui consigne les entrées longtask dans la console, y compris une pour un iFrame "cher" :

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

Pour en savoir plus sur la surveillance des tâches longues, consultez les métriques de performances axées sur l'utilisateur de Phil Walton.

Comment charger efficacement un script tiers ?

Si un script tiers ralentit le chargement de votre page, plusieurs options s'offrent à vous pour améliorer les performances:

  • Chargez le script à l'aide de l'attribut "async" ou "defer" pour éviter de bloquer l'analyse du document.

  • Envisagez d'auto-héberger le script si le serveur tiers est lent.

  • Envisagez de supprimer le script s'il n'apporte pas de valeur ajoutée à votre site.

  • Envisagez d'utiliser des suggestions de ressources comme <link rel=preconnect> ou <link rel=dns-prefetch> pour effectuer une résolution DNS pour les domaines hébergeant des scripts tiers.

Utiliser "async" ou "defer"

L'exécution de JavaScript bloque l'analyseur. Cela signifie que lorsque le navigateur rencontre un script, il doit mettre en pause la construction DOM, le transmettre au moteur JavaScript et autoriser l'exécution du script avant de poursuivre la construction DOM.

Les attributs "async" et "defer" modifient ce comportement.

  • Avec asynchrone, le navigateur télécharge le script de manière asynchrone pendant qu'il continue à analyser le document HTML. Une fois le téléchargement du script terminé, l'analyse est bloquée pendant son exécution.

  • Avec "defer", le navigateur télécharge le script de manière asynchrone pendant qu'il continue à analyser le document HTML. Le script ne s'exécute qu'une fois l'analyse terminée.

Si cela fait trop de mots, en voici une jolie représentation:

Visualisation comparant l&#39;impact de l&#39;utilisation d&#39;un script, de l&#39;utilisation d&#39;un script asynchrone ou d&#39;un report de script. Defer s&#39;affiche comme étant en cours d&#39;exécution après la récupération du script et l&#39;analyse HTML.

Crédit: se développer avec le Web

En général, vous devez toujours utiliser async ou defer pour les scripts tiers (sauf si le script effectue une action nécessaire pour le chemin critique du rendu):

  • Utilisez async s'il est important que le script s'exécute plus tôt dans le processus de chargement. Cela peut inclure des scripts d'analyse, par exemple.

  • Utilisez defer pour les ressources moins critiques. Par exemple, dans un lecteur vidéo situé dans la partie en dessous de la ligne de flottaison.

Devez-vous charger des scripts tiers sans async ni defer ? Vous pouvez justifier cela si le script est un élément essentiel du fonctionnement de votre site. Par exemple, si vous chargez votre framework ou votre bibliothèque d'UI principale à partir d'un CDN, celui-ci portera le badge "script tiers" dans les outils de développement, mais il devra être considéré comme une partie essentielle de votre site, et non comme un module complémentaire.

Notez que les scripts ne fonctionnent pas tous s'ils sont chargés de manière asynchrone. Consultez la documentation pour voir si vous utilisez des scripts tiers. Si vous utilisez un script qui ne peut pas être chargé de manière asynchrone, vous pouvez envisager une autre option ou le supprimer si possible. Certains tiers peuvent fortement recommander de charger la synchronisation de leurs scripts (pour devancer les autres scripts), même si cela fonctionne de manière asynchrone. Il en va de même de la diligence raisonnable lors de l'évaluation des stratégies de chargement de scripts tiers.

Utiliser des suggestions de ressources pour réduire le temps de configuration de la connexion

Établir des connexions avec des origines tierces peut prendre beaucoup de temps, en particulier sur les réseaux lents. De nombreuses étapes peuvent s'ajouter aux retards, y compris les résolutions DNS, les redirections et potentiellement plusieurs allers-retours vers chaque serveur tiers pour gérer la requête.

Vous pouvez utiliser des suggestions de ressources comme pour effectuer une résolution DNS pour les domaines hébergeant des scripts tiers. Une fois la demande effectuée, le temps peut être économisé, car la résolution DNS a déjà été effectuée.

<link rel="dns-prefetch" href="http://example.com" />

Si le domaine tiers que vous référencez utilise HTTPS, vous pouvez également envisager d'utiliser , car il effectuera à la fois la résolution DNS et permettra de résoudre les allers-retours TCP et de gérer les négociations TLS. Ces autres étapes peuvent être très lentes, car elles impliquent l'examen des certificats SSL à des fins de vérification. Par conséquent, prenez très au sérieux les conseils de ressource si vous constatez que le délai de configuration d'un service tiers pose problème.

<link rel="preconnect" href="https://cdn.example.com" />

Scripts "bac à sable" avec un iFrame

Dans certains cas, des scripts tiers peuvent être chargés directement dans un iFrame. En limitant ces scripts aux iFrames, ils ne bloquent pas l'exécution de la page principale. C'est la même approche qu'AMP pour exclure JavaScript du chemin critique. Notez que cette approche bloquera toujours l'événement onload. Essayez donc de ne pas associer de fonctionnalité critique à onload.

Chrome est également compatible avec les Règles relatives aux autorisations (anciennement "Règles relatives aux fonctionnalités"), un ensemble de règles permettant aux développeurs de désactiver de manière sélective l'accès à certaines fonctionnalités du navigateur. Cela peut éviter que des contenus tiers introduisent des comportements indésirables sur un site.

Scripts tiers auto-hébergés

L'auto-hébergement de scripts tiers peut vous permettre de mieux contrôler l'histoire de chargement d'un script. Par exemple, si vous souhaitez réduire les délais DNS ou aller-retour, ou améliorer les en-têtes de mise en cache HTTP. L'auto-hébergement peut être une considération viable si un script est considéré comme critique.

L'auto-hébergement peut s'accompagner d'un certain nombre de mises en garde importantes:

  • Les scripts peuvent devenir obsolètes. Il peut s'agir d'un problème important, car il vous empêche d'obtenir des correctifs de sécurité importants sans effectuer de mise à jour manuelle.

  • Les scripts auto-hébergés ne recevront pas de mises à jour automatiques en raison d'une modification de l'API. Par exemple, un éditeur dont 90% des revenus proviennent des annonces découvre que les annonces n'ont pas été diffusées pendant une demi-journée en raison d'un changement d'API qui n'était pas pris en compte par son script auto-hébergé, ce qui a entraîné une perte de revenus.

Une alternative aux scripts d'auto-hébergement consisterait à utiliser des service workers pour les mettre en cache. Cela vous permet de mieux contrôler la fréquence à laquelle ils sont récupérés sur le réseau. Cela peut également être utilisé pour créer une stratégie de chargement dans laquelle les requêtes pour les tiers non essentiels sont limitées jusqu'à ce que la page atteigne un moment clé de l'utilisateur.

Effectuez des tests A/B sur de plus petits échantillons d'utilisateurs.

Les tests A/B (ou tests fractionnés) sont une technique permettant de tester deux versions d'une page afin d'identifier la plus performante. Pour ce faire, activez les deux variantes (A et B) pour différents échantillons de trafic sur votre site Web. La page offrant le meilleur taux de conversion l'emporte.

Les tests A/B sont un outil très utile pour analyser l'expérience et le comportement des utilisateurs.

Cependant, de par sa conception, les tests A/B retardent l'affichage pour déterminer quel test doit être actif. Le code JavaScript permet souvent de vérifier si certains de vos utilisateurs participent à un test A/B, puis d'activer la bonne variante. Avec ce modèle, 100% de vos utilisateurs peuvent être envoyés vers un script volumineux et coûteux, même s'ils ne font pas partie de l'échantillon recevant le test.

Dans ce cas, une bonne alternative consiste à n'envoyer des scripts de test A/B que pour un sous-ensemble de votre base d'utilisateurs (par exemple, 10% contre 100%), en essayant idéalement de décider s'ils font partie d'un échantillon de test côté serveur. Cela améliore l'expérience de chargement pour la majorité des utilisateurs tout en permettant les tests fractionnés.

Ressources tierces de chargement différé

Les ressources tierces intégrées (telles que les annonces ou les vidéos) peuvent contribuer grandement à la lenteur de la page lorsqu'elles sont mal conçues. Le chargement différé permet de ne charger des ressources intégrées que si nécessaire. Par exemple, diffuser une annonce dans le pied de page uniquement lorsqu'un utilisateur fait défiler la page vers le bas. Un autre modèle consiste à charger le contenu de manière différée après le chargement du contenu de la page principale, mais avant qu'un utilisateur ne puisse interagir avec la page.

Illustration montrant les éléments essentiels à l&#39;expérience au-dessus de la ligne de flottaison, et ceux qui sont moins importants et peuvent être chargés en différé.

Les navigateurs permettent de manière native le chargement différé des images et des iFrames. LazySizes est une bibliothèque JavaScript populaire qui permet d'effectuer les mêmes opérations avec davantage d'options.

La documentation officielle de DoubleClick fournit des conseils sur le chargement différé des annonces. S'il est utilisé correctement, le chargement différé peut augmenter le pourcentage de visibilité globale d'une annonce. Par exemple, Mediavine est passé aux annonces à chargement différé et a constaté une amélioration de 200% de la vitesse de chargement des pages.

Chargement différé efficace avec Intersection Observer

Par le passé, les solutions permettant de détecter si un élément est visible dans la fenêtre d'affichage (en vue de charger son contenu de manière différée) étaient sujettes aux erreurs, ce qui entraînait souvent une lenteur du navigateur. Les solutions ont souvent écouté les événements de défilement ou de resize, puis ont utilisé des API DOM telles que getBoundingClientRect() pour calculer la position des éléments par rapport à la fenêtre d'affichage. Cela fonctionne, mais n'est pas efficace.

IntersectionObserver est une API de navigateur qui nous permet de détecter efficacement les entrées et sorties de la fenêtre d'affichage du navigateur d'un élément observé. Découvrez comment l'utiliser pour les ressources à chargement différé. LazySizes offre également une compatibilité facultative avec IntersectionObserver.

Les analyses peuvent être compliquées

Les scripts Analytics ne devraient jamais ralentir le chargement des pages. Toutefois, si vous retardez le chargement trop longtemps, vous risquez de manquer des données d'analyse précieuses pour les pages que les utilisateurs quittent avant la fin du chargement. C'est pourquoi de nombreux fournisseurs de services d'analyse recommandent de charger leurs scripts en haut de la page. Les propriétaires de sites doivent décider si ce gain d'analyse en vaut la peine en termes de chargement.

Quelles tendances dois-je éviter avec les scripts tiers ?

Éviter la requête document.write()

Les scripts tiers utilisent parfois document.write() pour injecter et charger des scripts. Cela est particulièrement vrai pour les services plus anciens qui n'ont pas été mis à jour depuis un certain temps. Heureusement, de nombreux tiers proposent une option de chargement asynchrone qui permet aux scripts tiers de se charger sans bloquer l'affichage du reste du contenu sur la page.

La solution pour document.write() consiste tout simplement à ne pas injecter de scripts en l'utilisant. À partir de Chrome 53, les outils pour les développeurs Chrome enregistreront des avertissements dans la console en cas d'utilisation problématique de document.write():

Avertissements dans la console DevTools signalant les cas de non-respect des règles d&#39;intégration tierce à l&#39;aide de document.write()

Pour découvrir l'utilisation de document.write() à grande échelle, vous pouvez vérifier les en-têtes HTTP envoyés à votre navigateur lorsque cette intervention pour Chrome se produit. Lighthouse peut également mettre en évidence les scripts tiers qui utilisent encore document.write() dans le rapport Lighthouse:

Bonnes pratiques Lighthouse pour signaler l&#39;utilisation de document.write()

Utilisez Tag Manager à bon escient.

Une "balise" est un extrait de code qui permet aux équipes de marketing digital de collecter des données, de définir des cookies ou d'intégrer des contenus tiers, tels que des widgets de réseaux sociaux, à un site. Ces tags ont un coût pour les performances de chargement de votre page : requêtes réseau supplémentaires, dépendances JavaScript importantes, images et ressources que le tag lui-même peut importer.

La gestion de ces balises peut devenir un véritable casse-tête avec le temps, car les équipes marketing souhaitent ajouter d'autres moyens de comprendre les utilisateurs, et les ingénieurs s'efforcent de minimiser leur impact sur l'expérience utilisateur. Pour que les expériences restent rapides, nous vous recommandons d'utiliser Tag Manager. Gestionnaires de balises:

  • Ils permettent de gérer de nombreux éléments de code d'intégration tiers à partir d'un seul et même endroit (généralement via une interface utilisateur).

  • tenter de réduire le nombre de balises tierces à déployer sur les sites.

Google Tag Manager (GTM) est l'un de ces outils populaires:

"Google Tag Manager est une balise asynchrone. Son exécution n'empêche pas les autres éléments de s'afficher sur la page. Les autres balises déployées via Google Tag Manager sont également déployées de manière asynchrone. Cela signifie qu'une balise qui se charge lentement ne bloquera pas les autres balises de suivi."

Les gestionnaires de balises peuvent améliorer les performances de chargement des pages en réduisant le nombre d'appels à des ressources externes nécessaires, à condition que vous n'extrayiez pas un grand nombre de tags. Elles permettent également aux balises de collecter des valeurs en un seul endroit. Dans le cas de GTM, il s'agit de la couche de données. Si plusieurs tiers souhaitent déclencher des données de suivi des conversions, ils peuvent le faire en extrayant des données de la couche de données.

Risques liés à l'utilisation de Tag Manager

Lorsque vous utilisez un gestionnaire de balises, vous devez veiller à ne pas ralentir le chargement des pages. Voici pourquoi :

  • Toute personne disposant d'identifiants et d'un accès peut facilement ajouter non seulement plus de balises, mais aussi tout code JavaScript de son choix. Bien que les gestionnaires de balises puissent charger les tags de manière asynchrone, cela peut toujours entraîner un nombre excessif de requêtes HTTP coûteuses qui sont émises et exécutées. Vous pouvez réduire ce nombre en n'autorisant qu'un seul utilisateur à publier des versions.

  • Tout le monde peut configurer un trop grand nombre d'écouteurs d'événements automatiques Tag Manager. Chaque écouteur d'événements automatiques doit être exécuté. Plus il y a de requêtes de code et de réseau, plus le chargement complet d'une page peut prendre du temps. Conformément à nos conseils sur les performances, qui vous encouragent à répondre aux événements dans un délai de 50 ms, chaque écouteur d'événements Tag Manager a ajouté des données consommées à cet objectif.

Pour en savoir plus, consultez les bonnes pratiques concernant les balises et les gestionnaires de balises.

Éviter les scripts qui polluent le champ d'application global

Les scripts tiers injectés dans l'inconnu peuvent parfois charger un certain nombre de leurs propres dépendances JavaScript. Cela peut polluer le champ d'application global et causer une rupture accidentelle des pages.

Il n'y a aucune garantie que le code chargé à partir d'un tiers reste identique à ce que vous avez vu lors des tests. De nouvelles fonctionnalités peuvent être déployées par des tiers à tout moment, ce qui peut endommager votre page. Les tests automatiques, l'intégrité des sous-ressources et la transmission sécurisée du code tiers (pour réduire le risque de modifications en transit) peuvent être utiles dans ce cas de figure.

Effectuez des audits minutieux des scripts tiers que vous chargez pour vous assurer qu'ils fonctionnent correctement.

Stratégies d'atténuation

L'ajout de scripts tiers à une page implique un niveau de confiance envers l'origine. Vous pouvez adopter certaines stratégies pour minimiser leur impact sur les performances et la sécurité:

  • Le protocole HTTPS est indispensable. Les sites fonctionnant sur HTTPS ne doivent pas faire appel à des tiers qui utilisent le protocole HTTP. Une page HTTPS incluant du contenu récupéré à l'aide du protocole HTTP est appelée "page de contenu mixte" et risque de recevoir des avertissements de type Contenu mixte.

  • Tenez compte de l'attribut sandbox sur les cadres iFrame. Du point de vue de la sécurité, cela vous permet de limiter les actions disponibles depuis l'iFrame. Les restrictions incluent le allow-scriptscontrôle si le contexte peut exécuter des scripts.

  • Envisagez d'utiliser Content Security Policy (CSP). Grâce à un en-tête HTTP dans la réponse de votre serveur, vous pouvez définir des comportements approuvés sur la page. CSP peut être utilisé pour détecter et atténuer les effets de certaines attaques, telles que les scripts intersites (XSS).

CSP est particulièrement puissant, car il inclut des directives telles que script-src, qui spécifient les sources valides et autorisées pour JavaScript. Vous trouverez ci-dessous un exemple d'utilisation pratique:

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

Conclusion

Étant donné que les sites s'appuient plus que jamais sur des scripts tiers, il est primordial de ne pas ignorer leurs performances. Voici ce que vous pouvez faire:

  • Familiarisez-vous avec certaines des méthodes d'optimisation de scripts tierces les plus efficaces, telles que le chargement des balises qui acceptent le modèle de chargement asynchrone.

  • Découvrez comment identifier et résoudre les problèmes de chargement de scripts tiers. Cela peut vous aider à reprendre le contrôle des performances de chargement de vos pages.

L'optimisation des scripts tiers doit être suivie d'une surveillance continue des performances de vos scripts en temps réel et d'une communication avec vos fournisseurs tiers. Le Web évolue à un rythme rapide, et les performances d'un script, observées localement, ne garantissent en rien qu'il sera performant à l'avenir ou en dehors.

Documentation complémentaire

Performances et résilience: organisations tierces qui font des tests de stress

Ajouter de l'interactivité avec JavaScript

Dangers potentiels liés aux scripts tiers

Comment les scripts tiers peuvent-ils être des citoyens performants sur le Web ?

L'importance de la rapidité : l'ingéniosité du CSS

Paradoxe de la chaîne d'approvisionnement JavaScript: SRI, CSP et confiance dans les bibliothèques tierces

Le CSS tiers n'est pas sécurisé

Nous remercions Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick et Cheney Tsai pour leurs avis.