Nous avons tous entendu dire que les performances sont importantes. Mais que voulons-nous dire précisément lorsque nous parlons de performances et de "rapidité" des sites Web ?
La vérité est que les performances sont relatives:
- Un site peut être rapide pour un utilisateur (sur un réseau rapide avec un appareil puissant) et lent pour un autre (sur un réseau lent avec un appareil bas de gamme).
- Deux sites peuvent se charger en exactement le même temps, mais l'un peut sembler se charger plus rapidement (s'il charge le contenu progressivement plutôt que d'attendre la fin pour afficher quoi que ce soit).
- Un site peut paraître se charger rapidement, mais répondre ensuite lentement (ou pas du tout) aux interactions des utilisateurs.
Lorsque vous parlez de performances, il est important d'être précis et de vous référer aux performances en termes de métriques. des critères objectifs qui peuvent être mesurés quantitativement, mais il est également important de vous assurer que les métriques que vous mesurez sont utiles.
Définir des métriques
Historiquement, les performances Web étaient mesurées à l'aide de 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 qui diffère ensuite l'extraction 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, le temps de chargement d'une telle page est rapide, mais il ne correspond pas à l'expérience de chargement de la page par l'utilisateur.
Au cours des dernières années, les membres de l'équipe Chrome, en collaboration avec le W3C Web Performance Working Group, ont travaillé à la standardisation d'un ensemble de nouvelles API et métriques qui mesurent 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 encadrons autour de quelques questions clés:
| Est-ce que cela se produit ? | La navigation a-t-elle bien démarré ? Le serveur a-t-il répondu ? |
| Est-il 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-il agréable ? | Les interactions sont-elles fluides et naturelles, sans décalage ? |
Comment les métriques sont-elles mesurées ?
Les métriques de performances sont généralement mesurées de l'une des deux manières suivantes:
- En laboratoire:en utilisant des outils pour simuler le chargement d'une page dans un environnement cohérent et contrôlé
- Sur le terrain: sur des utilisateurs réels qui chargent et interagissent avec la page
Aucune de ces options n'est nécessairement meilleure ou pire que l'autre. En fait, vous devez généralement utiliser les deux pour garantir de bonnes performances.
Au laboratoire
Tester les performances en laboratoire est essentiel lorsque vous développez de nouvelles fonctionnalités. Avant que les fonctionnalités ne soient publiées en production, il est impossible de mesurer leurs caractéristiques de performances sur des utilisateurs réels. Par conséquent, les tester en laboratoire avant leur publication est le meilleur moyen d'éviter une régression des performances.
Sur le terrain
En revanche, bien que les tests en laboratoire soient un indicateur raisonnable des performances, ils ne reflètent pas nécessairement l'expérience des utilisateurs réels sur votre site.
Les performances d'un site peuvent varier considérablement en fonction des fonctionnalités de l'appareil de l'utilisateur et de l'état de son réseau. Il peut également varier selon que l'utilisateur interagit avec la page (et comment).
Les chargements de pages ne sont pas toujours déterministes. Par exemple, les sites qui chargent des contenus ou des annonces personnalisés peuvent présenter des caractéristiques de performances très différentes d'un utilisateur à l'autre. Un test en laboratoire ne capturera pas ces différences.
Le seul moyen de savoir réellement comment votre site fonctionne pour vos utilisateurs est de mesurer ses performances lorsque ces utilisateurs le chargent et interagissent avec lui. Ce type de mesure est communément appelé surveillance des utilisateurs réels (RUM).
Types de métriques
Il existe plusieurs autres types de métriques qui sont pertinents pour la façon dont les utilisateurs perçoivent les performances.
- Vitesse de chargement perçue: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 requis pour que les composants répondent rapidement aux interactions des utilisateurs.
- Réactivité au moment de l'exécution:après le chargement de la page, vitesse à laquelle celle-ci peut répondre aux interactions utilisateur.
- Stabilité visuelle:les éléments de la page se déplacent-ils de manière inattendue pour les utilisateurs et interfèrent-ils potentiellement avec leurs interactions ?
- Fluidité:les transitions et les animations sont-elles affichées à une fréquence d'images constante et passent-elles d'un état à l'autre de manière fluide ?
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):mesure le temps écoulé entre le début du chargement de la page et l'affichage à l'écran du contenu de n'importe quelle partie de la page. (laboratoire, terrain)
- Largest Contentful Paint (LCP):mesure le temps écoulé entre le début du chargement de la page et l'affichage à l'écran du plus grand bloc de texte ou de l'élément image. (laboratoire, terrain)
- Interaction to Next Paint (INP): mesure la latence de chaque interaction (appui, clic ou commande au clavier) effectuée avec la page et, en fonction du nombre d'interactions, sélectionne la pire latence d'interaction de la page (ou la plus proche de la plus élevée) comme valeur unique et représentative pour décrire la réactivité globale de la page. (laboratoire, terrain)
- Total Blocking Time (TBT):mesure la durée totale entre le FCP et le TTI, où le thread principal a été bloqué suffisamment longtemps pour empêcher la réactivité aux entrées. (laboratoire)
- 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 moment où son état de cycle de vie passe à "masqué". (laboratoire, terrain)
- 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. (laboratoire, terrain)
Dans certains cas, de nouvelles métriques seront introduites pour couvrir les zones manquantes, mais dans d'autres, les meilleures métriques sont celles qui sont spécifiquement adaptées à votre site.
Métriques personnalisées
Les métriques de performances abordées précédemment permettent d'obtenir une compréhension générale des caractéristiques de performances de la plupart des sites sur le Web. Ils permettent également de disposer d'un ensemble commun de métriques pour que les sites puissent comparer leurs performances à celles de leurs concurrents.
Toutefois, il peut arriver qu'un site spécifique soit unique et nécessite des métriques supplémentaires pour obtenir une vue complète des performances. Par exemple, la métrique LCP vise à mesurer le moment où le contenu principal d'une page a fini de se charger. Toutefois, il est possible que le plus grand élément ne fasse pas partie du contenu principal de la page. Par conséquent, la métrique LCP peut ne pas être pertinente.
Pour résoudre ces problèmes, 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 Long Animation Frames
- API Element Timing
- API Navigation Timing
- API Resource Timing
- Délais du serveur
Consultez le guide sur les métriques personnalisées pour découvrir comment utiliser ces API pour mesurer les caractéristiques de performances spécifiques à votre site.