Addy Osmani

Les ressources tiers (telles que les éléments intégrés et les scripts) sont très utilisées sur le Web aujourd'hui. Ils proposent des solutions prêtes à l'emploi pour intégrer des réseaux sociaux, des vidéos, des données analytiques, un chat en direct, de la publicité, des tests A/B, de la personnalisation, etc. Les intégrations tierces sont un élément indispensable 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 des fonctions standards mais essentielles à des fournisseurs externes.

Lorsque les composants first party et tiers d'une page Web fonctionnent de manière harmonieuse, la page peut offrir une expérience utilisateur de qualité. Cependant, cela nécessite des efforts importants de la part des équipes d'ingénierie et d'entreprise, et est souvent négligé, ce qui se traduit par des pages Web moins performantes et un impact négatif sur les métriques axées sur l'utilisateur, telles que les Core Web Vitals. Cela est préjudiciable aux deux parties et crée des opportunités manquées pour les entreprises. Pouvons-nous faire mieux ?

Nous avons une vision future du Web dans laquelle les scripts et les ressources tiers fournissent la valeur commerciale prévue avec une régression minimale des performances ou de l'expérience utilisateur des sites Web qui les utilisent dans le navigateur. Cela permettrait aux utilisateurs de charger les pages plus rapidement.

Au cours de l'année écoulée, nous avons examiné, discuté et testé de nombreuses possibilités susceptibles de protéger l'expérience utilisateur contre l'impact négatif des scripts tiers, sans réduire leur valeur commerciale pour les propriétaires de sites.

Dans cet article, nous souhaitons vous communiquer des informations sur certains de nos tests. Nous espérons que ce début de processus encouragera la transparence et la visibilité entre les agents utilisateur, les entreprises et les fournisseurs tiers, et ouvrira la voie à un Web plus rapide.

Informations détaillées sur les tiers

Un tiers est une ressource gérée par un fournisseur externe au site. Elles ne sont pas directement contrôlées par les propriétaires du site, mais sont présentes avec leur approbation. Les ressources tierces sont les suivantes:

• Hébergé sur une origine partagée et publique différente de celle du site principal.
• Elles ne sont pas rédigées ni influencées par un propriétaire de site individuel.
• Largement utilisé par divers sites.

Les tiers contribuent à générer des revenus (via les annonces) et à offrir de meilleures opportunités marketing (intégration de réseaux sociaux), et servent ainsi à atteindre une grande variété d'objectifs commerciaux. Voici les catégories courantes de tiers:

Source: Tiers par catégorie.

Ces scripts et bibliothèques 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 mobile utilisent des tiers.

Quel est l'impact des tiers sur les performances ?

Idéalement, les développeurs tiers sont des experts des fonctionnalités spécifiques qu'ils fournissent. Les tiers les plus populaires ont subi plusieurs itérations. On peut s'attendre à ce que leur code soit optimisé pour leurs propres objectifs commerciaux, ce qui peut ou non inclure les performances des pages qui les utilisent. Toutefois, nous savons que même les tiers les plus optimisés affectent les performances. Voici les principales raisons de cet impact:

1. Taille et coûts d'exécution du script: les tiers visent souvent à fournir des fonctionnalités importantes "juste" en insérant un élément <script> ou <iframe> sur votre page. Ces éléments extraient ensuite des scripts et des ressources de grande taille qui prennent plus de temps à télécharger et à exécuter. Trop de code JavaScript occupe le thread principal plus longtemps, bloque le rendu et retarde les interactions des utilisateurs. Certains des principaux tiers ont été connus pour bloquer le thread principal pendant 42 ms à 1,6 s pour plus de 50% des sites analysés. Un thread principal bloqué entraîne un temps de blocage total (TBT) élevé, qui est l'une des métriques qui affectent le score de performances du site. De plus, cela retarde la réponse aux interactions des utilisateurs et dégrade la métrique Interaction to Next Paint (INP) utilisée pour mesurer la réactivité des sites Web. Par conséquent, les coûts d'exécution des scripts ont un impact significatif sur les performances.

