Chrome Dev Insider: Adapter les performances grâce à l'écosystème de frameworks

Paul Kinlan

Je m'appelle Paul Kinlan et je suis responsable des relations avec les développeurs pour Chrome. Dans le cadre de mon travail, je collabore avec une équipe de passionnés du Web qui ont pour mission de présenter le point de vue des développeurs du monde réel à nos équipes produit et d'ingénierie, avec pour objectif principal d'améliorer la satisfaction des développeurs.

Nous sommes conscients que la "satisfaction" est une métrique ambitieuse et subjective à suivre et à améliorer. Nous itérons donc constamment sur la façon dont nous pouvons avoir un impact tout en nous concentrant sur les besoins des développeurs. Nous avons suivi un principe directeur qui nous a semblé utile : rencontrer les développeurs là où ils se trouvent. Une étude récente de Stack Overflow a révélé que 75% des développeurs déclarent utiliser des frameworks ou une forme d'abstraction. Nous nous sommes donc demandé comment mieux servir les développeurs qui ont déjà pris des décisions concernant leur stack technologique ou qui n'ont aucun contrôle sur celle-ci. Comment les rendre plus productifs sans augmenter les coûts ?

Une petite équipe de Chrome a travaillé sur un projet appelé Aurora, dans le but de travailler avec des abstractions tierces de la plate-forme Web telles que des frameworks et des bibliothèques. Leur objectif est d'améliorer directement les performances de ces abstractions, au lieu de laisser cette tâche à leurs clients (les développeurs Web).

Pour la troisième édition de Chrome Dev Insider, j'ai discuté avec Addy Osmani, Kara Erickson et Houssein Djirdeh de l'équipe du projet Aurora pour en savoir plus sur la façon dont ils ont abordé ce projet et sur ce qui les attend.

Infos exclusives: Travailler avec des frameworks tiers

Commençons par la genèse de ce projet. Comment est-il né ?

Addy:Aurora est née d'une idée simple: rencontrer les développeurs là où ils en sont et les aider à atteindre leurs objectifs. Par exemple, améliorer les performances de la pile technologique populaire qu'ils ont choisie. De nos jours, de nombreux développeurs d'applications utilisent React, Vue ou Angular, ou des méta-frameworks* tels que Next.js et Nuxt (et bien d'autres, bien sûr). Svelte, Lit, Preact, Astro. La liste est longue. Plutôt que d'attendre de ces développeurs qu'ils deviennent des experts (par exemple, en termes de performances), nous pouvons nous assurer qu'ils réussissent en implémentant davantage de bonnes pratiques par défaut dans ces piles. Ainsi, les sites de meilleure qualité sont un effet secondaire de la création pour le Web.

