Si vous avez optimisé votre code, mais que votre site se charge toujours trop lentement, cela est probablement dû à des scripts tiers.
Les scripts tiers offrent une variété de fonctionnalités utiles qui rendent le Web plus dynamique, interactif et interconnecté. Certains d'entre eux peuvent même être essentiels au fonctionnement de votre site Web ou à vos revenus. Toutefois, leur utilisation est risquée :
- Ils peuvent ralentir les performances de votre site.
- Ils peuvent entraîner des problèmes de confidentialité ou de sécurité.
- Ils peuvent être imprévisibles et leur comportement peut avoir des conséquences inattendues.
Idéalement, vous devez vous assurer que les scripts tiers n'ont pas d'impact sur le chemin de rendu critique de votre site. Dans ce guide, nous allons voir comment identifier et résoudre les problèmes liés au chargement de code JavaScript tiers, et comment minimiser les risques pour vos utilisateurs.
Que sont les scripts tiers ?
Le JavaScript tiers fait souvent référence à des scripts qui peuvent être intégrés à n'importe quel site directement à partir d'un fournisseur tiers. Voici quelques exemples :
Boutons de partage sur les réseaux sociaux (Facebook, X, LinkedIn, Mastodon)
Lecteurs vidéo intégrés (YouTube, Vimeo)
iFrames publicitaires
Scripts d'analyse et de métriques
Scripts de tests A/B pour les tests
Bibliothèques d'assistance, telles que les bibliothèques de mise en forme de date, d'animation ou fonctionnelles
<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/mo8thg5XGV0"
frameborder="0"
allow="autoplay; encrypted-media"
allowfullscreen
>
</iframe>
Malheureusement, l'intégration de scripts tiers signifie que nous dépendons souvent d'eux pour s'exécuter rapidement et ne pas ralentir nos pages. Les scripts tiers sont une cause courante de ralentissement des performances causé par des ressources indépendantes du contrôle du propriétaire du site, y compris les problèmes suivants :
Envoi d'un trop grand nombre de requêtes réseau à plusieurs serveurs. Plus un site doit envoyer de requêtes, plus il peut mettre de temps à se charger.
Envoi d'un trop grand nombre de fichiers JavaScript qui occupent le thread principal. Un excès de JavaScript peut bloquer la construction du DOM, ce qui retarde l'affichage de la page. L'analyse et l'exécution de scripts gourmands en ressources CPU peuvent retarder l'interaction de l'utilisateur et décharger la batterie.
L'envoi de fichiers image ou de vidéos volumineux et non optimisés peut consommer des données et coûter de l'argent aux utilisateurs.
Problèmes de sécurité pouvant agir comme un point de défaillance unique si votre page charge un script sans précaution.
Mise en cache HTTP insuffisante, ce qui oblige le navigateur à envoyer davantage de requêtes réseau pour récupérer les ressources.
Une compression insuffisante du serveur ralentit le chargement des ressources.
Bloquer l'affichage du contenu jusqu'à la fin du traitement. Cela peut également être le cas pour les scripts de test A/B asynchrones.
Utilisation d'anciennes API connues pour nuire à l'expérience utilisateur, telles que document.write().
Éléments DOM excessifs ou sélecteurs CSS coûteux.
L'inclusion de plusieurs intégrations tierces peut entraîner l'extraction de plusieurs frameworks et bibliothèques à plusieurs reprises, ce qui gaspille des ressources et aggrave les problèmes de performances existants.
Les scripts tiers utilisent souvent des techniques d'intégration qui peuvent bloquer window.onload si leurs serveurs répondent lentement, même si l'intégration utilise async ou defer.
Votre capacité à résoudre les problèmes liés aux scripts tiers peut dépendre de votre site et de votre capacité à configurer le chargement du code tiers. Heureusement, il existe un certain nombre de solutions et d'outils pour identifier et résoudre les problèmes liés aux ressources tierces.
Comment identifier un script tiers sur une page ?
Identifier les scripts tiers sur votre site et déterminer leur impact sur les performances est la première étape pour les optimiser. Nous vous recommandons d'utiliser des outils de test de vitesse Web sans frais, tels que les Outils pour les développeurs Chrome, PageSpeed Insights et WebPageTest, pour identifier les scripts coûteux. Ces outils affichent des informations de diagnostic détaillées qui peuvent vous indiquer le nombre de scripts tiers utilisés par votre site et ceux qui prennent le plus de temps à s'exécuter.
La vue en cascade de WebPageTest peut mettre en évidence l'impact d'une utilisation intensive de scripts tiers. L'image suivante, tirée de Tags Gone Wild, montre un exemple de diagramme des requêtes réseau requises pour charger le contenu principal d'un site, par opposition aux scripts de suivi et de marketing.
La répartition par domaine de WebPageTest peut également être utile pour visualiser la quantité de contenu provenant de sources tierces. Il les répartit par nombre total d'octets et par nombre de requêtes :
Comment mesurer l'impact d'un script tiers sur ma page ?
Lorsque vous voyez un script qui pose problème, découvrez ce qu'il fait et déterminez si votre site en a besoin pour fonctionner. Si nécessaire, effectuez un test A/B pour trouver un équilibre entre sa valeur perçue et son impact sur l'engagement utilisateur ou les métriques de performances clés.
Audit du temps de démarrage 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 vous aider à identifier les scripts tiers qui consomment beaucoup de ressources du processeur.
Audit des charges utiles réseau Lighthouse
L'audit des charges utiles réseau de Lighthouse identifie les requêtes réseau, y compris les requêtes réseau tierces, qui ralentissent le temps de chargement des pages et font dépenser aux utilisateurs plus de données mobiles que prévu.
Blocage des requêtes réseau dans les outils pour les développeurs Chrome
Les outils pour les développeurs Chrome vous permettent de voir comment votre page se comporte lorsqu'un script, une feuille de style ou une autre ressource spécifiés ne sont pas disponibles. Pour ce faire, utilisez le blocage des requêtes réseau, une fonctionnalité qui permet de mesurer l'impact de la suppression de ressources tierces individuelles de votre page.
Pour activer le blocage des requêtes, effectuez un clic droit sur une 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 alors dans le panneau des outils de développement, ce qui vous permet de gérer les requêtes qui ont été bloquées.
Panneau "Performances" des outils pour les développeurs Chrome
Le panneau "Performances" des outils pour les développeurs Chrome permet d'identifier les problèmes de performances Web de votre page.
- Cliquez sur Enregistrer.
- Chargez votre page. Les outils de développement affichent un diagramme en cascade représentant la façon dont votre site utilise son temps de chargement.
- Accédez à Bottom-up (Ascendant) en bas du panneau "Performance".
- Cliquez sur Grouper par produit et triez les scripts tiers de votre page par temps de chargement.
Pour en savoir plus sur l'utilisation des outils pour les développeurs Chrome afin d'analyser les performances de chargement des pages, consultez Premiers pas avec l'analyse des performances d'exécution.
Voici le workflow que nous vous recommandons pour mesurer l'impact des scripts tiers :
- Utilisez le panneau "Réseau" pour mesurer le temps de chargement de votre page.
- Pour émuler des conditions réelles, nous vous recommandons d'activer la limitation de bande passante réseau et la limitation du processeur. Il est peu probable que vos utilisateurs disposent des connexions réseau rapides et du matériel de bureau qui réduisent l'impact des scripts coûteux dans des conditions de laboratoire.
- Bloquez les URL ou les domaines responsables des scripts tiers qui, selon vous, posent problème (consultez le panneau "Performances" des outils pour les développeurs Chrome pour savoir comment identifier les scripts coûteux).
- Actualisez la page et mesurez à nouveau le temps de chargement.
- Pour obtenir des données plus précises, vous pouvez mesurer votre temps de chargement au moins trois fois. Cela explique pourquoi certains scripts tiers récupèrent des ressources différentes à chaque chargement de page. Pour vous aider, le panneau "Performances" des outils de développement accepte plusieurs enregistrements.
Mesurer l'impact des scripts tiers avec WebPageTest
WebPageTest permet de bloquer le chargement de requêtes individuelles pour mesurer leur impact dans Advanced Settings > Block (Paramètres avancés > Bloquer). Utilisez cette fonctionnalité pour spécifier une liste de domaines à bloquer, tels que les domaines publicitaires.
Nous vous recommandons de suivre le workflow ci-dessous pour utiliser cette fonctionnalité :
- Testez une page sans bloquer les tiers.
- Répétez le test en bloquant certains tiers.
- Sélectionnez les deux résultats dans votre historique des tests.
- Cliquez sur Comparer.
L'image suivante montre la fonctionnalité de pellicule de WebPageTest, qui compare les séquences de chargement des pages avec et sans ressources tierces actives. Nous vous recommandons de vérifier cela pour les tests d'origines tierces individuelles, afin de déterminer quels domaines ont le plus d'impact sur les performances de votre page.
WebPageTest accepte également deux commandes fonctionnant au niveau du DNS pour bloquer les domaines :
blockDomainsprend une liste de domaines à bloquer.- blockDomainsExcept prend une liste de domaines et bloque tout ce qui ne figure pas dans la liste.
WebPageTest dispose également d'un onglet "Point de défaillance unique" (SPOF) qui vous permet de simuler un délai avant expiration ou un échec complet du chargement d'une ressource. Contrairement au blocage de domaine, le SPOF expire lentement, ce qui peut être utile pour tester le comportement de vos pages lorsque les services tiers sont soumis à une charge importante ou temporairement indisponibles.
Détecter les iFrames coûteux à l'aide des tâches longues
Lorsque l'exécution des scripts dans des iFrames tiers prend beaucoup de temps, ils peuvent bloquer le thread principal et retarder d'autres tâches. Ces tâches longues peuvent ralentir le fonctionnement des gestionnaires d'événements ou entraîner la perte d'images, ce qui nuit à l'expérience utilisateur.
Pour détecter les tâches longues pour la surveillance des utilisateurs réels (RUM), utilisez l'API JavaScript PerformanceObserver pour observer les entrées longtask. Ces entrées contiennent une propriété d'attribution que vous pouvez utiliser pour déterminer quel contexte de frame a causé la tâche longue.
Le code suivant consigne les entrées longtask dans la console, y compris une entrée pour un iFrame "coûteux" :
<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 Métriques de performances axées sur l'utilisateur.
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
asyncoudeferpour éviter de bloquer l'analyse du document. - Si le serveur tiers est lent, pensez à héberger vous-même le script.
- Si le script n'apporte aucune valeur ajoutée claire à votre site, supprimez-le.
- Utilisez des indications de ressources telles que
<link rel=preconnect>ou<link rel=dns-prefetch>pour effectuer une résolution DNS pour les domaines hébergeant des scripts tiers.
Utilisez async ou defer.
L'exécution de JavaScript bloque l'analyseur. Lorsque le navigateur rencontre un script, il doit suspendre la construction du DOM, transmettre le script au moteur JavaScript et autoriser l'exécution du script avant de poursuivre la construction du DOM.
Les attributs async et defer modifient ce comportement comme suit :
asyncindique au navigateur de télécharger le script de manière asynchrone pendant qu'il continue d'analyser le document HTML. Une fois le téléchargement du script terminé, l'analyse est bloquée pendant l'exécution du script.deferindique au navigateur de télécharger le script de manière asynchrone pendant qu'il continue d'analyser le document HTML, puis d'attendre que l'analyse du document soit terminée pour exécuter le script.
Utilisez toujours async ou defer pour les scripts tiers, sauf si le script est nécessaire pour le chemin de rendu critique. Utilisez async s'il est important que le script s'exécute plus tôt dans le processus de chargement, par exemple pour certains scripts d'analyse. Utilisez defer pour les ressources moins critiques, telles que les vidéos qui s'affichent plus bas sur la page que ce que l'utilisateur verra initialement.
Si les performances sont votre principale préoccupation, nous vous recommandons d'attendre que le contenu critique de votre page soit chargé avant d'ajouter des scripts asynchrones. Nous vous déconseillons d'utiliser async pour les bibliothèques essentielles telles que jQuery.
Certains scripts doivent être chargés sans async ni defer, en particulier ceux qui sont essentiels à votre site. Il peut s'agir de bibliothèques d'UI ou de frameworks de réseau de diffusion de contenu (CDN) sans lesquels votre site ne peut pas fonctionner.
D'autres scripts ne fonctionnent tout simplement pas s'ils sont chargés de manière asynchrone. Consultez la documentation des scripts que vous utilisez et remplacez ceux qui ne peuvent pas être chargés de manière asynchrone par des alternatives qui le peuvent. Sachez que certains tiers recommandent d'exécuter leurs scripts de manière synchrone, même s'ils fonctionnent tout aussi bien de manière asynchrone.
N'oubliez pas que async ne résout pas tout. Si votre page inclut un grand nombre de scripts, tels que des scripts de suivi à des fins publicitaires, les charger de manière asynchrone ne les empêchera pas de ralentir le chargement de la page.
Utiliser les optimisations de ressources pour réduire le temps de configuration de la connexion
L'établissement de connexions à des origines tierces peut prendre beaucoup de temps, en particulier sur les réseaux lents, car les requêtes réseau comportent plusieurs composants complexes, y compris des résolutions DNS et des redirections. Vous pouvez utiliser des indications de ressources telles que pour effectuer des résolutions DNS pour les domaines hébergeant des scripts tiers au début du processus de chargement de la page, afin que le reste de la requête réseau puisse se poursuivre plus rapidement par la suite :
<link rel="dns-prefetch" href="http://example.com" />
Si le domaine tiers auquel vous vous connectez utilise HTTPS, vous pouvez également utiliser , qui effectue des résolutions DNS et résout les allers-retours TCP et gère les négociations TLS. Ces autres étapes peuvent être très lentes, car elles impliquent la vérification des certificats SSL. La préconnexion peut donc réduire considérablement le temps de chargement.
<link rel="preconnect" href="https://cdn.example.com" />
"Sandboxer" les scripts avec un iFrame
Si vous chargez un script tiers directement dans un iframe, il ne bloque pas l'exécution de la page principale. AMP utilise cette approche pour exclure JavaScript du chemin critique. Notez que cette approche bloque toujours l'événement onload. Essayez donc de ne pas associer de fonctionnalités critiques à onload.
Chrome est également compatible avec la règle d'autorisation (anciennement "règle de fonctionnalité"), un ensemble de règles qui permettent à un développeur de désactiver de manière sélective l'accès à certaines fonctionnalités du navigateur. Vous pouvez l'utiliser pour empêcher les contenus tiers d'introduire des comportements indésirables sur un site.
Auto-héberger des scripts tiers
Si vous souhaitez mieux contrôler le chargement d'un script critique, par exemple pour réduire le temps DNS ou améliorer les en-têtes de mise en cache HTTP, vous pouvez l'héberger vous-même.
Toutefois, l'auto-hébergement présente ses propres problèmes, en particulier lorsqu'il s'agit de mettre à jour des scripts. Les scripts auto-hébergés ne reçoivent pas de mises à jour automatiques pour les modifications d'API ou les correctifs de sécurité, ce qui peut entraîner des pertes de revenus ou des problèmes de sécurité jusqu'à ce que vous puissiez mettre à jour votre script manuellement.
Vous pouvez également mettre en cache les scripts tiers à l'aide de service workers pour mieux contrôler la fréquence à laquelle les scripts sont récupérés sur le réseau. Vous pouvez également utiliser des service workers pour créer des stratégies de chargement qui limitent les requêtes tierces non essentielles jusqu'à ce que votre page atteigne un moment clé pour l'utilisateur.
Effectuer des tests A/B sur des échantillons d'utilisateurs plus petits
Les tests A/B (ou tests fractionnés) sont une technique permettant de tester deux versions d'une page afin d'analyser l'expérience et le comportement des utilisateurs. Il met les versions de la page à la disposition de différents échantillons du trafic de votre site Web et détermine, à partir des données analytiques, quelle version offre un meilleur taux de conversion.
Toutefois, par défaut, les tests A/B retardent l'affichage pour décider quel test doit être actif. JavaScript est souvent utilisé pour vérifier si l'un de vos utilisateurs fait partie d'un test A/B, puis pour activer la variante appropriée. Ce processus peut dégrader l'expérience, même pour les utilisateurs qui ne font pas partie du test.
Pour accélérer l'affichage des pages, nous vous recommandons d'envoyer vos scripts de test A/B à un échantillon plus restreint de votre base d'utilisateurs et d'exécuter le code qui détermine la version de la page à afficher côté serveur.
Chargement différé des ressources tierces
Les ressources tierces intégrées, telles que les annonces et les vidéos, peuvent être des facteurs majeurs de ralentissement de la vitesse des pages lorsqu'elles sont mal conçues. Le chargement différé peut être utilisé pour ne charger les ressources intégrées que lorsque cela est nécessaire. Par exemple, vous pouvez attendre que l'utilisateur fasse défiler la page suffisamment pour voir les annonces dans le pied de page avant de les diffuser. Vous pouvez également charger de manière différée le contenu tiers après le chargement du contenu de la page principale, mais avant qu'un utilisateur n'interagisse avec la page.
Soyez prudent lorsque vous chargez des ressources de manière différée, car cela implique souvent du code JavaScript qui peut être affecté par des connexions réseau instables.
DoubleClick fournit des conseils sur le chargement différé des annonces dans sa documentation officielle.
Chargement différé efficace avec Intersection Observer
Par le passé, les méthodes permettant de détecter si un élément est visible dans la fenêtre d'affichage à des fins de chargement différé étaient sujettes aux erreurs et ralentissaient souvent le navigateur. Ces méthodes inefficaces écoutent souvent les événements scroll ou resize, puis utilisent des API DOM telles que getBoundingClientRect() pour calculer la position des éléments par rapport à la fenêtre d'affichage.
IntersectionObserver est une API de navigateur qui permet aux propriétaires de pages de détecter efficacement quand un élément observé entre dans la fenêtre d'affichage du navigateur ou en sort. LazySizes est également compatible (en option) avec IntersectionObserver.
Chargement différé des analyses
Si vous différez trop longtemps le chargement de vos scripts d'analyse, vous risquez de passer à côté de données analytiques précieuses. Heureusement, il existe des stratégies pour initialiser l'analyse de manière différée tout en conservant les données de chargement de page initiales.
L'article de blog de Phil Walton The Google Analytics Setup I Use on Every Site I Build (La configuration Google Analytics que j'utilise sur chaque site que je crée) décrit une telle stratégie pour Google Analytics.
Charger des scripts tiers de manière sécurisée
Cette section explique comment charger des scripts tiers de la manière la plus sécurisée possible.
Éviter la requête document.write()
Les scripts tiers, en particulier pour les services plus anciens, utilisent parfois document.write() pour injecter et charger des scripts. Cela pose problème, car document.write() se comporte de manière incohérente et ses échecs sont difficiles à déboguer.
Pour résoudre les problèmes liés à document.write(), il suffit de ne pas l'utiliser. Dans Chrome 53 et versions ultérieures, les outils pour les développeurs Chrome consignent des avertissements dans la console en cas d'utilisation problématique de document.write() :
document.write().Si vous recevez cette erreur, vous pouvez vérifier si votre site utilise document.write() en recherchant les en-têtes HTTP envoyés à votre navigateur.
Lighthouse peut également mettre en évidence les scripts tiers qui utilisent encore document.write().
document.write().Utiliser les gestionnaires de balises avec précaution
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 (comme des widgets de réseaux sociaux) sur un site. Ces balises ajoutent des requêtes réseau, des dépendances JavaScript et d'autres ressources à votre page, ce qui peut avoir un impact sur ses performances. Plus vous ajoutez de balises, plus il est difficile de minimiser cet impact pour vos utilisateurs.
Pour que les chargements de page soient rapides, nous vous recommandons d'utiliser un gestionnaire de balises tel que Google Tag Manager (GTM). GTM vous permet de déployer des balises de manière asynchrone afin qu'elles ne se bloquent pas mutuellement lors du chargement, réduit le nombre d'appels réseau qu'un navigateur doit effectuer pour exécuter les balises et collecte les données des balises dans son UI de couche de données.
Risques liés à l'utilisation de gestionnaires de balises
Bien que les gestionnaires de balises soient conçus pour simplifier le chargement des pages, une utilisation imprudente peut au contraire le ralentir de différentes manières :
- Un nombre excessif de balises et d'écouteurs d'événements automatiques dans votre Tag Manager entraîne l'envoi par le navigateur d'un nombre de requêtes réseau supérieur à ce qui serait nécessaire, et réduit la capacité de votre code à répondre rapidement aux événements.
- Toute personne disposant d'identifiants et d'un accès peut ajouter du code JavaScript à votre gestionnaire de balises. Non seulement cela peut augmenter le nombre de requêtes réseau coûteuses nécessaires au chargement de votre page, mais cela peut également présenter des risques de sécurité et d'autres problèmes de performances liés à des scripts inutiles. Pour réduire ces risques, nous vous recommandons de limiter l'accès à votre gestionnaire de balises.
Éviter les scripts qui polluent le champ d'application global
Les scripts tiers peuvent se comporter de toutes sortes de manières qui endommagent votre page de manière inattendue :
- Les scripts qui chargent des dépendances JavaScript peuvent polluer le champ d'application global avec du code qui interagit mal avec votre code.
- Les mises à jour inattendues peuvent entraîner des modifications destructives.
- Le code tiers peut être modifié en transit pour se comporter différemment entre le test et le déploiement de votre page.
Nous vous recommandons d'effectuer régulièrement des audits des scripts tiers que vous chargez pour détecter les acteurs malveillants. Vous pouvez également mettre en œuvre des tests automatiques, l'intégrité des sous-ressources et la transmission sécurisée du code tiers pour assurer la sécurité de votre page.
Stratégies d'atténuation
Voici quelques stratégies à grande échelle pour minimiser l'impact des scripts tiers sur les performances et la sécurité de votre site :
HTTPS : les sites qui utilisent HTTPS ne doivent pas dépendre de tiers qui utilisent HTTP. Pour en savoir plus, consultez Contenu mixte.
Sandboxing : envisagez d'exécuter des scripts tiers dans des iFrames avec l'attribut
sandboxpour limiter les actions disponibles pour les scripts.Content Security Policy (CSP) : vous pouvez utiliser des en-têtes HTTP dans la réponse de votre serveur pour définir des comportements de script de confiance pour votre site, et détecter et atténuer les effets de certaines attaques, telles que le script intersites (XSS).
Voici un exemple d'utilisation de la directive script-src de la CSP pour spécifier les sources JavaScript autorisées d'une page :
// 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>
Documentation complémentaire
Pour en savoir plus sur l'optimisation du code JavaScript tiers, nous vous recommandons de lire les articles suivants :
- Performances et résilience : tests de résistance des tiers
- Ajouter de l'interactivité avec JavaScript
- Dangers potentiels des scripts tiers
- How 3rd Party Scripts can be performant citizens on the web
- Why Fast Matters - CSS Wizardry
- The JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party Libraries
- 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 commentaires.