Métriques de performances axées sur l'utilisateur

Philip Walton

Nous savons tous à quel point les performances sont importantes. Mais lorsque nous parlons de performances et de la "vitesse de chargement des sites Web ", qu'entendons-nous précisément ?

En réalité, les performances sont relatives:

• Un site peut être rapide pour un utilisateur (sur un réseau rapide avec un appareil puissant), mais lent pour un autre utilisateur (sur un réseau lent avec un appareil bas de gamme).
• Il se peut que deux sites se chargent dans le même laps de temps, mais l'un d'entre eux semble se charger plus rapidement (s'il charge le contenu progressivement au lieu d'attendre la fin pour afficher quoi que ce soit).
• Un site peut sembler se charger rapidement, puis répondre lentement (ou pas du tout) aux interactions des utilisateurs.

Lorsque vous parlez des performances, il est important d'être précis et de faire référence aux performances en termes de metrics. Il s'agit de critères objectifs qui peuvent être mesurés de façon quantitative, mais il est également important de s'assurer que les métriques que vous mesurez sont utiles.

Définir des métriques

Auparavant, les performances Web étaient mesurées avec l'événement load. Cependant, même si load est un moment bien défini dans le cycle de vie d'une page, ce moment ne correspond pas nécessairement à ce qui intéresse l'utilisateur.

Par exemple, un serveur peut répondre avec une page minimale qui se "charge" immédiatement, puis différer la récupération du contenu ou l'affichage de quoi que ce soit sur la page jusqu'à plusieurs secondes après le déclenchement de l'événement load. Techniquement, une telle page présente un temps de chargement rapide, mais ce temps ne correspond pas à la façon dont l'utilisateur la voit se charger.

Ces dernières années, des membres de l'équipe Chrome, en collaboration avec le groupe de travail du W3C sur les performances Web, ont travaillé à la standardisation d'un ensemble de nouvelles API et métriques permettant de mesurer plus précisément l'expérience des utilisateurs sur une page Web.

Pour nous assurer que les métriques sont pertinentes pour les utilisateurs, nous les axons sur quelques questions clés:

Comment les métriques sont-elles mesurées ?

Les métriques de performances sont généralement mesurées de deux manières:

• Au cours de l'atelier:Utiliser des outils pour simuler le chargement d'une page dans un environnement cohérent et contrôlé
• Sur le terrain: utilisateurs réels qui chargent la page et interagissent avec elle

Aucune de ces options n'est nécessairement meilleure ou pire que l'autre. En fait, il est généralement préférable d'utiliser les deux pour obtenir de bonnes performances.

Au laboratoire

Il est essentiel de tester les performances dans l'atelier lorsque vous développez de nouvelles fonctionnalités. Avant le lancement d'une fonctionnalité en production, il est impossible de mesurer ses caractéristiques de performances auprès d'utilisateurs réels. Par conséquent, le meilleur moyen d'éviter toute régression des performances consiste à les tester en laboratoire avant le lancement de la fonctionnalité.

Sur le terrain

En revanche, bien que les tests en laboratoire constituent un indicateur raisonnable des performances, ils ne reflètent pas nécessairement l'expérience utilisateur réelle sur votre site.

Les performances d'un site peuvent varier considérablement en fonction des capacités de l'appareil d'un utilisateur et de l'état du réseau. Elle peut également varier selon que l'utilisateur interagit avec la page ou non.

Par ailleurs, les chargements de page ne sont pas toujours déterministes. Par exemple, les sites qui chargent du contenu ou des annonces personnalisés peuvent connaître des caractéristiques de performances très différentes d'un utilisateur à l'autre. Un test en atelier ne capturera pas ces différences.

La seule façon de connaître les performances de votre site pour vos utilisateurs est de mesurer ses performances à mesure que ces derniers se chargent et interagissent avec lui. Ce type de mesure est communément appelé Real User Monitoring (RUM).

Types de métriques

Plusieurs autres types de métriques sont pertinents pour la façon dont les utilisateurs perçoivent les performances.

• Vitesse de chargement perçue:la vitesse à laquelle une page peut charger et afficher tous ses éléments visuels à l'écran.
• Réactivité de chargement:la vitesse à laquelle une page peut charger et exécuter tout code JavaScript requis afin que les composants répondent rapidement aux interactions de l'utilisateur.
• Réactivité à l'exécution:après le chargement de la page, rapidité avec laquelle celle-ci peut répondre aux interactions de l'utilisateur.
• Stabilité visuelle:les éléments de la page se déplacent-ils de manière inattendue pour les utilisateurs et peuvent-ils interférer avec leurs interactions ?
• Fluidité:les transitions et les animations s'affichent-elles à une fréquence d'images constante et circulent-elles de manière fluide d'un état à l'autre ?

Compte tenu de tous ces types de métriques de performances, il est clair qu'aucune métrique unique ne suffit pour capturer toutes les caractéristiques de performances d'une page.

Métriques importantes à mesurer

• First Contentful Paint (FCP):mesure le temps écoulé entre le début du chargement de la page et l'affichage d'une partie de son contenu à l'écran. (atelier, champ)
• Largest Contentful Paint (LCP):mesure le temps écoulé entre le début du chargement de la page et l'affichage du plus grand bloc de texte ou élément image à l'écran. (atelier, champ)
• Interaction to Next Paint (INP): mesure la latence de chaque appui, clic ou interaction avec le clavier sur la page et, en fonction du nombre d'interactions, sélectionne la latence d'interaction la plus faible sur la page (ou une valeur proche de la latence la plus élevée) comme valeur unique représentative de la réactivité globale d'une page. (atelier, champ)
• Total Blocking Time (TBT):mesure le temps total entre le FCP et le TTI pendant lequel le thread principal a été bloqué suffisamment longtemps pour empêcher la réactivité aux entrées. (atelier)
• Cumulative Layout Shift (CLS):mesure le score cumulé de tous les décalages de mise en page inattendus qui se produisent entre le début du chargement de la page et le état de son cycle de vie (masqué). (atelier, champ)
• Time to First Byte (TTFB): mesure le temps nécessaire au réseau pour répondre à une requête utilisateur avec le premier octet d'une ressource. (atelier, champ)

Dans certains cas, de nouvelles métriques seront ajoutées pour couvrir les domaines manquants, mais dans d'autres cas, les meilleures métriques seront celles spécifiquement adaptées à votre site.

Métriques personnalisées

Les métriques de performances décrites précédemment sont utiles pour obtenir une compréhension générale des caractéristiques de performances de la plupart des sites sur le Web. Ils sont également utiles pour disposer d'un ensemble commun de statistiques permettant aux sites de comparer leurs performances à celles de leurs concurrents.

Cependant, il peut arriver qu'un site spécifique soit unique, d'une manière qui nécessite des métriques supplémentaires pour obtenir une vue d'ensemble des performances. Par exemple, la métrique LCP sert à mesurer le moment où le chargement du contenu principal d'une page est terminé. Toutefois, il peut arriver que l'élément le plus volumineux ne fasse pas partie du contenu principal de la page et que le LCP ne soit donc pas pertinent.

Pour résoudre ce problème, le groupe de travail Web Performance Working Group a également standardisé des API de niveau inférieur qui peuvent être utiles pour implémenter vos propres métriques personnalisées:

• API User Timing
• API Long Tasks
• API Element Timing
• API Navigation Timing
• API Resource Timing
• Temps du serveur

Consultez le guide sur les métriques personnalisées pour découvrir comment utiliser ces API afin de mesurer les caractéristiques de performances propres à votre site.