Nous savons tous à quel point les performances sont importantes. Mais lorsqu'on parle de performances (et de rendre les sites "rapides", par exemple), qu'entend-on 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 l'un 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, puis répondre lentement (ou pas du tout) à l'interaction utilisateur.
Par conséquent, lorsque vous parlez des performances, il est important d'être précis et de faire référence aux performances en termes de critères objectifs pouvant être mesurés de manière quantitative. Ces critères sont appelés metrics.
Toutefois, ce n'est pas parce qu'une métrique est basée sur des critères objectifs et qu'elle peut être mesurée de manière quantitative que ces mesures sont utiles.
Définir des 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 reporte ensuite la récupération du contenu et l'affichage de tout élément sur la page jusqu'à quelques secondes après le déclenchement de l'événement load. Bien qu'une telle page puisse techniquement avoir un temps de chargement rapide, ce temps ne correspond pas à la façon dont un utilisateur subit réellement le chargement de la page.
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 en atelier soient un indicateur raisonnable 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 de son réseau. Elle peut également varier selon que l'utilisateur interagit avec la page (ou selon la manière dont il interagit).
En outre, les chargements de page peuvent ne pas être 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 seront 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 lorsque les utilisateurs le chargent et interagissent avec celui-ci. Ce type de mesure est communément appelé Real User Monitoring, ou RUM en abrégé.
Types de métriques
Plusieurs autres types de métriques sont pertinents pour déterminer comment 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 de chargement et d'exécution du code JavaScript requis par une page pour permettre aux composants de répondre rapidement à l'interaction de l'utilisateur.
- Réactivité de l'exécution:après le chargement de la page, quelle est la vitesse à laquelle celle-ci peut répondre à l'interaction utilisateur ?
- Stabilité visuelle:les éléments de la page se déplacent-ils d'une manière inattendue pour les utilisateurs, et sont-ils susceptibles d'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 les types de métriques de performances ci-dessus, 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):mesure le 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):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)
- First Input Delay (FID):mesure le délai entre le moment où un utilisateur interagit pour la première fois avec votre site (lorsqu'il clique sur un lien, appuie sur un bouton ou utilise une commande JavaScript personnalisée) et le moment où le navigateur est réellement en mesure de répondre à cette interaction. (champ)
- Interaction to Next Paint (INP): mesure la latence de chaque appui, clic ou interaction avec le clavier effectués avec la page. En fonction du nombre d'interactions, cette fonction sélectionne la pire latence d'interaction de la page (ou presque la plus élevée) comme valeur unique et représentative pour décrire la réactivité globale d'une page. (atelier, champ)
- Total Blocking Time (TBT):mesure la durée totale entre le FCP et le TTI, pendant laquelle 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 passage de son état de 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)
Bien que cette liste inclue des métriques mesurant de nombreux aspects des performances pertinents pour les utilisateurs, elle n'inclut pas tous les éléments. Par exemple, la réactivité et la fluidité de l'environnement d'exécution ne sont pas couvertes à l'heure actuelle.
Dans certains cas, de nouvelles métriques seront introduites pour couvrir les domaines manquants. 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 répertoriées ci-dessus sont utiles pour comprendre les caractéristiques de performances de la plupart des sites sur le Web. Elles sont également idéales 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 que vous ayez besoin de 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. Le LCP peut donc ne pas être 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.