Introduction
La mesure des performances web ne se limite pas à la seule mesure du "temps de chargement". Il existe de nombreux indicateurs de performance web, chacun remplissant un rôle précis. Certains sont plutôt techniques, tandis que d'autres visent à donner un aperçu de l'expérience des utilisateurs vis-à-vis du chargement des pages. Comprendre les indicateurs que vous utilisez est essentiel pour orchestrer vos projets.
Le module Speed Analysis Lab et le RUM disposent de toute une série de métriques UX et techniques pour vous permettre de mesurer intégralement les performances web de votre site.
Liste des métriques par ordre alphabétique
Retrouvez ci-dessous la liste complète (organisée dans l'ordre alphabétique de A à Z) des métriques que vous pouvez suivre dans Speed Analysis Lab et ses fonctionnalités de monitorings synthétique et d'utilisateurs réels (RUM).
DOM Complete (Synthetic)
Le DOM Complete, littéralement "DOM Complet" en français, mesure le temps nécessaire pour achever la construction du DOM.
Comprendre le DOM Complete
Le timestamp du DOM Complete corresponds au moment où tous les scripts contenus dans le DOM, y compris ceux avec l'attribut "async", ont été exécutés : c'est-à dire que toutes les sous-ressources de la page définies dans le DOM (images, iframes, etc.) sont chargées.
Le Load Event Start ("début de l'événement de chargement" en français) succède directement au DOM Complete. Dans la plupart des cas, ces 2 métriques sont égales. Le seul délai supplémentaire qui pourrait être introduit avant le Load Event Start serait causé par les traitements gérés par onReadyStateChange.
DOM Content Loaded (Synthetic)
Méthode de collecte : Navigateur web (API)
Le DOMContentLoaded (DCL) est un évènement déclenché par le navigateur web. Comme cet évènement permet d'attacher des écouteurs d'évènements ("listeners") permettant eux mêmes de déclencher des traitements JavaScript (comme le fait jQuery.ready
, un exemple très répandu), le DCL a un début (Start) et une fin (End).
L'événement DOMContentLoaded est émis lorsque le document HTML initial a été complètement chargé et traité par le navigateur (mais sans attendre la fin du chargement des images ou des iFrames).
En revanche, le JavaScript bloquant retardera l'évènement. Rendre votre JavaScript asynchrone vous permettra d'améliorer le DOMContentLoaded.
Note : Si le DOMContentLoaded End est significativement plus élevée que le DOMContentLoaded Start, cela signifie que les traitements déclenchés sur la page via un listener associé sont lents (à cause d'une quantité de code significative et/ou s'appuyant sur le réseau).
Le DOMContentLoaded Start succède directement au DOMInteractive. Entre le DOMInteractive et le DCL Start, les seuls traitements de codes qui se produisent sont liés aux scripts de type module avec l'attribut "async" (asynchrone).
DOM Interactive (Synthetic)
Méthode de collecte : Navigateur web (API)
L'événement DOMInteractive se déclenche une fois que le DOM ("Document Object Model") est chargé et que les scripts "bloquants" de la page web ont été exécutés.
En revanche, les scripts qui ont l'attribut "defer" ne sont pas encore exécutés à ce stade. Certaines feuilles de style peuvent être encore en cours de chargement et bloquer le rendu de la page.
Cumulative Layout Shift (Synthetic and RUM)
Méthode de collecte : Navigateur web (API)
Le Cumulative Layout Shift (CLS) mesure la stabilité de la page. Il surveille les déplacements significatifs des éléments de la page qui pourraient frustrer ou induire en erreur les utilisateurs, pendant toute la durée de vie de la page.
Le CLS fait partie des Core Web Vitals. Google utilise les Core Web Vitals comme système de classement de recherche depuis 2021.
Comprendre le Cumulative Layout Shift (CLS)
Le Cumulative Layout Shift mesure la somme totale de tous les décalages de mise en page individuels qui se produisent durant toute la durée de vie de la page (y compris après que l'utilisateur ait commencé à interagir avec la page), en tenant compte de la taille de la zone concernée et de la distance du décalage.
L'algorithme du CLS suit chaque layout shift ("décalage de mise en page") dans son contexte, en excluant le contenu des iFrames.
Les décalages qui se produisent 500 ms après une interaction active d'utilisateur (comme un clic, une saisie ou le redimenssionnement de la fenêtre) n'ont aucun impact sur le CLS. Les survols, le scroll, et les mises à jour ne sont pas considérés comme des interactions actives.
Tous les autres décalages sont notés selon la surface totale affectée et la distance parcourue par les éléments déplacés. Le Cumulative Layout Shift correspond à la somme de tous les scores de décalages considérés.
Selon les directives de Google, vos pages web devraient avoir un CLS inférieur à 0,1s pour au moins 75% de vos utilisateurs (trafic sur desktop et mobile inclus).
Exemple d'optimisation
Pour améliorer votre Cumulative Layout Shift, assurez-vous que le navigateur peut attribuer le bon espace à vos images et iFrames (publicités incluses), avant même qu'ils ne commencent à les charger. Vous pouvez accomplir cela en définissant leur dimension ou leur rapport largeur / hauteur.
First Contentful Paint (Synthetic and RUM)
Méthode de collecte : Navigateur web (API)
Le First Contentful Paint (FCP) mesure le délai nécessaire pour que du contenu commence a apparaître sur la page.
Comprendre le First Contentful Paint (FCP)
La définition du FCP est très proche de celle du Start Render (voir ci-dessous). Cependant, le FCP n'est pas obtenu par analyse vidéo, il est fourni directement par le navigateur web (via l'API Paint Timing).
Malgré sa définition, le FCP peut se déclencher même si rien n'est encore visible sur la page. Par exemple, un texte peut être disponible sur la page, mais invisible, parce que la police de caractère personnalisée (web font) dans laquelle il est écrit est encore en cours de chargement.
First Input Delay (RUM)
Méthode de collecte : Navigateur web (API)
Le First Input Delay (FID) mesure le temps qu'il faut à une page Web pour répondre à la première interaction d'un utilisateur (une interaction peut être un clic ou un tap sur un lien ou sur un bouton).
Le First Input Delay maximal potentiel (FID maximal potentiel) est la pire valeur que peut avoir un FID. Le First Input Delay (FID) est la durée qu'un utilisateur doit attendre avant que la page ne réagisse à une interaction lorsqu'il interagit avec la page pour la première fois (par exemple : le délai pour obtenir un retour de la page lorsqu'on clique sur un élément).
Le FID dépend de l'activité de la page (tâches empêchant la réactivité) et du moment où l'utilisateur interagit.
Le FID est collecté à partir d'une interaction donnée d'un utilisateur réel, alors que le FID maximal potentiel peut être calculé sans utilisateur : la valeur est le temps auquel un utilisateur serait confronté s'il interagissait avec la page lorsqu'elle est la moins réactive (pire scénario possible).
Selon les directives de Google, vos pages Web devraient avoir un FID inférieur à 100ms pour au moins 75 % des utilisateurs (trafic desktop et mobile compris).
Comment est-ce calculé ?
Le First Input Delay maximal potentiel est calculé à l'aide de la plus longue tâche après le First Contentful Paint (puisqu'on suppose qu'un utilisateur n'essayerait pas d'interagir avec la page avant que du contenu y soit affiché).
Interaction to Next Paint (RUM)
Méthode de collecte : Navigateur web (API)
L'Interaction to Next Paint (INP) est une métrique qui évalue la réactivité de la page web. Elle mesure le temps qui s'écoule entre une interaction utilisateur, comme un clic ou une saisie clavier, et la mise à jour visuelle de la page qui suit pour l'utilisateur. (Notez que la mise à jour visuelle en question peut ne pas être liée à l'interaction de l'utilisateur).
Google a annoncé que le FID serait remplacé par l'INP en mars 2024. Le FID ne sera alors plus utilisé pour classer les sites web, tandis que l'INP, si (avec le LCP et le CLS).
Différences entre l'INP et le FID
- le FID se concentre sur la première interaction sur la page tandis que l'INP mesure toutes les interactions avec la page
- le FID calcule le temps écoulé entre l'interaction utilisateur et le moment où le navigateur est en mesure de la traiter.
- l'INP mesure le délai entre l'interaction utilisateur et le moment où un changement d'UI se produit.
L'INP est bien plus représentatif du potentiel délai visuel dont l'utilisateur fait l'expérience lorsqu'il interagit avec la page. Le FID, lui, se concentre davantage sur un délai technique au début de la vue de page (première interaction uniquement).
L'INP : comment ça marche ?
L'INP vise à enregistrer la durée entre le moment où un utilisateur entreprend une interaction et le rendu consécutif de la frame suivante, et ce pour la plupart des interactions utilisateurs, si ce n'est toutes. La valeur de l'INP représente le pire délai observé (pour les vues de page avec plus de 50 interactions, l'INP étant donné au 98ème centile, les valeurs extrêmes sont exclues).
Interactions prises en compte pour l'INP :
- Clic avec une souris
- Tap sur un device à écran tactile
- Saisie sur clavier (physique ou sur écran)
Note : Les survols et les scrolls ne sont pas pris en compte dans l'INP.
Selon les directives de Google, l'INP de vos pages web devrait être en dessous de 200ms pour au moins 75% des utilisateurs (trafic mobile et desktop inclus).
Largest Contentful Paint (Synthetic and RUM)
Méthode de collecte : Navigateur web (API)
Le Largest Contentful Paint (LCP) mesure les performances de chargement et fait partie des Core Web Vitals. Google utilise les Core Web Vitals comme système de classement de recherche depuis 2021.
Comprendre le Largest Contentful Paint (LCP)
Le LCP mesure le temps de rendu du plus grand élément de contenu visible dans le viewport (donc avant que les utilisateurs ne scrollent la page).
Le LCP se concentre sur la vitesse d'affichage du contenu le plus grand (en excluant les images d'arrière-plan et le contenu affiché en dehors du viewport : par exemple, en dessous de la ligne de flottaison) et le plus constant (les contenus temporaires tels que les écrans de démarrages ou de chargements sont ignorés).
Selon les directives de Google, vos pages web devraient avoir un LCP inférieur à 2,5s, pour au moins 75% de vos utilisateurs (trafic desktop et mobile inclus).
Les causes courantes d'un LCP lent sont les éléments volumineux tels que les images, les vidéos et les scripts tiers.
Exemple d'optimisation
Optimisez les ressources, utilisez le lazy load et réduisez le JS à l'essentiel.
Load Time / Fully Loaded (Synthetic)
Méthode de collecte : Analyse du trafic réseau
Cette métrique correspond au délai nécessaire pour que la page web soit entièrement chargée (jusqu'à ce que Speed Analysis Lab ne détecte plus d'activité réseau).
Comprendre le Fully Loaded
Le Fully Loaded, qu'on pourrait appeler "temps de chargement complet" en français, est affecté par toutes les requêtes émises en lien avec le chargement de la page, y compris les ressources chargées par la page puisque les requêtes n'affectent pas directement l'expérience utilisateur (retargeting, etc.).
Onload Start/End (Synthetic)
Méthode de collecte : Navigateur web (API)
L'événement onload est déclenché lorsque le Document Object Model (DOM) est chargé et que les dépendances de la page ont été chargées et traitées (images, CSS, JavaScript, etc., mais pas les iFrames).
Le Load Event a un début et une fin puisque des écouteurs d'évènement ("listeners" en anglais), des morceau de JavaScript qui analysent les évènements de la page pour éxécuter du code, peuvent y être rattachés pour déclencher l'exécution de JavaScript lors du déclenchement de l'évènement. Le Load event ("évènement de chargement") se déclenche lorsque le document HTML initial est complètement chargé et traité (sans attendre que les images et les iFrames finissent de charger).
Les scripts externes avec un attribut "defer" et/ou "async" ont également été exécutés à ce stade, de même que les feuilles de style avec l'attribut "async".
Speed Index (Synthetic)
Méthode de collecte : Analyse vidéo
Le Speed Index ou "indice de vitesse" est un indice qui reflète la vitesse d'affichage moyenne des composants de la page.
Comprendre le Speed Index
Le Speed Index correspond au délai moyen d'affichage des pixels qui composent la partie visible de la page web testée (au-dessus de la ligne de flottaison). Par conséquent, cet indicateur prend en compte la progressivité de l'affichage des différents éléments composant la page (plus la vitesse est faible, mieux c'est).
Google recommande un indice de vitesse inférieur à 1000 ms.
Exemples d'optimisation
Évitez les appels synchrones aux ressources statiques externes, hébergez localement les CSS et JS importants.
Réduisez la charge utile de JS ou déplacez-le vers le pied de page.
Start Render (Synthetic)
Méthode de collecte : Analyse vidéo
Le Start Render, ou "début de l'affichage", correspond au moment du premier affichage sur l'écran de l'utilisateur (avant cela, la page reste vierge). Le Start Render est déterminé par analyse vidéo du chargement de la page web.
Comprendre le Start Render
Comme l'analyse vidéo ne concerne que la partie visible de la page web testée (c'est-à-dire ce qui se trouve au-dessus de la ligne de flottaison), veuillez noter que le premier élément à être rendu n'est pas nécessairement significatif (il peut s'agir d'un élément mineur comme une couleur d'arrière-plan, un texte ou autre).
Exemples d'optimisation
Rendez le contenu important disponible rapidement dans la page web, sans appels d'API supplémentaires.
Fournissez le CSS nécessaire au contenu du haut de la page dès le début, idéalement en ligne.
Time to First Byte (Synthetic and RUM)
Méthode de collecte : Analyse du trafic réseau
Le Time To First Byte (TTFB) (littéralement "délai au premier octet" en français) indique le temps écoulé entre le moment où le navigateur émet une requête de page et la réception du premier élément de données par l'utilisateur (le code HTML de la page web correspondante).
Comprendre le Time to First Byte
Le Time To First Byte correspond au temps de réponse du serveur web ajouté à la latence du réseau, à la résolution DNS et au temps nécessaire pour établir une connexion TCP (et pour établir une connexion sécurisée si votre page web utilise des HTTP).
Les délais de redirection (non seulement 301 et 302, mais aussi les redirections JavaScript côté client) sont inclus dans le TTFB, car la métrique considère le premier octet "utile" associé à la page web à charger.
Google recommande que le TTFB de votre site web soit de 200 millisecondes (0,2 s) ou moins. Un chargement lent peut être dû au contexte (débit à forte latence), à l'état du serveur, à la longueur de la chaîne de certificats ou à des redirections, entre autres.
Exemple d'optimisation
Examinez d'éventuels problèmes de cache sur le backend.
Time to Last Byte (Synthetic)
Méthode de collecte : Analyse du trafic réseau
Le Time To Last Byte, ou "délai de réception du dernier octet", mesure le temps qui s'écoule entre la demande envoyée par le navigateur et la réception du dernier octet de la réponse correspondante (la dernière partie du document HTML).
Comprendre le Time to Last Byte (TTLB)
Le TTLB suit directement le TTFB (Time To First Byte ou "délai au premier octet"). Le "délai de réception du dernier octet" prends en compte un délai supplémentaire par rapport au "délai au premier octet" : celui de la réception du reste de la réponse, soit le temps de téléchargement des données.
Note : La différence entre le temps de début (TTFB) et le temps de fin (TTLB) est généralement mineur, sauf lorsque la page HTML est lourde (par rapport au débit descendant de la connexion utilisée pour le test de vitesse).
Time to (Consistently) Interactive (Synthetic)
Méthode de collecte : GoogleChromeLabs polyfill (en attente d'une implémentation native dans le navigateur)
Le Time to Interactive (proposé par Google) est un indicateur complexe. Contrairement à ce que son nom pourrait évoquer, il ne correspond pas au moment où une page devient interactive, mais au moment où elle le devient de manière certaine et durable. Pour plus de clarté, nous avons décidé de nommer cet indicateur Time To (Consistently) Interactive dans Speed Analysis Lab.
Qu'est-ce qui rend une page durablement interactive?
L'algorithme TTI est basé à la fois sur l'analyse de l'activité JavaScript et sur celle du réseau. Il permet de déterminer le moment à partir duquel un utilisateur peut interagir avec la page sans risque quant à la fluidité de la réaction attendue (pas de "lag" de la page, pas de délai perceptible entre l'action et la réaction associée...).
Une page est considérée comme durablement interactive lorsque toutes les conditions sont réunies, pendant au moins 5 secondes, pour qu'une interaction se produise de manière satisfaisante. Si durant cette fenêtre de 5 secondes, une LongTask (littéralement "tâches longues") se produit, alors nous recommençons à attendre 5 secondes consécutives. Si ce n'est pas le cas, le Time To (Consistently) Interactive est défini au début de la plage "calme" des 5 secondes.
S'il n'y a pas de répit dans l'émergence de LongTasks (c'est-à-dire que le navigateur effectue de manière répétée des tâches qui le ralentissent), ni leTime To (Consistently) Interactive, ni les mesures qui s'y rapportent (comme le Total Blocking Time par exemple) ne peuvent être calculées.
Total Blocking Time (Synthetic)
Méthode de collecte : Navigateur web (longue tâches d'API + algorithme simple)
Le Total Blocking Time (TBT) mesure la durée totale durant laquelle une page est bloquée et ne peut répondre aux interactions utilisateurs (clics, saisies clavier, etc.) après que la page ait commencé à rendre du contenu.
Comment est-ce calculé ?
Le calcul du Total Blocking Time est basé sur les Long Tasks. Une Long Task, ou "tâche longue" en français, est un traitement qui monopolise le navigateur web un certain temps (>50 millisecondes) et empêche donc les autres tâches cruciales d'être traitées et exécutées (par exemple : réagir aux interactions des utilisateurs).
Le Total Blocking Time correspond à la somme, calculé en additionnant le temps de blocage de toutes les Long Tasks qui se produisent entre le First Contentful Paint et le Time to (Consistently) Interactive. Le temps de blocage d'une Long Task équivaut à la durée qu'elle prends après 50 ms.
Exemple du chargement d'une page avec 3 tâches longues :
[longtask 1: 55 ms] FCP [longtask 2: 110 ms] [longtask 3: 200 ms] TTI
- longtask 1 est ignorée puisqu'elle a lieu avant le FCP.
- le temps de blocage de long task 2 est de 60 ms (110 - 50).
- le temps de blocage de long task 3 est de 150 ms (200 - 50).
Le Total Blocking Time est donc de 210 ms (60 + 150).
Pourquoi le Total Blocking Time n'est-il parfois pas calculé ?
Puisque le Total Blocking Time est calculé entre le First Contentful Paint (FCP) et le Time to (Consistently) Interactive, les deux métriques doivent être définies pour que le TBT existe. Lorsque les tâches longues sont récurrentes et répétées, il n'y a pas vraiment de moment où l'interface est constamment interactive, il n'y a donc pas de "fin" à la plage de temps durant laquelle le TBT doit être calculé.
Si vous devez suivre vos tâches longues mais que le TBT ne peut être calculé, vous pouvez utiliser la métrique "Somme des tâches longues" à la place.
Visually Complete (Synthetic)
Méthode de collecte : Analyse vidéo
Visually Complete (littéralement "visuellement complet" en français) calcule le temps nécessaire pour que tout le contenu situé au-dessus de la ligne de flottaison soit visible.
Comprendre le Visually Complete
Le Visually Complete correspond au délai nécessaire pour que la partie de la page au dessus de la ligne de flottaison atteigne son état final. (Cette métrique est calculée à partir de l'analyse de la vidéo de chargement de la page web).
Cet état de rendu final est capturé à la fin de notre analyse, c'est-à-dire lorsque Speed Analysis Lab ne détecte plus aucun trafic lié au chargement de la page. L'analyse de la vidéo permet ensuite à notre module d'identifier à quel moment cet état final a pu être atteint.
La détection de l'état final peut être affectée par les animations (comme les carrousels par exemple), puisque l'affichage peut changer à plusieurs reprises alors que visuellement la page web semble totalement chargée. Afin de stabiliser vos résultats, le module propose de désactiver les animations.
Exemple d'optimisation
Choisissez la couleur dominante à charger en arrière-plan et mettez-la en ligne avec votre CSS. Par exemple, mettez un fond noir pour une image où le noir est dominant pour réserver l'espace pendant son temps de chargement.