Les ressources tierces (telles que les intégrations et les scripts) sont aujourd'hui très utilisées sur le Web. Ils fournissent des solutions prêtes à l'emploi pour l'intégration de réseaux sociaux, de vidéos, d'analyses, de chats en direct, de publicités, de tests A/B, de personnalisations et plus encore. Les intégrations tierces font partie intégrante des sites Web modernes. Elles permettent aux propriétaires de sites de se concentrer sur leurs compétences de base, tout en déléguant les fonctions standards, mais essentielles, à des fournisseurs externes.
Lorsque les propriétaires et les tiers d'une page Web travaillent en harmonie, une page peut offrir une expérience utilisateur de qualité. Cependant, cette approche nécessite un effort important de la part des ingénieurs et des équipes commerciales. Elle est souvent négligée, ce qui entraîne des pages Web moins performantes et un impact négatif sur les métriques axées sur les utilisateurs telles que les Core Web Vitals. Cela nuit aux deux parties et crée des opportunités manquées dans les entreprises. Peut-on faire mieux ici ?
Nous envisageons l'avenir du Web : les scripts et les ressources tiers apporteront la valeur commerciale prévue avec un minimum de régression sur les performances ou l'expérience utilisateur des sites Web qui les utilisent dans le navigateur. Idéalement, les utilisateurs pourront ainsi bénéficier d'un chargement de page plus rapide.
Au cours de l'année écoulée, nous avons étudié, discuté et expérimenté de nombreuses possibilités qui pourraient potentiellement protéger l'expérience utilisateur des effets néfastes des scripts tiers, sans réduire leur valeur commerciale pour les propriétaires de sites.
Grâce à cet article, nous souhaitons partager des informations sur certaines de nos expériences. Nous espérons que ce processus marque le début d'un processus qui favorisera la transparence et la visibilité entre les user-agents, les entreprises et les fournisseurs tiers, et qui ouvrira la voie à un Web plus rapide.
Explications détaillées sur les tiers
Un tiers est une ressource servie par un fournisseur externe au site. Ils ne sont pas directement sous le contrôle du propriétaire du site, mais ils le sont avec leur approbation. Les ressources tierces sont:
- Hébergé sur une origine partagée et publique différente de l'origine du site principal.
- Il n'est pas rédigé ni influencé par un propriétaire de site particulier.
- Largement utilisé par une variété de sites.
Qu'il s'agisse de générer des revenus (via des annonces) ou de proposer de meilleures opportunités marketing (intégration de médias sociaux), les tiers répondent à une grande variété d'objectifs commerciaux. Les tiers les plus courants sont les suivants:
Source: Tiers par catégorie.
| Catégorie | Définition |
|---|---|
| Publicité | Scripts utilisés pour diffuser des annonces ou mesurer les performances des annonces. |
| Vidéo | Scripts permettant d'activer le lecteur vidéo et les fonctionnalités de streaming |
| Bibliothèques hébergées | Un mélange de bibliothèques Open Source publiques. |
| Contenus | Scripts de fournisseurs de contenu ou suivi d'affiliation spécifique à l'éditeur |
| Témoignages de clients | Des scripts créés par des prestataires d'assistance client ou des prestataires de marketing qui proposent des solutions de chat et de contact. |
| Hébergement | Scripts issus de plates-formes d'hébergement Web |
| Marketing | Scripts d'outils marketing permettant d'ajouter des pop-ups, des newsletters, etc. |
| Réseau social | Scripts qui activent des fonctionnalités de réseaux sociaux. |
| Tag Manager | Scripts qui chargent de nombreux autres scripts et lancent de nombreuses tâches. |
| Analyse | Scripts qui mesurent ou suivent les utilisateurs et leurs actions. |
| Plate-forme de consentement aux cookies | Scripts permettant aux sites d'obtenir le consentement de l'utilisateur (RGPD, ePR, CCPA) de manière éclairée et transparente. |
| Utilitaire | Scripts qui sont des utilitaires de développement (clients API, surveillance des sites, détection des fraudes, etc.). |
| Autre | Scripts divers diffusés via une origine partagée sans catégorie ni attribution précises. |
Ces bibliothèques et scripts tiers permettent aux développeurs Web d'exploiter des solutions éprouvées pour implémenter des fonctionnalités standards au lieu de réinventer la roue. Ainsi, les tiers réduisent le temps de développement et aident les entreprises à lancer ou mettre à niveau leurs produits plus rapidement. Il n'est donc pas étonnant que plus de 94% de tous les sites Web sur ordinateur et sur mobile utilisent des tiers.
Quel est l'impact des tiers sur les performances ?
Dans l'idéal, les développeurs de tiers sont des experts sur les fonctionnalités spécifiques qu'ils fournissent. La plupart des fournisseurs tiers populaires ont subi plusieurs itérations. Ils peuvent s'attendre à ce que leur code soit optimisé en fonction de leurs propres objectifs commerciaux, qui peuvent inclure ou non les performances des pages qui les utilisent. Cependant, nous savons que même les outils tiers les mieux optimisés affectent les performances. Voici les principales raisons de cet impact:
Coûts liés à la taille et à l'exécution des scripts: les tiers cherchent souvent à fournir des fonctionnalités importantes en ajoutant simplement un élément
<script>ou<iframe>sur votre page. Ces éléments importent ensuite les scripts et les ressources de taille importante, dont le téléchargement et l'exécution prennent plus de temps. Un nombre trop important de code JavaScript maintient le thread principal occupé plus longtemps, bloque l'affichage et retarde les interactions utilisateur. Certains des principaux fournisseurs tiers bloquent le fil de discussion principal de 42 ms à 1,6 s pour plus de 50% des sites analysés. Un thread principal bloqué entraîne un temps total de blocage (TBT) élevé, qui est l'une des métriques ayant une incidence sur le score de performances du site. En outre, cela retarde également la réponse aux interactions des utilisateurs et diminue la métrique Interaction to Next Paint (INP) qui permet de mesurer la réactivité des sites Web. Ainsi, les coûts d'exécution des scripts ont un impact significatif sur les performances.Nombre: en moyenne, les sites Web utilisent environ 21 tiers différents sur mobile et sur le Web. Souvent, les balises tierces sont ajoutées par des outils de gestion des balises qui ne sont pas directement contrôlés par les équipes techniques/de développement. Les tags qui ne sont pas obligatoires peuvent être ajoutés par d'autres équipes sans examen préalable et ne sont jamais supprimés. Ils peuvent avoir un impact significatif sur l'expérience utilisateur, le poids de la page ou l'utilisation du processeur. La mise en place d'un processus de gouvernance permet de résoudre ces situations et de permettre aux développeurs d'auditer l'impact de chaque fournisseur. Il serait utile que les développeurs disposent de données prêtes à l'emploi pour tous les tiers qui fournissent une fonction spécifique avec leur impact sur les performances, leurs avantages et leurs compromis à des fins de comparaison. Les équipes sont également confrontées à un autre défi : pour de nombreux sites, les balises tierces ne s'exécutent qu'en production, mais pas dans leurs environnements de développement. Il est donc plus difficile pour les développeurs de les tester.
Réseau: puisque les tiers sont hébergés sur des origines différentes, les navigateurs doivent établir un plus grand nombre de connexions pour pouvoir télécharger leur contenu. Les différentes connexions ne peuvent pas coordonner le téléchargement en fonction de la priorité, ce qui entraîne des conflits sur le réseau. Le chargement de la page peut être davantage retardé si les optimisations appropriées ne sont pas prises en compte.
Séquençage: les tiers peuvent bloquer le thread principal et gérer la bande passante pour des ressources plus critiques. Cela dit, dans certains cas, les tiers constituent les ressources essentielles nécessaires à l'affichage d'une page. Un séquencement optimal des ressources propriétaires et tierces devient nécessaire lorsque les sites Web utilisent plusieurs tiers. Les développeurs Web doivent connaître les différentes options disponibles pour optimiser le séquencement.
Par conséquent, les tiers peuvent avoir une incidence sur tout ou partie des composants des métriques Core Web Vitals. La majorité des tiers ont un impact négatif sur le Largest Contentful Paint (LCP) et le First Input Delay (FID). Les intégrations YouTube bloquent le fil de discussion principal pendant 4,5 secondes pour 10% des sites Web sur mobile et pendant au moins 1,6 seconde pour 50% des sites Web étudiés. Imaginez la frustration d'un utilisateur qui arrivait sur une page contenant 20 scripts de ce type avec une connexion lente. La visualisation suivante de thirdpartyweb.today montre les tiers dont l'impact sur les performances est le plus important à l'heure actuelle.
"Sur les 4 millions de sites les plus importants, environ 2 700 origines représentent environ 57% de la durée totale d'exécution des scripts, les 50 principales entités représentant déjà environ 47 %." - Web tiers
Les pages qui s'affichent rapidement et deviennent interactives dans un délai raisonnable sont essentielles à une bonne expérience utilisateur selon les métriques Core Web Vitals. Une bonne expérience utilisateur se traduit souvent par de bonnes affaires pour les sites Web, ce qui peut se traduire par de bonnes affaires pour les tiers utilisés. Travailler ensemble pour réduire l'impact des tiers peut être bénéfique pour tous les acteurs de la chaîne.
Nous savons que Google fournit un certain nombre de scripts tiers couramment utilisés, y compris Google Tag Manager, les intégrations YouTube et ReCaptcha, pour n'en citer que quelques-uns. Nous sommes conscients qu'un certain nombre de nos scripts peuvent avoir un impact moins important sur les performances des métriques Core Web Vitals. Nous nous engageons à explorer les moyens d'améliorer cet impact dans la mesure du possible.
Comment Chrome peut-il vous aider ?
Les performances médiocres des ressources tierces représentent souvent un défi pour les développeurs, ce qui implique de modifier pas à pas la dynamique sous-jacente de l'écosystème. Chrome souhaite explorer cette opportunité pour obtenir les résultats suivants:
Trouvez de meilleures façons de charger des ressources tierces sur le Web sans nuire à l'expérience utilisateur ni aux résultats commerciaux.
Nous savons que nous ne pouvons pas aller loin dans cette démarche si nous ne collaborons pas avec des partenaires, des entreprises, des tiers et des développeurs. Nous voulons créer un champ ouvert pour discuter des possibilités et échanger des idées par le biais d'explications et de spécifications publiques. Les développeurs auront le temps de donner leur avis et de tester l'impact d'un grand nombre de ces propositions.
Permettez aux utilisateurs de scripts tiers d'obtenir une meilleure attribution de leurs coûts en outils et sur le terrain, de chemins clairs et bien rodés pour leur utilisation, et de meilleures incitations au moment de la création pour s'assurer qu'ils sont optimaux par défaut.
Nous souhaitons améliorer toutes les couches, telles que les user-agents, les frameworks et les scripts tiers, afin de réduire l'impact des tiers sur les performances. Nous souhaitons également fournir suffisamment d'informations pour aider les propriétaires de sites à appliquer les bonnes pratiques concernant chaque script intégré, y compris des alternatives plus rapides, le cas échéant.
Approche proposée
Pour obtenir ces résultats, nous proposons une approche en trois étapes...
**Fournissez aux développeurs une attribution plus approfondie de l'impact pour les tiers via RUM et dans les outils pour les développeurs Chrome.**
Le RUM fait référence à des métriques utilisateur réelles (également appelées données de terrain) disponibles via les API Web Performance Monitoring. Les outils pour les développeurs Chrome incluent Lighthouse, les outils pour les développeurs Chrome et le rapport d'expérience utilisateur Chrome. Nous proposons d'améliorer les API et les outils disponibles afin que les développeurs de sites comprennent l'impact de chaque tiers qu'ils ont utilisé sur chaque page. Ces outils les informeront également sur les mesures qu'ils peuvent prendre pour atténuer l'impact (par exemple, les reporter ou utiliser des façons) et exploreront d'autres solutions potentielles (autres tierces ou DIY) en faisant des compromis. Pour les API de surveillance des performances Web, nous étudions des moyens d'étendre leur couverture des ressources multi-origines sans compromettre la confidentialité ni la sécurité de nos utilisateurs.
**Donnez aux établissements un chemin bien éclairé pour qu'ils puissent charger efficacement les ressources tierces.**
Nous souhaitons proposer de nouvelles normes qui encouragent les navigateurs à faire des compromis plus judicieuses entre le chargement des ressources propriétaires et tierces, afin d'améliorer l'expérience de chargement pour les utilisateurs. Par la suite, nous présenterons certaines de ces propositions, comme le chargement différé des intégrations tierces par défaut ou l'application de priorités différentes pour les ressources tierces, qui peuvent ne pas être aussi importantes pour le contenu initial qui intéresse le plus les utilisateurs. Ce ne sont là que quelques exemples d'idées que nous évaluons dans ce domaine, et nous aimerions collaborer avec des spécialistes des performances Web et la communauté au sens large pour façonner ce travail.
Nous souhaitons également résoudre les problèmes liés aux frameworks JavaScript et aux systèmes de gestion de contenu (CMS), le cas échéant. Des projets tels que Aurora et l'équipe WordPress Performance nous ont appris l'importance des valeurs par défaut intégrées pour résoudre les problèmes de chargement connus. Des modèles par défaut intégrés à des frameworks et des CMS guident les entreprises sur une voie bien éclairée. Elles peuvent également être utiles au user-agent (Chrome, par exemple) pour lui permettre d'appliquer des méthodes heuristiques afin d'optimiser le chargement des pages et le contrôle des métriques Core Web Vitals. Ces indications peuvent aider le user-agent à décider quand et comment des tiers spécifiques doivent se charger dans le cycle de vie de la page. Par exemple, le composant de script Next.js intègre une valeur par défaut permettant de charger des scripts tiers une fois que la page devient interactive.
**Offrez aux tiers des incitations pour réduire leur impact sur les performances en améliorant la transparence.**
À l'heure actuelle, les développeurs tiers ne disposent pas de la visibilité nécessaire pour comprendre l'impact de leurs scripts sur l'ensemble des sites. Nous prévoyons de résoudre ce problème et de fournir à ces fournisseurs des outils pour analyser leur impact et le comparer à d'autres produits du marché qui offrent la même valeur. Nous voulons également les aider à utiliser les données pour identifier les causes de l'impact, afin qu'ils puissent l'atténuer en amont. Pour réussir, nous devrons mentionner tous les tiers, y compris ceux créés par Google.
Challenges
Un effort d'une telle ampleur n'est pas sans conséquence. Voici quelques-unes des principales difficultés que nous devons prendre en compte.
- Les tiers représentent un problème transversal impliquant les annonces, les analyses, la gestion des balises, les services publics et bien d'autres. Chaque domaine nécessite de tenir compte d'un ensemble unique d'exigences et de compromis. Exemple :
- La décision d'optimiser le chargement des annonces dépend d'un compromis entre revenus et expérience utilisateur. Trop tôt, elles bloquent les contenus intéressants ; trop tard, l'utilisateur passerait à côté de ces contenus.
- Les scripts Analytics augmentent la pondération de la page, mais fournissent des données précieuses sur les actions des utilisateurs pour l'entreprise.
Nous espérons établir des partenariats avec différentes catégories de tiers, saisir les nuances en jeu, résoudre les compromis et développer des incitations qui conviennent à tous. Nous sommes conscients que nous devons travailler séparément avec des entités dans tous les domaines pour que notre stratégie soit efficace. y compris nos partenaires internes tels que Google Tag Manager, Google Ads et YouTube.
Nous souhaitons établir une attribution plus approfondie aux développeurs de sites et aux développeurs tiers. Cela nécessite un effort consciencieux, dans lequel nous identifions les données les plus pertinentes pour mesurer l'impact, nous les attribuons avec précision et précision, et nous indiquons la bonne voie à suivre. En fin de compte, le calcul des performances d'un tiers donné par rapport à ses concurrents doit être transparent pour tout le monde.
Nous proposons d'améliorer Chrome afin qu'il puisse appliquer des optimisations qui aident à trouver le juste équilibre entre le chargement des ressources propriétaires et des ressources tierces. Une modification importante est alors appliquée de manière standard dans tous les navigateurs, mais cela prend du temps. Par exemple, l'attribut
loadingpour les éléments<img>et<iframe>est disponible dans Chrome/Edge depuis 2019, mais n'est disponible dans Safari qu'en 2022. Tant qu'une fonctionnalité n'est pas standardisée, les utilisateurs de ressources tierces devront s'assurer qu'elles ont également été optimisées pour d'autres navigateurs. Nous vous aiderons en le mettant en évidence dans nos conseils, le cas échéant.Pour mener à bien ce projet, nous devrons collaborer avec des partenaires et des développeurs non seulement pour nous aider à comprendre des exigences spécifiques, mais aussi pour tester des solutions expérimentales à grande échelle, fournir des commentaires, effectuer des itérations et improviser selon les besoins. Les changements devront être planifiés, en laissant un délai raisonnable pour les tests et l'évaluation.
Propositions de normes initiales
Nous avons effectué quelques tests initiaux afin de développer des fonctionnalités que vous pouvez activer afin d'optimiser le processus de chargement tiers. Nous sommes satisfaits des résultats observés, et nous pouvons d'ores et déjà vous présenter deux de ces caractéristiques.
LazyEmbeds
Auparavant, Chrome effectuait le chargement différé des éléments <img> et <iframe> hors de l'écran pour les utilisateurs en mode simplifié. Cette fonctionnalité peut être étendue à tous les utilisateurs afin de différer le chargement des éléments <iframe> identifiés comme étant des intégrations tierces jusqu'à ce qu'ils fassent défiler la page à proximité. Cela peut accélérer le chargement d'autres parties de la page, améliorer les métriques Core Web Vitals, réduire l'utilisation de la mémoire et économiser des données.
Voici une démonstration d'utilisation de LazyEmbeds pour charger différé des vidéos YouTube sur une page. En général, une seule vidéo YouTube intégrée ajoute 500 à 600 Ko de JavaScript à la page. Nous avons essayé d'optimiser un article de blog avec 14 vidéos intégrées à l'aide de LazyEmbeds. Les résultats étaient prometteurs en termes de temps de chargement des pages et d'économies de données.
| Avant | Après | |
|---|---|---|
| Données | 15,4 Mo | 6,1 Mo |
| Total Blocking Time | 3,2 secondes | 1,6 seconde |
Pour en savoir plus sur ce travail, consultez notre fil d'explication sur l'intent à tester et l'extension de test sur blink-dev.
Limitation tierce ciblée
Les scripts tiers sont souvent ajoutés par diverses équipes sans processus de surveillance global. L'équipe d'ingénieurs de The Telegraph a formulé l'exemple suivant : "Tout le monde veut 'ce tag' sur une page qui rapportera de l'argent à l'organisation". Cela peut sans cesse augmenter la charge de gestion de l'impact sur les performances.
La limitation des scripts tiers ciblés consiste à limiter des types très spécifiques de tiers afin d'atténuer leur impact. Cela permettrait aux navigateurs de charger le contenu clé et les tiers importants plus tôt, tandis que ceux qui peuvent être chargés ultérieurement sont limités.
Améliorer les API RUM
Nous envisageons également d'améliorer les API RUM afin d'y inclure des informations utiles pour évaluer les performances des tiers. Voici les améliorations apportées:
Rapports
<iframe>: nous travaillons sur des solutions qui peuvent exploiter l'API Performance Timeline pour la création de rapports multiframe. Cela permettrait aux auteurs de la page de premier niveau d'inspecter les données sur les performances d'un iFrame tiers coopératif intégré à la page.Attribution de tâches longues: l'API Long Tasks de type RUM aidera les propriétaires de sites à identifier les longues tâches qui occupent le thread principal pendant un long moment et retardent les interactions.
Autres mises à jour
Nous testons encore beaucoup d'idées de ce type et espérons publier des explications GitHub et des ébauches de spécifications à mesure que nous avancerons. Les tiers et les propriétaires de sites qui souhaitent collaborer avec nous ou nous faire part de vos commentaires peuvent contribuer aux discussions via ces outils. Les tiers peuvent également commencer à se concentrer sur l'optimisation des métriques Core Web Vitals et INP pour s'assurer que les données Core Web Vitals/INP ne leur sont pas attribuées. Pour l'instant, les personnes qui recherchent activement des mises à jour peuvent se référer aux posts du groupe blink-dev.
Nous sommes impatients d'explorer davantage cette problématique et d'échanger avec la communauté pour partager nos enseignements.
Nous remercions particulièrement Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. Jose, Melissa Mitchell, Yoav Weiss, Shunya Shishido et Minoru Chikamune pour leurs commentaires et leurs contributions.