Aurora choisit quelques frameworks et méta-frameworks largement utilisés avec lesquels collaborer. Nous documentons nos enseignements (par exemple, comment créer un bon composant d'image) afin que d'autres puissent suivre rapidement et essayer de faire évoluer leurs projets via d'autres frameworks et outils grâce au fonds Chrome Frameworks. Bien qu'il soit possible d'améliorer la qualité des expériences Web via le navigateur, nous pensons que cet objectif peut également être atteint (dans certains cas) via des frameworks. Nous espérons que cela nous aidera à atteindre notre objectif d'un Web de meilleure qualité pour tous.

Kara:Pour en savoir plus, l'idée est d'améliorer les performances sur le Web en améliorant l'expérience des développeurs. Il ne suffit pas de diffuser les bonnes pratiques en matière de performances, car elles changent souvent et il est difficile pour les entreprises de s'y tenir. Ils ont leurs propres priorités commerciales qui sont probablement prioritaires par rapport aux performances.

Nous pensons donc que si les développeurs ont un temps limité à consacrer aux performances, nous devons leur permettre de créer une application performante plus facilement (et plus rapidement). En collaborant avec des frameworks Web populaires, nous nous trouvons au bon niveau d'abstraction pour améliorer l'expérience des développeurs grâce à des composants de niveau supérieur, des avertissements de conformité, etc. Tous ceux qui utilisent ces outils populaires auront accès à ces avantages. En théorie, si les conseils recommandés changent, nous pouvons mettre à jour nos composants en interne, et les développeurs n'ont pas à se soucier de rester à jour.

Houssein:J'ai rejoint Google en tant que développeur advocate avant de passer à un poste d'ingénieur logiciel quelques années plus tard. Une grande partie de mon travail précédent consistait à enseigner aux développeurs Web les nombreuses façons de créer des expériences utilisateur de qualité. Des variantes des mêmes conseils ont été fournies à plusieurs reprises pour avertir les développeurs des problèmes courants susceptibles d'affecter les performances et la facilité d'utilisation de leurs sites. Lorsque nous avons commencé à réfléchir au projet Aurora, nous nous sommes demandés: pouvons-nous envisager de ne jamais avoir à dire aux développeurs ce qu'ils doivent faire, car leur chaîne d'outils s'en occupe pour eux ?

Si je comprends bien, votre équipe compte six ingénieurs. Je parie que vous ne pouvez pas travailler avec tous les frameworks ou bibliothèques possibles. Comment choisir avec qui travailler ? Qui sont-ils ?

Addy:Le Web est à bien des égards comme le Far West. Vous pouvez choisir à peu près n'importe quel framework, bundler, bibliothèques et tiers. Cela introduit plusieurs niveaux de complexité qui peuvent contribuer à de bonnes ou de mauvaises performances. L'un des meilleurs moyens d'améliorer les performances consiste à trouver des couches qui s'expriment avec conviction et à en ajouter d'autres.

Par exemple, les frameworks Web (Next.js, Nuxt.js et, dans une certaine mesure, Angular) tentent d'intégrer davantage d'opinions et de valeurs par défaut qu'une solution plus manuelle. C'est l'une des raisons pour lesquelles nous aimons travailler avec eux. Dans ces modèles, il est logique d'avoir des valeurs par défaut plus strictes pour le chargement des images, des polices et des scripts afin d'améliorer les métriques Core Web Vitals.

Il permet également de confirmer dans quels cas les bonnes pratiques modernes fonctionnent ou doivent être repensées, et peut aider l'ensemble de l'écosystème à trouver des solutions aux problèmes d'optimisation.

Kara:Réaliste, nous devons aussi tenir compte de la popularité. Pour avoir le plus d'impact possible sur le Web, il est idéal de travailler avec des frameworks et des bibliothèques qui disposent d'une grande communauté de développeurs. Nous pouvons ainsi toucher plus de développeurs et plus d'applications. Mais il ne s'agit pas seulement de popularité. En fin de compte, il s'agit d'un croisement entre la popularité, le caractère orienté d'une bibliothèque et l'ensemble de fonctionnalités disponibles avec lequel nous pouvons travailler.

Par exemple, si nous nous limitons à la popularité, React, Vue et Angular sont les trois principaux frameworks à prendre en compte. Mais nous utilisons principalement Next.js, Nuxt et Angular. En effet, les bibliothèques de vues telles que React et Vue se concentrent principalement sur le rendu. Il est donc impossible d'intégrer directement toutes les fonctionnalités souhaitées. Nous collaborons donc plus étroitement avec les méta-frameworks basés sur eux: Next.js et Nuxt. À ce niveau d'abstraction, nous pouvons créer des composants intégrés. Elles disposent également de serveurs intégrés, ce qui nous permet d'inclure des optimisations côté serveur.

Vous remarquerez qu'Angular figurait dans cette liste de partenariats profonds, mais qu'il ne s'agit pas d'un métaframework. Angular est un cas particulier, car il est très populaire, mais ne dispose pas de métaframework complémentaire comme React et Vue. Nous collaborons donc directement avec eux et contribuons à des fonctionnalités via leur CLI lorsque cela est possible.

Il est également intéressant de noter que nous entretenons plusieurs relations en cours avec d'autres projets, comme Gatsby, avec lesquels nous nous synchronisons régulièrement sur la conception, mais sans contribuer activement au code.

À quoi cela ressemble-t-il en pratique ? Quelle a été votre approche pour résoudre ce problème ?

Kara:En pratique, nous collaborons étroitement avec quelques frameworks. Nous allons prendre le temps de profiler des applications utilisant ce framework et d'identifier les problèmes de performances courants. Nous collaborons ensuite avec l'équipe du framework pour concevoir des fonctionnalités expérimentales afin de résoudre ces difficultés et nous contribuons au code directement dans le dépôt Open Source pour les implémenter.

Il est très important pour nous de vérifier que l'impact sur les performances est celui que nous avons prévu. Nous collaborons donc également avec des entreprises externes pour effectuer des tests de performances en production. Si les résultats sont encourageants, nous ferons en sorte que la fonctionnalité devienne stable et, éventuellement, qu'elle soit proposée par défaut.

Tout cela ne peut pas être aussi simple que vous le prétendez. Quels ont été les défis ou les apprentissages que vous avez rencontrés jusqu'à présent ?

Houssein:Nous essayons de contribuer au mieux de nos capacités à des dépôts Open Source populaires qui ont de nombreuses priorités concurrentes. Le fait que nous fassions partie de l'équipe Google ne signifie pas nécessairement que nos fonctionnalités seront prioritaires. Nous faisons de notre mieux pour nous conformer au processus habituel de proposition et de lancement de nouvelles fonctionnalités sans déranger personne. Nous avons eu la chance de travailler avec des mainteneurs réceptifs dans les écosystèmes Next.js, Nuxt et Angular. Nous sommes reconnaissants qu'ils aient été prêts à écouter nos préoccupations concernant l'écosystème Web et à collaborer avec nous de différentes manières.

Notre mission globale est la même pour de nombreux frameworks avec lesquels nous travaillons : comment les développeurs peuvent-ils bénéficier d'une expérience utilisateur améliorée dès le départ tout en profitant d'une expérience de développement de qualité ? Nous sommes conscients et respectueux du fait qu'il existe des centaines, voire des milliers de contributeurs et de responsables de framework qui travaillent chacun sur différents projets qui se croisent.

Kara:De plus, comme nous nous soucions de valider l'impact sur les performances et d'agir en fonction des données, le processus prend un peu plus de temps. Nous nous trouvons sur un territoire inexploré. Il arrive donc que nous testions une optimisation qui ne fonctionne pas et que nous n'arrivions pas à créer une fonctionnalité prévue. Même si une fonctionnalité est efficace, les quelques étapes supplémentaires nécessaires pour évaluer ses performances prennent du temps et retardent les délais.

Trouver des partenaires de production pour tester nos fonctionnalités peut également s'avérer difficile. Comme indiqué précédemment, il s'agit d'entreprises qui ont leurs propres priorités. Il peut donc être difficile pour elles d'intégrer de nouvelles initiatives si elles ne correspondent pas bien aux projets existants, qui doivent passer en premier. De plus, les entreprises les plus intéressées à être aidées ont déjà tendance à investir dans les performances. Elles ne constituent donc pas vraiment notre audience cible. Nous essayons de recueillir les commentaires de la grande majorité de la communauté qui ne peut pas investir dans les performances, mais ce sont les utilisateurs les moins susceptibles de nous contacter.

Passons aux optimisations. Sur quoi vous êtes-vous concentré ?

Houssein:Après avoir analysé des milliers d'applications, nous avons constaté que les plus gros problèmes de performances sont généralement dus à des anti-modèles dans le code de l'application plutôt qu'au framework lui-même. Par exemple, en envoyant des images inutilement volumineuses, en chargeant des polices personnalisées trop tard, en extrayant trop de requêtes tierces qui bloquent le thread principal et en ne gérant pas la façon dont le contenu asynchrone peut entraîner le déplacement d'autres éléments sur la page. Tous ces problèmes peuvent survenir quel que soit l'outil que vous utilisez. Nous nous sommes donc demandés si nous pouvions intégrer des optimisations par défaut qui les gèrent bien, mais avec une expérience de développement agréable qui s'intègre parfaitement à l'outil de framework.

C'est pourquoi nous avons lancé:

Notre travail a inspiré d'autres frameworks et outils à implémenter des optimisations similaires. Cela inclut, sans s'y limiter :

Pouvez-vous nous donner des exemples de résultats positifs de votre travail avec certains de ces acteurs ?

Houssein:De nombreux sites ont vu leurs performances s'améliorer grâce aux optimisations que nous avons apportées. L'un de mes exemples préférés est Leboncoin, qui a réduit son LCP de 2,4 s à 1,7 s après avoir passé au composant Image Next.js. De nombreux autres tests sont actuellement en cours, et nous continuerons de partager les enseignements et les résultats obtenus sur cette page.

Je comprends que vous vous concentrez sur les plus populaires, mais existe-t-il des moyens d'en faire profiter d'autres frameworks ou bibliothèques avec lesquels vous ne travaillez pas de manière proactive ?

Addy:de nombreuses optimisations des performances sur lesquelles Aurora collabore peuvent être reproduites par n'importe quel framework. Prenons l'exemple de nos efforts concernant les composants Image ou Script. Ils codifient souvent un ensemble existant de bonnes pratiques. Nous essayons de documenter la façon de créer ces composants et leur apparence dans chaque framework. J'espère que cela vous aidera à copier l'idée.

Nous avons constaté que nous pouvions tirer des enseignements d'un écosystème (React et Next.js, par exemple) et les appliquer à d'autres. Par exemple, la nouvelle directive Image Angular (basée sur nos enseignements lors de la création du composant Image Next.js) ou Gatsby qui propose notre approche de segmentation JavaScript précise.

En même temps, nous comprenons que tous les frameworks ne disposent pas de la bande passante ni des fonds nécessaires pour que les contributeurs puissent développer des fonctionnalités de performances similaires ou investir dans d'autres optimisations qu'ils pensent être importantes pour leurs utilisateurs. Le Fonds Chrome Web Frameworks nous permet de sponsoriser les travaux de performances dans l'écosystème JavaScript afin de permettre aux projets de rémunérer leurs contributeurs et de développer davantage les travaux de performances dans l'écosystème.

Quels sont les projets à venir pour votre équipe ?

Kara:De nombreux projets passionnants nous attendent ! Voici quelques points à retenir :

  • Réduire le CLS lié aux polices:il est assez courant de constater des décalages de mise en page lorsqu'une police Web est chargée et remplace la police de remplacement. Nous étudions l'utilisation de forçages de métriques de police et de la propriété "size-adjust" pour réduire le CLS lié aux polices par défaut dans Next.js. Nous avons également consulté l'équipe Nuxt à ce sujet et prévoyons d'étendre cette idée à d'autres frameworks l'année prochaine.
  • Débogage de l'INP:maintenant que la métrique Interaction to Next Paint (INP) est disponible, nous collaborons avec des frameworks pour identifier les causes les plus courantes des problèmes d'INP dans leurs communautés et suggérer des solutions. Nous collaborons étroitement avec Angular à ce sujet et espérons pouvoir vous communiquer des résultats prochainement.
  • Optimisation des scripts tiers courants:le chargement de scripts tiers au mauvais moment peut avoir un impact négatif important sur les performances. Étant donné que certains tiers sont très courants, nous étudions la possibilité de proposer des wrappers pour nous assurer qu'ils sont chargés de manière optimale avec les frameworks et qu'ils ne bloquent pas le thread principal. Nous utilisons le composant de script Next.js que nous avons créé comme point de départ pour cette investigation.

Les développeurs peuvent suivre notre progression sur ce site.

Lieu à la une

Avant de vous quitter, je voulais vous donner quelques informations intéressantes sur les frameworks au sein de Google.

En juillet, l'équipe Chrome a annoncé la dernière levée de fonds de 500 000 $pour le Fonds pour les frameworks et les outils, qui vise à financer des projets visant à améliorer les performances, l'expérience utilisateur et l'expérience des développeurs sur le Web. De nouveaux projets seront pris en compte pour les futurs financements. N'oubliez pas d'envoyer votre demande.

Et, bien sûr, la communauté est le théâtre de TOUTES sortes de choses incroyables. L'écosystème regorge de nouveaux frameworks comme Fresh de Deno et d'expériences exceptionnelles comme le tutoriel d'intégration de Svelte, qui n'est pas seulement une démonstration dans le navigateur, mais qui utilise également l'API Web Container pour exécuter Node.js de manière native dans le navigateur. Tellement de bonnes choses !

Je suis vraiment ravi de voir l'écosystème se développer, de repousser les limites du navigateur et d'aider les développeurs à créer des produits qui fonctionnent pour tous. C'est une période passionnante pour être développeur Web.

À la prochaine, Hwyl fawr.

Qu'avez-vous pensé de cette édition de The Chrome Dev Insider ? Envoyez-nous vos commentaires.