Comment comparer et améliorer les éléments vitaux Web avec des métriques utilisateur réelles

Cet article a été aimablement soutenu par nos chers amis de Raygun qui aident les développeurs à identifier les problèmes avant que leurs clients ne soient impactés, offrant le niveau d'expérience que les utilisateurs attendent et méritent. Merci!

Comment mesureriez-vous les performances ? Parfois, il s'agit du temps qu'une application prend entre la demande initiale et le rendu complet. D'autres fois, il s'agit de la vitesse à laquelle une tâche est exécutée. Il peut également s'agir du temps qu'il faut à l'utilisateur pour obtenir des commentaires sur une action. Rassurez-vous, toutes ces définitions (et d'autres) seraient correctes, à condition d'être dans le bon contexte.

Malheureusement, il n'y a pas de solution miracle pour mesurer les performances. Différents produits auront des références différentes et deux applications peuvent fonctionner différemment par rapport aux mêmes mesures, mais se classent toujours de manière assez similaire à nos verdicts subjectifs « bon » et « mauvais ».

Dans un effort de rationalisation du langage et de promotion de la collaboration et de la normalisation, notre industrie a mis au point des concepts répandus. De cette façon, les développeurs sont capables de partager des solutions, de définir des priorités et de se concentrer sur l'exécution efficace du travail.

Performances vs performances perçues

Prenez cet extrait comme exemple :

 const sum = new Array(1000) .fill(0) .map((el, idx) => el + idx) .reduce((sum, el) => sum + el, 0) console.log(sum)

Le but de ceci n'est pas important, et cela ne fait rien d'autre que de prendre un temps considérable pour sortir un nombre sur la console. Face à ce code, on dirait (à juste titre) qu'il ne fonctionne pas bien. Ce n'est pas un code rapide à exécuter, et il pourrait être optimisé avec différents types de boucles, ou effectuer ces tâches dans une seule boucle.

Une autre chose importante est qu'il a le potentiel de bloquer le rendu d'une page Web. Il gèle (ou peut-être même plante) l'onglet de votre navigateur. Ainsi, dans ce cas, la performance perçue par l'utilisateur va de pair avec la performance de la tâche elle-même.

Cependant, nous pouvons exécuter cette tâche dans un web worker. En empêchant le blocage du rendu, notre tâche ne s'exécutera pas plus rapidement - on pourrait donc dire que les performances sont toujours les mêmes - mais l'utilisateur pourra toujours interagir avec notre application et recevoir des commentaires appropriés. Cela a un impact sur la rapidité avec laquelle notre utilisateur final percevra notre application. Ce n'est pas plus rapide, mais il a de meilleures performances perçues .

Note : N'hésitez pas à explorer ma preuve de concept react-web-workers sur GitHub si vous souhaitez en savoir plus sur Web-Workers et React.

Web Vitals

Les performances Web sont un vaste sujet avec des milliers de mesures que vous pourriez potentiellement surveiller et améliorer. Web Vitals est la réponse de Google à la standardisation des performances Web. Cette standardisation permet aux développeurs de se concentrer sur les mesures qui ont le plus d'impact sur l'expérience de l'utilisateur final.

• Première peinture de contenu (FCP)
  Le temps entre le début du chargement et le rendu du contenu à l'écran.
• La plus grande peinture de contenu (LCP)
  Le temps de rendu de l'image ou du bloc de texte le plus grand est visible dans la fenêtre d'affichage. Un bon score est inférieur à 2,5s pour 75% des chargements de page.
• Premier délai d'entrée (FID)
  Le temps entre le moment où l'utilisateur interagit avec la page et le moment où le navigateur est capable de traiter la demande.
  Un bon score est inférieur à 100 ms pour 75 % des chargements de page.
• Décalage de mise en page cumulé (CLS)
  La somme totale de tous les changements de mise en page individuels pour chaque changement inattendu qui se produit dans la durée de vie de la page. Un bon score est de 0,1 sur 75 % des chargements de page.
• Temps d'interactivité (TTI)
  Le temps entre le moment où la page commence à se charger et le moment où ses sous-ressources principales ont été chargées.
• Temps de blocage total (TBT)
  Le temps entre First Contentful Paint et Time to Interactive où le thread principal a été bloqué (aucune réactivité à l'entrée de l'utilisateur).

Lequel d'entre eux est le plus important ?

Les Core Web Vitals sont le sous-ensemble de Web Vitals que Google a identifié comme ayant le plus grand impact sur l'expérience de l'utilisateur final. À partir de 2022, il existe trois Core Web Vitals - Largest Contentful Paint (vitesse), Cumulative Layout Shift (stabilité) et First Input Delay (interactivité).

Lecture recommandée : Guide du développeur pour Core Web Vitals