2. Nombre: en moyenne, les sites Web utilisent environ 21 tiers différents sur mobile et sur le Web. Les balises tierces sont souvent ajoutées par des outils de gestion des balises qui ne sont pas directement contrôlés par les équipes techniques/de développement. Des balises non obligatoires peuvent être ajoutées par d'autres équipes sans examen et ne sont jamais supprimées. Ils peuvent avoir un impact important sur l'expérience utilisateur, le poids de la page ou l'utilisation du processeur. L'établissement d'un processus de gouvernance peut résoudre ce type de situations et 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 doivent également faire face à un autre défi : pour de nombreux sites, leurs balises tierces ne s'exécutent qu'en production, et non dans leurs environnements de développement. Il est donc plus difficile pour les développeurs de les tester.

3. Réseau: comme les tiers sont hébergés sur différentes origines, les navigateurs doivent établir un plus grand nombre de connexions pour télécharger du contenu auprès d'eux. Les différentes connexions ne peuvent pas coordonner le téléchargement en fonction de la priorité, ce qui entraîne des conflits réseau. Cela peut encore retarder le chargement de la page si les optimisations appropriées ne sont pas prises en compte.

4. Séquencement: les tiers peuvent bloquer le thread principal et se battre pour la bande passante avec des ressources plus critiques. Toutefois, dans certains cas, les ressources tierces sont les ressources essentielles requises pour l'affichage de la page. Une séquence optimale des ressources first party 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équençage.

Par conséquent, les tiers peuvent affecter l'un ou l'ensemble des composants des 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 thread 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 s'il tombe sur une page contenant 20 scripts de ce type sur une connexion lente. La visualisation suivante de thirdpartyweb.today montre les tiers ayant le plus d'impact sur les performances à l'heure actuelle.

"Sur les ~4 millions de sites les plus populaires, ~2 700 origines représentent ~57% de la durée d'exécution de tous les scripts, dont ~47 % pour les 50 premières entités." - third-party-web

Les pages qui s'affichent rapidement et deviennent interactives dans un délai raisonnable sont essentielles à une bonne expérience utilisateur, comme le mesurent les Core Web Vitals. Une bonne expérience utilisateur se traduit souvent par de bonnes affaires pour les sites Web, ce qui peut être bénéfique pour les tiers utilisés. En travaillant ensemble pour réduire l'impact des tiers, tous les acteurs de la chaîne peuvent en bénéficier.

Nous reconnaissons que Google vend un certain nombre de scripts tiers couramment utilisés, y compris Google Tag Manager, les implémentations YouTube et ReCaptcha, pour n'en citer que quelques-uns. Nous sommes conscients qu'un certain nombre de nos scripts pourraient avoir un impact plus faible sur les performances des métriques Core Web Vitals. Nous nous engageons à trouver des moyens d'améliorer cet impact dans la mesure du possible.

Comment Chrome peut-il vous aider ?

Les performances des ressources tierces sont souvent un défi pour les développeurs, qui doivent alors modifier de manière significative la dynamique de l'écosystème sous-jacent. Chrome souhaite explorer cet espace pour obtenir les résultats suivants:

1. Trouvez de meilleures façons de charger des ressources tierces sur le Web sans dégrader l'expérience utilisateur ni les résultats commerciaux.

   Nous savons que nous ne pourrons pas aller bien loin dans cette démarche si nous ne collaborons pas avec nos partenaires, nos entreprises, nos tiers et nos développeurs. Nous souhaitons créer un espace ouvert pour discuter des possibilités et échanger des idées via des explications et des spécifications publiques. Les développeurs auront le temps de nous faire part de leurs commentaires et de tester l'impact de nombreuses propositions.

2. Permettre aux utilisateurs de scripts tiers d'attribuer plus facilement leurs coûts en outils et sur le terrain, de définir des chemins clairs et bien balisés pour leur utilisation, et de bénéficier d'incitations plus intéressantes lors 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 prévoyons également de fournir des insights suffisants 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

Nous proposons une approche en trois volets pour atteindre ces résultats :

1. **Fournissez aux développeurs une attribution plus précise de l'impact par tiers via le RUM et les outils pour les développeurs de Chrome.**

   Le RUM fait référence aux données de métriques utilisateur réelles (également appelées données de terrain) disponibles via les API de surveillance des performances Web. Les outils pour les développeurs de Chrome incluent Lighthouse, les outils de développement 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 puissent comprendre l'impact de chaque tiers qu'ils ont utilisé sur chaque page. Ils leur indiqueront également les mesures qu'ils peuvent prendre pour atténuer l'impact (par exemple, les différer ou utiliser des facades) et explorer d'autres solutions potentielles (autres tiers ou bricolage) avec des compromis. Pour les API de surveillance des performances Web, nous étudions comment étendre leur couverture des ressources multi-origines sans compromettre la confidentialité et la sécurité de nos utilisateurs.

