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 Chrome. Dans le cadre de mon travail, je travaille avec une équipe de passionnés du Web qui sont chargés d'apporter la perspective de développeurs réels à nos équipes produit et d'ingénierie, avec une métrique de référence visant à améliorer la satisfaction des développeurs.

Nous sommes conscients que la satisfaction est une métrique ambitieuse et subjective qu'il faut suivre et améliorer. C'est pourquoi nous repensons constamment comment nous pouvons avoir un impact, tout en nous concentrant sur les besoins des développeurs. L'un des principes directeurs que nous avons trouvé utile à suivre est le suivant : "S'adapter aux développeurs". Une étude récente de Stack Overflow a montré que 75% des développeurs déclarent utiliser des frameworks ou une abstraction. Nous nous sommes demandé comment mieux servir les développeurs qui ont déjà pris des décisions concernant leur pile technologique ou qui n'ont aucun contrôle sur celle-ci. Comment accroître leur productivité sans augmenter les frais généraux ?

Une petite équipe de Chrome travaille sur un projet appelé Aurora, dont le but est 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 les performances directement dans ces abstractions, au lieu de laisser la charge sur 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, membres de l'équipe Project Aurora, pour en savoir plus sur leur approche de ce projet et sur ce qui les attend.

Scoop d'initié: collaboration avec des frameworks tiers

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

