Nous savons tous à quel point les performances sont importantes. Mais lorsque nous parlons de performances et de rapidité, 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 doté d'un appareil puissant), mais lent pour un autre (sur un réseau lent avec un appareil d'entrée de gamme).
- Le chargement de deux sites peut se terminer exactement dans le même temps, mais il peut sembler 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, mais réagir lentement, voire pas du tout, aux interactions des utilisateurs.
Lorsque l'on parle de performances, il est important d'être précis et de se référer aux performances en termes de metrics, des critères objectifs pouvant être mesurés de manière quantitative. Mais il est également important de s'assurer que les métriques que vous mesurez sont utiles.
Métriques
Auparavant, les performances Web étaient mesurées avec l'événement load. Toutefois, 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 à quelque chose qui intéresse l'utilisateur.
Par exemple, un serveur peut répondre avec une page minimale qui "se charge" immédiatement, mais diffère ensuite la récupération du contenu ou l'affichage de tout élément de la page jusqu'à quelques 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 perçoit le chargement.
Ces dernières années, les membres de l'équipe Chrome, en collaboration avec le W3C Web Performance Working Group, se sont efforcés de standardiser un ensemble de nouvelles API et métriques permettant de mesurer plus précisément l'expérience des utilisateurs sur les pages Web.
Pour nous assurer que les métriques sont pertinentes pour les utilisateurs, nous les axons autour de quelques questions clés:
| C'est un problème ? | La navigation a-t-elle démarré correctement ? Le serveur a-t-il répondu ? |
| Est-ce utile ? | Le contenu affiché est-il suffisant pour que les utilisateurs puissent interagir avec lui ? |
| Est-il utilisable ? | Les utilisateurs peuvent-ils interagir avec la page ou est-elle occupée ? |
| Est-ce agréable ? | Les interactions sont-elles fluides et naturelles, sans décalage ni à-coups ? |
Comment les métriques sont mesurées
Les métriques de performances sont généralement mesurées de l'une des deux manières suivantes:
- Dans l'atelier:Utiliser des outils pour simuler un chargement de page dans un environnement cohérent et contrôlé
- Dans le champ: sur des utilisateurs réels qui chargent la page et interagissent avec elle
Aucune de ces options n'est nécessairement meilleure ou moins bonne que l'autre. En fait, vous devez généralement utiliser les deux pour garantir de bonnes performances.
Au laboratoire
Il est essentiel de tester les performances en atelier lorsque vous développez de nouvelles fonctionnalités. Avant la sortie des fonctionnalités en production, il est impossible de mesurer leurs caractéristiques de performances sur des utilisateurs réels. Le meilleur moyen d'éviter les régressions de performances est donc de les tester dans l'atelier avant le lancement de la fonctionnalité.
Sur le terrain
En revanche, bien que les tests effectués dans cet atelier soient un bon indicateur des performances, ils ne reflètent pas nécessairement l'expérience de tous les utilisateurs sur votre site.
Les performances d'un site peuvent varier considérablement en fonction des capacités de l'appareil de l'utilisateur et de l'état du réseau. Elle peut également varier selon que l'utilisateur interagit avec la page (ou selon la méthode utilisée).
De plus, les chargements de page ne sont pas toujours déterministes. Par exemple, les sites qui chargent du contenu ou des annonces personnalisés peuvent présenter des caractéristiques de performances très différentes d'un utilisateur à l'autre. Ces différences ne sont pas prises en compte dans un test d'atelier.
La seule façon de connaître les performances réelles de votre site auprès des utilisateurs est de mesurer ses performances à mesure que ces utilisateurs 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 concernant la façon dont les utilisateurs perçoivent les performances:
- Vitesse de chargement perçu:la vitesse à laquelle une page peut se charger et afficher tous ses éléments visuels à l'écran.
- Réactivité au chargement:vitesse à laquelle une page peut charger et exécuter le code JavaScript nécessaire pour que les composants répondent rapidement aux interactions des utilisateurs.
- Réactivité lors de l'exécution:vitesse à laquelle une page peut répondre à l'interaction de l'utilisateur après son chargement.
- Stabilité visuelle:les éléments de la page se déplacent-ils d'une manière inattendue pour les utilisateurs, ce qui peut interférer avec leurs interactions ?
- Fluidité:les transitions et les animations s'affichent-elles à une fréquence de frames cohérente 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 ne suffit à capturer toutes les caractéristiques de performances d'une page.
Métriques importantes à mesurer
- First Contentful Paint (FCP)
- Délai 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)
- Délai entre le début du chargement de la page et l'affichage du plus grand bloc de texte ou élément d'image à l'écran. (atelier, champ)
- Interaction to Next Paint (INP)
- Latence de chaque appui, clic ou interaction avec le clavier avec la page. En fonction du nombre d'interactions, cette métrique sélectionne la latence d'interaction la plus faible (ou proche de la pire) de la page en tant que valeur unique et représentative pour décrire la réactivité globale d'une page. (atelier, champ)
- Total Blocking Time (TBT)
- Délai total entre le FCP et le délai avant interactivité (TTI), pendant lequel le thread principal a été bloqué suffisamment longtemps pour empêcher la réactivité aux entrées. (atelier)
- CLS (Cumulative Layout Shift)
- 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 passage à l'état de son cycle de vie en mode masqué. (atelier, champ)
- Temps de latence du premier octet (TTFB)
- Temps nécessaire au réseau pour répondre à une requête utilisateur avec le premier octet d'une ressource. (atelier, champ)
Cette liste comprend des métriques qui mesurent de nombreux aspects de performances pertinents pour les utilisateurs, mais elle n'inclut pas tout. Par exemple, la réactivité et la fluidité de l'environnement d'exécution ne sont pas couvertes.
Dans certains cas, de nouvelles métriques seront introduites pour couvrir les domaines manquants. Dans d'autres cas, les métriques optimales seront celles spécifiquement adaptées à votre site.
Métriques personnalisées
Les métriques de performances répertoriées ici sont utiles pour comprendre les caractéristiques de performances de la plupart des sites sur le Web. Elles sont également efficaces pour disposer d'un ensemble commun de métriques 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 ou d'une autre, et qu'il nécessite des métriques supplémentaires pour obtenir un aperçu complet des performances. Par exemple, la métrique LCP est destinée à mesurer le moment où le chargement du contenu principal d'une page est terminé. Toutefois, dans certains cas, le plus grand élément ne fait pas partie du contenu principal de la page, ce qui rend le LCP non pertinent.
Pour traiter de tels cas, le groupe de travail sur les performances Web a également normalisé 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 de serveur
Consultez le guide sur les métriques personnalisées pour apprendre à utiliser ces API afin de mesurer les caractéristiques de performances propres à votre site.