2. **Fournissez aux entreprises un chemin d'accès clair pour charger efficacement les ressources tierces.**

   Nous souhaitons proposer de nouvelles normes qui encouragent les navigateurs à faire des compromis plus intelligents entre la façon dont les ressources propriétaires et tierces sont chargées, dans le but d'améliorer l'expérience de chargement pour les utilisateurs. Nous mettrons en avant certaines de ces propositions plus tard, comme le préchargement des éléments intégrés tiers par défaut ou l'application de différentes priorités de ressources aux ressources tierces qui ne sont peut-être pas aussi essentielles au contenu initial qui intéresse le plus les utilisateurs. Il ne s'agit que d'un petit nombre d'idées que nous évaluons dans ce domaine. Nous serions ravis de collaborer avec des experts en performances Web et avec la communauté plus large pour façonner ce travail.

   Nous aimerions également résoudre ces problèmes dans les frameworks JavaScript et les systèmes de gestion de contenu (CMS) lorsque cela est approprié. Des projets tels que Aurora et l'équipe WordPress Performance nous ont appris l'importance des valeurs par défaut intégrées qui résolvent les problèmes de chargement connus. Les valeurs par défaut intégrées aux frameworks et aux CMS guident les entreprises sur un chemin bien éclairé. Ils peuvent également être utiles à l'agent utilisateur (par exemple, Chrome) en tant qu'indices lui permettant d'appliquer des heuristiques pour optimiser le chargement de la page et le CWV. Ces indications peuvent aider l'agent utilisateur à déterminer quand et comment des tiers spécifiques doivent être chargés au cours du cycle de vie de la page. (Par exemple, le composant de script Next.js est configuré par défaut pour charger des scripts tiers une fois que la page est interactive.)

3. **Donnez aux tiers des incitations à réduire leur impact sur les performances grâce à une meilleure transparence.**

   Les développeurs tiers ne disposent actuellement pas de la visibilité nécessaire pour comprendre l'impact de leurs scripts sur les sites en général. Nous prévoyons de résoudre ce problème et de fournir à ces fournisseurs des outils pour analyser leur impact et le comparer à celui d'autres produits du marché qui offrent la même valeur. Nous voulons également les aider à utiliser les données pour diagnostiquer la cause de l'impact afin qu'ils puissent l'atténuer en amont. Pour y parvenir, nous devrons faire appel à tous les tiers, y compris ceux créés par Google.

Défis

Un effort de cette ampleur n'est pas sans difficultés. Voici quelques-uns des principaux défis que nous devons prendre en compte :

• Les tiers constituent un problème transversal impliquant les annonces, l'analyse, la gestion des balises, les utilitaires, etc. Chaque domaine nécessite de prendre en compte un ensemble unique d'exigences et de compromis. Exemple :
  • La décision d'optimiser le chargement des annonces dépend d'un compromis entre les revenus et l'expérience utilisateur. S'ils apparaissent trop tôt, ils bloquent du contenu intéressant ; s'ils apparaissent trop tard, l'utilisateur ne les voit pas.
  • Les scripts Analytics augmentent le poids de la page, mais fournissent à l'entreprise des données précieuses sur les actions des utilisateurs.

Nous espérons collaborer avec différentes catégories de tiers, saisir les nuances impliquées, résoudre les compromis et développer des incitations qui fonctionnent pour tous. Nous sommes conscients que nous devons travailler séparément avec les entités de chaque zone pour que notre stratégie soit efficace. Cela inclut nos partenaires internes tels que Google Tag Manager, Google Ads et YouTube.

1. Nous souhaitons fournir une attribution plus précise aux développeurs de sites et aux développeurs tiers. Pour ce faire, nous devons identifier les données les plus pertinentes pour mesurer l'impact, les attribuer de manière précise et détaillée, et vous indiquer la bonne voie à suivre. En fin de compte, le calcul des performances d'un tiers donné par rapport à ses concurrents doit être transparent pour tous.

