Si vous avez optimisé votre code, mais que votre site se charge encore trop lentement, les scripts tiers sont probablement à l'origine de cette.
Les scripts tiers offrent diverses fonctionnalités utiles qui rendent le Web plus dynamique, interactif et interconnecté. Certaines d'entre elles peuvent même être cruciales pour la fonction ou la source de revenus de votre site Web. Toutefois, leur utilisation présente des risques:
- Elles peuvent ralentir les performances de votre site.
- Ils peuvent causer des problèmes de confidentialité ou de sécurité.
- Elles peuvent être imprévisibles et leur comportement peut avoir des conséquences inattendues.
Idéalement, vous devez vous assurer que les scripts tiers n'affectent pas le chemin critique du rendu de votre site. Dans ce guide, nous vous expliquons comment identifier et résoudre les problèmes liés au chargement de JavaScript tiers, et comment minimiser les risques pour vos utilisateurs.
Que sont les 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. Voici quelques exemples :
Boutons de partage sur les réseaux sociaux (Facebook, X, LinkedIn, Mastodon)
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, telles que la mise en forme des dates, les animations ou les bibliothèques 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 nous appuyons souvent sur eux pour s'exécuter rapidement et ne pas ralentir nos pages. Les scripts tiers sont souvent à l'origine de ralentissements des performances causés par des ressources que le propriétaire du site ne contrôle pas, y compris les problèmes suivants:
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 de la page. 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 vidéos ou de fichiers image volumineux non optimisés peut consommer des données et entraîner des frais pour les utilisateurs.
Problèmes de sécurité pouvant agir en tant que point de défaillance unique (SPOF) si votre page charge un script sans précaution.
Mise en cache HTTP insuffisante, obligeant le navigateur à envoyer davantage de requêtes réseau pour extraire des ressources.
Un manque de compression de serveur suffisant entraîne une lenteur de chargement 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 connues pour nuire à l'expérience utilisateur, telles que document.write()
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, ce qui gaspille des ressources et aggrave les problèmes de performances existants.
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.
Votre capacité à résoudre les problèmes liés aux scripts tiers peut dépendre de votre site et de votre capacité à configurer la manière dont vous chargez le 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 ?
La première étape pour optimiser votre site consiste à identifier les scripts tiers sur votre site et à déterminer leur impact sur les performances. Nous vous recommandons d'utiliser des outils de test de débit 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 vous indiquent combien de scripts tiers votre site utilise 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. L'image suivante, tirée de la section Les balises obsolètes, 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 marketing.
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:
Comment mesurer l'impact des scripts tiers sur ma page ?
Si vous constatez qu'un script pose problème, essayez de déterminer son rôle et si votre site en a besoin pour fonctionner. Si nécessaire, exécutez un test A/B pour équilibrer sa valeur perçue par rapport à son impact sur les principales métriques d'engagement utilisateur ou de performances.
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 vous aider à identifier les scripts tiers qui utilisent de manière intensive le processeur.
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 qui sont émises par des tiers et ralentissent le temps de chargement des pages. Les utilisateurs dépensent donc plus que leurs attentes en termes de données mobiles.
Outils pour les développeurs Chrome (blocage des requêtes réseau)
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 n'est pas disponible. Pour ce faire, vous pouvez utiliser le blocage des requêtes réseau, une fonctionnalité qui peut vous aider à 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 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 ensuite dans le panneau DevTools, ce qui vous permet de gérer les requêtes bloquées.
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.
- Cliquez sur Enregistrer.
- Chargez votre page. Les outils de développement présentent un diagramme en cascade représentant le temps de chargement de votre site.
- Accédez à la vue Ascendant au bas du panneau "Performances".
- Cliquez sur Grouper par produit, puis 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 notre workflow recommandé 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 du réseau et la limitation du processeur. Il est peu probable que vos utilisateurs bénéficient de connexions réseau et de matériel de bureau rapides, ce qui réduit 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 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 de chargement.
- Pour obtenir des données plus précises, vous pouvez mesurer votre temps de chargement au moins trois fois. Cela tient compte de certains scripts tiers qui récupèrent différentes ressources à chaque chargement de page. Pour vous aider, le panneau sur les performances des outils de développement accepte plusieurs enregistrements.
Mesurer l'impact de scripts tiers avec WebPageTest
WebPageTest permet de bloquer le chargement de requêtes individuelles afin de mesurer leur impact dans 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 suivant pour utiliser cette fonctionnalité:
- Testez une page sans bloquer des tiers.
- Répétez le test en bloquant certains tiers.
- Sélectionnez les deux résultats dans l'historique des tests.
- Cliquez sur Comparer.
L'image suivante montre la fonctionnalité de pellicule de WebPageTest comparant 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 d'identifier les domaines ayant le plus d'impact sur les performances de votre page.
WebPageTest prend également en charge deux commandes fonctionnant au niveau DNS pour bloquer des domaines:
blockDomainsaccepte une liste de domaines à bloquer.- blockDomainsExcept prend une liste de domaines et bloque tous les domaines ne figurant pas sur la liste.
WebPageTest comporte également un onglet SPOF (Single Point of faille, point de défaillance unique) qui vous permet de simuler un délai avant expiration ou un échec total du chargement d'une ressource. Contrairement au blocage de domaine, le protocole SPOF expire lentement, ce qui peut être utile pour tester le comportement de vos pages lorsque des services tiers sont soumis à une charge importante ou temporairement indisponibles.
Détecter les iFrame coûteux à l'aide de longues tâches
Lorsque les scripts d'iFrame tiers prennent beaucoup de temps, ils peuvent bloquer le thread principal et retarder d'autres tâches. Ces longues tâches peuvent ralentir le fonctionnement des gestionnaires d'événements ou provoquer une perte de frames, nuisant à l'expérience utilisateur.
Pour détecter les longues tâches liées à Real User Monitoring (RUM), utilisez l'API JavaScript PerformanceObserver afin d'observer les entrées de longtask. Ces entrées contiennent une propriété d'attribution que vous pouvez utiliser pour déterminer le contexte de frame à l'origine de la tâche longue.
Le code suivant enregistre 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 la page 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, envisagez d'auto-héberger le script.
- Si le script n'apporte aucune valeur claire à votre site, supprimez-le.
- Utilisez 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.
Utilisez async ou defer.
L'exécution JavaScript bloque l'analyseur. Lorsque le navigateur rencontre un script, il doit interrompre la construction DOM, le transmettre au moteur JavaScript et lui permettre de s'exécuter avant de poursuivre la construction DOM.
Les attributs async et defer modifient ce comportement comme suit:
asyncentraîne le téléchargement du script de manière asynchrone par le navigateur 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.deferentraîne le téléchargement asynchrone du script par le navigateur pendant qu'il continue à analyser le document HTML, puis attend la fin de l'exécution du script.
Utilisez toujours async ou defer pour les scripts tiers, sauf si ces scripts sont nécessaires 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, 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 des parties cruciales de votre site. Il s'agit, par exemple, 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 ne fonctionnent tout simplement pas s'ils sont chargés de manière asynchrone. Consultez la documentation de tous les scripts que vous utilisez et remplacez ceux qui ne peuvent pas être chargés de manière asynchrone par d'autres solutions possibles. Sachez que certains tiers recommandent d'exécuter leurs scripts de manière synchrone, même si leur fonctionnement asynchrone est tout aussi efficace.
N'oubliez pas que async ne permet pas de tout résoudre. Si votre page comprend un grand nombre de scripts, tels que des scripts de suivi à des fins publicitaires, leur chargement asynchrone ne l'empêchera pas de ralentir son chargement.
Utiliser des suggestions 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 et redirections DNS. Vous pouvez utiliser des conseils de ressource tels que pour effectuer des résolutions DNS pour les domaines hébergeant des scripts tiers dès le début du processus de chargement de la page, afin que le reste de la requête réseau puisse être traitée plus rapidement plus tard:
<link rel="dns-prefetch" href="http://example.com" />
Si le domaine tiers auquel vous vous connectez utilise HTTPS, vous pouvez également utiliser , qui effectue à la fois 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" />
Scripts "bac à sable" avec un iFrame
Si vous chargez un script tiers directement dans un iFrame, cela ne bloque pas l'exécution de la page principale. AMP utilise cette approche pour garder JavaScript en dehors 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 les Règles d'autorisation (anciennement Feature Policy), 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. Vous pouvez l'utiliser pour empêcher un contenu tiers d'introduire des comportements indésirables sur un site.
Scripts tiers auto-hébergés
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 peut-être l'héberger vous-même.
Cependant, 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 recevront 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é tant que vous ne pourrez pas les mettre à jour manuellement.
Vous pouvez également mettre en cache des scripts tiers à l'aide de service workers pour mieux contrôler la fréquence de récupération des scripts 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.
Effectuez des tests A/B sur de plus petits échantillons d'utilisateurs.
Les tests A/B (ou tests fractionnés) sont une technique permettant d'expérimenter deux versions d'une page dans le but d'analyser l'expérience utilisateur et le comportement. Il met les versions de la page à la disposition de différents échantillons de trafic sur votre site Web et détermine, à partir d'analyses, quelle version offre le meilleur taux de conversion.
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. Ce processus peut aggraver l'expérience, même pour les utilisateurs qui ne participent pas au test.
Pour accélérer l'affichage de la page, nous vous recommandons d'envoyer vos scripts de tests A/B à un échantillon plus petit de votre base d'utilisateurs et d'exécuter le code qui détermine la version de la page à afficher côté serveur.
Ressources tierces de chargement différé
Les ressources tierces intégrées, telles que les annonces et les vidéos, peuvent contribuer fortement à 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 lorsque cela est nécessaire, par exemple en attendant de diffuser des annonces en pied de page jusqu'à ce que l'utilisateur fasse défiler l'écran suffisamment loin pour les voir. Vous pouvez également effectuer un chargement différé du contenu tiers après le chargement du contenu de la page principale, mais avant qu'un utilisateur ne puisse interagir avec la page.
Soyez prudent lorsque vous chargez des ressources de manière différée, car il implique souvent du code JavaScript qui peut être affecté par des connexions réseau irrégulières.
La documentation officielle de DoubleClick fournit des conseils sur le chargement différé des annonces.
Chargement différé efficace avec Intersection Observer
Par le passé, les méthodes permettant de détecter si un élément était visible dans la fenêtre d'affichage à des fins de chargement différé étaient sujettes aux erreurs et ralentissent souvent le navigateur. Ces méthodes inefficaces écoutent souvent les événements de défilement ou de 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 les entrées et sorties d'un élément observé dans la fenêtre d'affichage du navigateur. LazySizes offre également une compatibilité facultative avec IntersectionObserver.
Analyse de la charge différée
Si vous retardez le chargement de vos scripts d'analyse pendant trop longtemps, vous pouvez manquer des données d'analyse précieuses. Heureusement, il existe des stratégies permettant d'initialiser les analyses en différé tout en conservant les données de chargement précoce.
L'article de blog de Phil Walton intitulé The Google Analytics Setup I Use on Every Site I Build (La configuration Google Analytics que j'utilise pour chaque site que je crée) traite de l'une de ces stratégies pour Google Analytics.
Charger des scripts tiers en toute sécurité
Cette section fournit des conseils pour 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. C'est un problème, car document.write() se comporte de manière incohérente et ses défaillances sont difficiles à déboguer.
La solution aux problèmes document.write() consiste à ne pas l'utiliser. Dans Chrome 53 et versions ultérieures, les outils pour les développeurs Chrome enregistrent 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 surbrillance les scripts tiers qui utilisent encore document.write().
document.write().Utiliser Tag Manager 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 du contenu tiers à un site, tel que des widgets de réseaux sociaux. Ces tags 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. Il est donc de plus en plus difficile d'en limiter l'impact pour les utilisateurs à mesure que des balises sont ajoutées.
Pour que les pages se chargent rapidement, 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 bloquent pas le chargement mutuellement, de réduire le nombre d'appels réseau nécessaires à un navigateur pour exécuter des balises et de collecter les données de tag 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, leur utilisation prudente peut ralentir le chargement, comme suit:
- Un nombre excessif de balises et d'écouteurs d'événements automatiques dans votre gestionnaire de balises entraîne l'envoi par le navigateur de plus de requêtes réseau qu'il n'en aurait autrement, 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 JavaScript à votre gestionnaire de balises. Cela peut non seulement augmenter le nombre de requêtes réseau coûteuses nécessaires au chargement de votre page, mais é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 à Tag Manager.
Éviter les scripts qui polluent le champ d'application global
Les scripts tiers peuvent se comporter de différentes manières et entraîner le dysfonctionnement de votre page:
- Les scripts qui chargent des dépendances JavaScript peuvent polluer le champ d'application global avec du code qui interagit mal avec votre code.
- Des mises à jour inattendues peuvent entraîner des modifications destructives.
- Le code tiers peut être modifié pendant le transfert afin qu'il se comporte différemment entre le test et le déploiement de votre page.
Nous vous recommandons d'effectuer des audits réguliers des scripts tiers que vous chargez afin de détecter les acteurs malintentionnés. Vous pouvez également mettre en œuvre les tests automatiques, l'intégrité des sous-ressources et la transmission sécurisée de code tiers pour protéger votre page.
Stratégies d'atténuation
Voici quelques stratégies à grande échelle pour réduire 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 la section Contenu mixte.
Bac à sable : pensez à exécuter des scripts tiers dans des cadres iFrame avec l'attribut
sandboxafin de limiter les actions disponibles pour ces 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 scripts approuvés pour votre site, ainsi que pour détecter et atténuer les effets de certaines attaques, telles que les scripts intersites (XSS).
Voici un exemple d'utilisation de l'instruction script-src de 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>
Complément d'informations
Pour en savoir plus sur l'optimisation de JavaScript tiers, nous vous recommandons de lire ce qui suit:
- 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.