Rapport sur l'expérience utilisateur de Chrome par rapport aux métriques de l'utilisateur réel

Il existe plusieurs façons de tester Web Vitals sur votre application. Le plus simple consiste à ouvrir vos outils de développement Chrome, à accéder à l'onglet Phare, à vérifier vos préférences et à générer un rapport. C'est ce qu'on appelle un rapport d'expérience utilisateur Chrome (CrUX) , et il est basé sur une moyenne de 28 jours d'échantillons d'utilisateurs Chrome qui répondent à certaines exigences :

• synchronisation de l'historique de navigation ;
• pas de configuration de la phrase secrète de synchronisation ;
• rapport de statistiques d'utilisation activé.

Mais il est assez difficile de définir à quel point le rapport Chrome UX est représentatif de vos propres utilisateurs. Le rapport sert de fourchette approximative et peut offrir un bon indicateur des choses à améliorer de manière ponctuelle. C'est pourquoi c'est une très bonne idée d'utiliser un outil de Real User Monitoring (RUM), comme Raygun. Cela rendra compte des personnes qui interagissent réellement avec votre application, sur tous les navigateurs, dans un délai imparti.

Cependant, surveiller vous-même les métriques des utilisateurs réels n'est pas une tâche simple. Il y a une pléthore d'obstacles à connaître. Cependant, cela ne doit pas être compliqué. Il est facile de se mettre en place pour obtenir des métriques RUM avec des outils de surveillance des performances. L'une des options à considérer est Raygun - il peut être configuré en quelques étapes rapides et est compatible avec le RGPD. De plus, vous bénéficiez également de nombreuses fonctionnalités de rapport d'erreurs.

Surveillance des applications

Les développeurs traitent souvent l'observabilité et la surveillance des performances comme une réflexion après coup. Cependant, la surveillance est un aspect crucial du cycle de vie du développement qui aide les équipes logicielles à progresser plus rapidement, à hiérarchiser les efforts et à éviter les problèmes graves en cours de route.

La configuration de la surveillance peut être simple, et la création de fonctionnalités qui tiennent compte de l'observabilité aidera l'équipe à effectuer la maintenance de base et l'hygiène du code pour éviter ces épouvantables sprints de refactorisation. La surveillance des applications peut vous aider à dormir paisiblement la nuit et guider votre équipe vers la création de meilleures expériences utilisateur.

Surveillez les tendances et évitez les régressions

De la même manière, nous avons des tests en cours d'exécution sur notre pipeline d'intégration continue (idéalement) pour éviter les régressions de fonctionnalités et les bogues, nous devrions avoir un moyen d'identifier les régressions de performances pour nos utilisateurs immédiatement après un nouveau déploiement. Raygun peut aider les développeurs à automatiser ce travail grâce à leur fonction de suivi du déploiement.

Le respect du budget de performance devient plus durable. Grâce à ces informations, votre équipe peut rapidement repérer les régressions (ou améliorations) des performances sur tous les Web Vitals, identifier les déploiements problématiques et se concentrer sur les utilisateurs concernés.

Explorez et passez à l'action

Lors de l'utilisation de RUM, il est possible d'affiner les résultats par utilisateur. Par exemple, dans Raygun, il est possible de cliquer sur un score ou une barre sur l'histogramme pour voir une liste des utilisateurs impactés. Cela permet de commencer à approfondir les sessions sur une base individuelle, avec des informations au niveau de l'instance. Cela permet de prendre des mesures directement ciblées sur le problème au lieu de simplement faire confiance aux meilleures pratiques générales. Et plus tard, pour diagnostiquer les répercussions du changement.

Mettre en évidence les événements inhabituels

Bien sûr, ces fonctionnalités sont géniales et un développeur responsable doit garder un œil sur les tableaux de bord de surveillance des applications. Mais à mesure que votre application évolue, que les équipes grandissent et que les responsabilités se répartissent, il est plus important que jamais de mettre en place des processus automatisés qui vous alertent rapidement de tout problème de performance majeur. C'est pourquoi il est recommandé de configurer des déclencheurs d'alerte pour votre application.

Emballer

Pour résumer, les Web Vitals sont la nouvelle référence en matière de performances en raison de leur corrélation directe avec l'expérience de l'utilisateur. Les équipes de développement qui surveillent et optimisent activement leurs Web Vitals sur la base d'informations réelles sur les utilisateurs offriront des expériences numériques plus rapides et plus résilientes.

Nous n'avons fait qu'effleurer la surface de ce que la surveillance peut faire et des solutions pour maintenir la maintenance des performances tout en faisant évoluer votre application. Faites-moi savoir dans les commentaires comment vous utilisez un budget de performance, une meilleure observabilité ou d'autres solutions pour passer une nuit de sommeil détendue !