2. Nous proposons d'améliorer Chrome afin qu'il puisse appliquer des optimisations qui permettent de trouver le juste équilibre pour hiérarchiser le chargement des ressources propriétaires et tierces. Une modification utile devient disponible en standard dans tous les navigateurs, mais cela prend du temps. Par exemple, l'attribut loading pour les éléments <img> et <iframe> est disponible dans Chrome/Edge depuis 2019, mais n'est disponible dans Safari que depuis 2022. Tant qu'une fonctionnalité n'est pas standardisée, les utilisateurs de ressources tierces devront s'assurer qu'elles sont également optimisées pour d'autres navigateurs. Nous vous aiderons à le faire en mettant en évidence ces points dans nos conseils, le cas échéant.

3. Pour mener à bien ce projet, nous devrons collaborer avec des partenaires et des développeurs pour nous aider à comprendre les exigences spécifiques, mais aussi pour tester des solutions expérimentales à grande échelle, nous faire part de leurs commentaires, itérer et improviser si nécessaire. Les modifications doivent être planifiées, en prévoyant un délai raisonnable pour les tests et l'évaluation.

Propositions de normes initiales

Nous avons effectué des tests initiaux pour développer des fonctionnalités pouvant être activées afin d'optimiser le processus de chargement tiers. Nous sommes satisfaits des résultats observés et pouvons actuellement discuter de deux de ces fonctionnalités.

LazyEmbeds

Chrome chargeait de manière différée les éléments <img> et <iframe> hors écran pour les utilisateurs du mode Lite. Cette fonctionnalité pourrait être étendue à tous les utilisateurs pour différer le chargement des éléments <iframe> identifiés comme étant des éléments intégrés tiers jusqu'à ce que l'utilisateur les approche en faisant défiler la page. Cela peut accélérer le chargement d'autres parties de la page, améliorer les Core Web Vitals, réduire l'utilisation de la mémoire et économiser des données.

Voici une démonstration utilisant LazyEmbeds pour charger de manière différée des vidéos YouTube sur une page. Une seule vidéo YouTube intégrée ajoute généralement 500 à 600 ko de code JavaScript à la page. Nous avons essayé d'optimiser un article de blog contenant 14 de ces vidéos intégrées à l'aide de LazyEmbeds. Les résultats étaient prometteurs en termes de temps de chargement des pages et d'économie de données.

Pour en savoir plus sur ce travail, consultez notre article explicatif et les fils de discussion "intent-to-experiment" et extension de test de blink-dev.

Limiter le débit des tiers ciblés

Les scripts tiers sont souvent ajoutés par différentes équipes sans processus de surveillance globale. L'équipe d'ingénieurs de The Telegraph a déclaré que "tout le monde veut "cette balise" sur une page qui rapportera de l'argent à l'organisation". Cela peut augmenter continuellement la charge de gestion de l'impact sur les performances.

Le débit ciblé des scripts tiers propose de limiter des types très spécifiques de tiers pour atténuer leur impact. Cela permettrait aux navigateurs de charger les contenus clés et les tiers essentiels plus tôt, tandis que les éléments pouvant être chargés plus tard sont limités.

Amélioration des API RUM

Nous envisageons également d'améliorer les API RUM pour inclure des informations utiles à l'évaluation des performances des tiers. Voici les améliorations apportées:

1. Rapports <iframe>: nous travaillons sur des solutions pouvant exploiter l'API Performance Timeline pour les rapports inter-frames. Cela permettrait aux auteurs de la page de niveau supérieur d'inspecter les données de performances d'une iframe tierce compatible intégrée à la page.

2. Attribution de tâches longues: l'API Long Tasks dans RUM aide les propriétaires de sites à identifier les tâches longues qui occupent le thread principal pendant une longue période et retardent l'interaction.

Autres informations

Nous testons encore de nombreuses idées de ce type et espérons publier des explications sur GitHub et des versions préliminaires de spécifications pour les modifications au fur et à mesure. Les tiers et les propriétaires de sites qui souhaitent collaborer avec nous ou nous faire part de leurs commentaires peuvent participer aux discussions via ces canaux. Les tiers peuvent également commencer à se concentrer sur l'optimisation pour les métriques Core Web Vitals et INP afin de s'assurer que les données Core Web Vitals/INP de mauvaise qualité ne leur sont pas attribuées. Pour le moment, ceux qui recherchent activement des informations peuvent consulter les posts du groupe blink-dev.

Nous avons hâte d'explorer davantage ce champ de problèmes et de partager nos enseignements avec la communauté.

Remerciements particuliers à Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara et Alex N. Jose, Melissa Mitchell, Yoav Weiss, Shunya Shishido et Minoru Chikamune pour leurs commentaires et leurs contributions.