Addy:Aurora a commencé par une idée simple: rencontrons les développeurs là où ils en sont et les aidons à atteindre leurs objectifs. Par exemple, aidez la pile technologique populaire qu'ils ont choisie pour améliorer les performances. Aujourd'hui, de nombreux développeurs d'applications créent des applications à l'aide de React, Vue ou Angular, ou de méta-frameworks* comme Next.js et Nuxt (et bien d'autres encore... Svelte, Lit, Preact, Astro. La liste est longue !). Plutôt que d'attendre que ces développeurs deviennent des experts approfondis (par exemple, dans le domaine des performances), nous pourrions nous assurer qu'ils tombent dans un creux de réussite en intégrant par défaut davantage de bonnes pratiques à ces piles. De cette façon, le simple fait de développer des sites de meilleure qualité est le résultat d'un simple développement pour le Web.

Aurora choisit quelques frameworks et méta-cadres largement utilisés avec lesquels collaborer, nous documentons nos enseignements (comme la création d'un bon composant image), afin que d'autres puissent suivre rapidement et essayer de mettre à l'échelle via d'autres frameworks et outils grâce au fonds Chrome Framework. Même s'il est 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) à l'aide de frameworks. Nous espérons que ces informations nous aideront à atteindre nos objectifs : offrir un Web de meilleure qualité à tous.

Kara:En outre, l'idée est d'améliorer les performances sur le Web en optimisant l'expérience des développeurs. Il ne suffit pas de publier les bonnes pratiques en matière de performances, car elles changent souvent et il est difficile pour les entreprises de les suivre. Elles ont leurs propres priorités commerciales, qui prévaudront probablement sur les performances.

Nous pensons donc que si les développeurs n'ont que peu de temps à consacrer aux performances, nous pouvons leur permettre de créer plus facilement (et plus rapidement) une application performante. Si nous collaborons avec des frameworks Web populaires, nous sommes à la bonne couche d'abstraction pour améliorer l'expérience des développeurs grâce à des composants de niveau supérieur, des avertissements de conformité, etc. Toute personne utilisant ces outils populaires aura accès à ces avantages. En théorie, si les conseils recommandés changent, nous pouvons mettre à jour nos composants en arrière-plan et les développeurs n'ont pas à se soucier de rester à jour.

Houssein:J'ai rejoint Google en tant que Developer Advocate avant d'occuper 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 de ces conseils ont été proposées à maintes 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é si nous pourrions ne jamais avoir à dire aux développeurs ce qu'ils doivent faire, car leur chaîne d'outils s'occupe de tout à leur place.

Si je comprends bien, vous formez une équipe de six ingénieurs. Je parie que vous ne pouvez pas travailler avec tous les frameworks ou bibliothèques possibles. Alors, comment choisir avec qui travailler ? Et qui sont-ils ?

Addy:le Web ressemble, à bien des égards, au 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 mauvaises performances. L'un des meilleurs moyens d'améliorer les performances est de s'assurer que ces couches se sentent à l'aise pour exprimer une opinion publique.

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

Il s'agit également d'un bon moyen de déterminer où les bonnes pratiques modernes fonctionnent ou si vous devez les repenser, et d'orienter l'ensemble de l'écosystème sur la façon d'aborder les problèmes d'optimisation.

Kara:En réalité, nous devons aussi prendre en compte la popularité. Si nous voulons avoir le plus grand impact possible sur le Web, l'idéal est de travailler avec des frameworks et des bibliothèques qui bénéficient d'une vaste communauté de développeurs. De cette façon, nous pouvons toucher davantage de développeurs et d'applications. Mais il ne peut pas s'agir seulement de la popularité. En fin de compte, il s'agit d'un croisement entre la popularité, le degré d'opinion d'une bibliothèque et l'ensemble des fonctionnalités disponibles.

Par exemple, si nous nous basons uniquement sur la popularité, nous devons prendre en compte React, Vue et Angular. Mais c'est principalement avec 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'y intégrer directement toutes les fonctionnalités que nous souhaitons y intégrer. Nous travaillons donc plus étroitement avec des méta-frameworks avisés basés sur ceux-ci: Next.js et Nuxt. À ce niveau d'abstraction, nous pouvons créer des composants intégrés. Ils disposent également de serveurs intégrés, ce qui nous permet d'intégrer des optimisations côté serveur.

Vous avez peut-être remarqué qu'Angular figurait dans cette liste de partenariats profonds, mais il ne s'agit pas d'un méta-framework. Angular est un cas particulier, car il est très populaire, mais ne dispose pas d'un méta-framework complémentaire à celui de React et Vue. Nous travaillons donc directement avec eux et, dans la mesure du possible, nous proposons des fonctionnalités via leur CLI.

Il convient de noter que nous entretenons plusieurs relations continues avec d'autres projets comme Gatsby, où nous nous synchronisons assez régulièrement sur la conception sans contribuer activement au codage.

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

Kara:Dans la pratique, nous collaborons étroitement avec quelques frameworks. Nous allons prendre le temps de profiler les applications à l'aide de ce framework et d'identifier les principales difficultés liées aux performances. Ensuite, nous travaillons avec l'équipe chargée du framework pour concevoir des fonctionnalités expérimentales afin de résoudre ces problèmes et pour contribuer directement au code dans le dépôt OSS afin de les implémenter.

Il est très important pour nous de vérifier que l'impact sur les performances correspond à ce que nous avions prévu. C'est pourquoi nous travaillons également avec des entreprises externes pour effectuer des tests de performance en production. Si les résultats sont encourageants, nous aiderons la fonctionnalité à passer à la version "stable" et nous la définirons peut-être comme valeur par défaut.

Tout cela n'est pas aussi simple qu'il en a l'air. Quels sont les défis ou leçons que vous avez rencontrés jusqu'à présent ?

Houssein:Nous essayons d'exploiter au mieux nos capacités à la création de dépôts Open Source populaires qui ont de nombreuses priorités concurrentes. Ce n'est pas parce que nous sommes une équipe Google que nous donnons la priorité à nos fonctionnalités. Nous faisons donc tout notre possible pour nous aligner sur le processus habituel de proposition et de déploiement de nouvelles fonctionnalités, sans intervenir. Nous avons eu la chance de collaborer avec des responsables réceptifs des écosystèmes Next.js, Nuxt et Angular. Nous leur sommes reconnaissants d'avoir été prêts à écouter nos préoccupations à propos de l'écosystème Web et à collaborer avec nous de différentes manières.

Avec la plupart des frameworks avec lesquels nous travaillons, notre mission globale est la même : comment les développeurs peuvent-ils obtenir une expérience utilisateur améliorée dès la première utilisation tout en profitant d'une expérience de qualité ? Nous sommes conscients qu'il existe des centaines, voire des milliers de contributeurs de la communauté et de mainteneurs du framework qui travaillent chacun sur des projets différents qui s'entrecroisent.

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 sommes en territoire inconnu. Par conséquent, nous testons parfois une optimisation qui n'aboutit pas et nous n'élaborons pas toujours une fonctionnalité planifiée. Même lorsqu'une fonctionnalité se déploie, ces quelques étapes supplémentaires pour vérifier les performances prennent du temps et prolongent les délais.

Il peut également s'avérer difficile de trouver des partenaires en production pour tester nos fonctionnalités. Comme mentionné précédemment, ce sont des entreprises qui ont leurs propres priorités. Il peut donc être difficile pour elles de s'inscrire dans de nouvelles initiatives si elles ne s'alignent pas bien sur des projets existants qui doivent être prioritaires. De plus, les entreprises qui souhaitent le faire sont généralement celles qui prennent déjà le temps d'investir dans les performances. Elles ne constituent donc pas notre audience cible. Nous essayons de recueillir les commentaires d'un large éventail de membres de la communauté qui ne peuvent pas investir dans les performances, mais qui sont les moins susceptibles de nous contacter.

Continuons, sur quels types d'optimisations avez-vous concentré votre attention ?

Houssein:Après avoir analysé des milliers d'applications, nous avons constaté que les principaux problèmes de performances sont généralement dus aux antimodèles du code de l'application plutôt que du framework lui-même. Par exemple, expédier des images inutilement volumineuses, charger des polices personnalisées trop tard, récupérer trop de requêtes tierces qui bloquent le thread principal, et ne pas gérer la façon dont le contenu asynchrone peut entraîner le décalage d'autres éléments sur la page. Tous ces problèmes peuvent survenir quel que soit l'outil que vous utilisez, et nous avons donc pensé que vous pourriez intégrer des optimisations par défaut qui les gèrent correctement, mais avec une expérience de développement agréable qui s'intègre parfaitement aux outils de leur framework.

Dans cette optique, nous avons lancé:

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

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

Houssein:Les performances de nombreux sites s'améliorent grâce aux optimisations que nous avons déployées. L'un de mes exemples préférés est Leboncoin, qui a réduit son LCP de 2,4 à 1,7 s après être passé au composant d'image Next.js. De nombreux autres sont actuellement en phase d'expérimentation et de test. Nous continuerons à partager les enseignements et bénéfices qu'ils ont tirés de ceux-ci sur cette page.

D'accord. Je comprends que vous vous concentrez sur ceux qui sont les plus populaires, mais y a-t-il des moyens dont d'autres frameworks ou bibliothèques avec lesquels vous ne travaillez pas de manière proactive peuvent également profiter ?

Ajoutée:de nombreuses optimisations de performances sur lesquelles Aurora collabore peuvent être répliquées par n'importe quel framework. Examinez, par exemple, nos efforts en matière de composants Image ou Script. Ils codifient souvent un ensemble de bonnes pratiques. Nous essayons de documenter le "comment" de la création de ces composants et à quoi ils ressemblent dans chaque framework. J'espère que c'est un bon début pour copier l'idée.

Nous avons observé de bonnes performances en utilisant les enseignements tirés d'un écosystème (par exemple, React et Next.js) pour les transmettre à d'autres. Par exemple, la nouvelle directive sur les images Angular (basée sur les enseignements tirés de la création du composant Image Next.js) ou Gatsby a mis en œuvre notre approche de la fragmentation JavaScript précise.

Parallèlement, nous sommes conscients que tous les frameworks n'offriront pas suffisamment de bande passante ni de financement pour que les contributeurs puissent développer des fonctionnalités de performances similaires ou investir dans d'autres optimisations qu'ils estiment importantes pour leurs utilisateurs. Le Chrome Web Frameworks Fund nous permet de sponsoriser des projets axés sur les performances dans l'écosystème JavaScript afin de permettre aux projets de payer leurs contributeurs et de permettre l'expansion des travaux liés aux performances dans l'écosystème.

Quelle est la feuille de route de votre équipe ?

Kara: Nous avons de nombreux projets passionnants à venir ! 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 envisageons d'utiliser des remplacements de métriques de police et la propriété "size-adjust" pour réduire le CLS lié à la police par défaut dans Next.js. Nous avons également consulté l'équipe Nuxt à ce sujet et nous prévoyons d'étendre cette idée à d'autres cadres l'année prochaine.
  • Débogage INP:maintenant que la métrique Interaction to Next Paint (INP) est disponible, nous travaillons avec des frameworks pour identifier les causes les plus courantes des problèmes INP dans leurs communautés et suggérer des solutions. Nous travaillons en étroite collaboration avec Angular sur ce sujet et espérons vous communiquer très prochainement les résultats.
  • Optimiser les scripts tiers courants:charger des scripts tiers au mauvais moment peut avoir un impact négatif important sur les performances. Étant donné que quelques tiers sont très courants, nous cherchons à déterminer si nous pouvons proposer des wrappers pour ceux-ci afin de nous assurer qu'ils sont chargés de manière optimale avec des frameworks et ne bloquent pas le thread principal. Nous utilisons le composant de script Next.js que nous avons créé comme point de départ de cette investigation.

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

Actualités

Avant de terminer, je voudrais vous faire part de quelques informations intéressantes sur l'univers des frameworks Google.

En juillet, l'équipe Chrome a annoncé la dernière série de financements de 500 000 $pour le fonds Frameworks et outils, qui se concentre sur le financement de projets visant à améliorer les performances et l'expérience utilisateur ainsi que l'expérience des développeurs sur le Web. Les futurs projets prendront en compte les nouveaux projets. N'oubliez donc pas d'envoyer votre demande.

Bien sûr, il y a aussi de très nombreuses choses incroyables qui se passent dans la communauté. L'écosystème est mûr avec de nouveaux frameworks tels que Fresh de Deno, et des expériences géniales comme le tutoriel de prise en main de Svelte, qui est non seulement une démo intégrée au navigateur, mais qui utilise également l'API Web Container pour exécuter Node.js en natif dans ce navigateur. Tant de choses intéressantes !

Je suis très enthousiaste à l'idée de voir l'écosystème se mettre en place, repousser les limites du possible dans le navigateur et aider les développeurs à créer des produits qui conviennent à tous. Nous entrons dans une période passionnante pour les développeurs Web.

À bientôt au prochain Insider.

Qu'avez-vous pensé de cette édition de The Chrome Dev Insider ? Donnez-nous votre avis.