html <h1>Suivi synthétique et métriques RUM (liste A-Z)</h1>

Le DOM Complet mesure le temps nécessaire pour construire complètement le DOM.

Comprendre le DOM Complet
Tous les scripts dans le DOM, y compris ceux avec l'attribut async, ont été exécutés. Toutes les sous-ressources de la page définies dans le DOM sont chargées (images, iframes, etc.).

L'événement de début de chargement suit immédiatement le DOM Complet. Dans la plupart des cas, ces 2 métriques sont égales. Le seul délai supplémentaire qui pourrait être introduit avant le début de l'événement de chargement serait causé par des traitements gérés par onReadyStateChange.

Collecté depuis : Navigateur Web (API)

Le DOMContentLoaded (DCL) est un événement déclenché par le navigateur web. Il a un début et une fin car des écouteurs peuvent être attachés à l'événement pour déclencher l'exécution de JavaScript lorsque l'événement se déclenche (c'est essentiellement ce que fait jQuery.ready).

L'événement DOMContentLoaded se déclenche lorsque le document HTML initial a été complètement chargé et analysé (sans attendre que les images et les iframes aient fini de se charger).

Le JavaScript bloquant retardera l'événement. Rendez votre JavaScript asynchrone pour optimiser le DOMContentLoaded.

Note : Si la fin de DOMContentLoaded est significativement plus élevée que le début de DOMContentLoaded, cela signifie que la page a des écouteurs attachés à cet événement déclenchant une exécution de code significative et/ou dépendant du réseau.

Le début de DOMContentLoaded suit immédiatement DOM Interactif. Entre DOMInteractif et DCL Début, les seuls traitements sont liés aux scripts asynchrones avec un type de module.

Collecté depuis : Navigateur Web (API)

L'événement DOMInteractif est déclenché lorsque le DOM est chargé et que les scripts bloquants pour la page web ont été exécutés. À ce stade, les scripts avec l'attribut defer ne sont pas encore exécutés. Certains styles peuvent encore se charger et bloquer la représentation de la page.

Collecté depuis : API du Navigateur Web

Le Déplacement de Mise en Page Cumulatif (CLS) mesure la stabilité de la page, en surveillant les mouvements significatifs des éléments sur la page qui peuvent frustrer ou induire en erreur l'utilisateur, 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 signal de classement depuis 2021.

Comprendre le Déplacement de Mise en Page Cumulatif (CLS)
Le Déplacement de Mise en Page Cumulatif mesure la somme totale de tous les déplacements de mise en page individuels qui se produisent pendant toute la durée de vie de la page (y compris après que l'utilisateur a commencé à interagir avec la page), en tenant compte de la taille de la zone concernée et de la distance du déplacement.

L'algorithme CLS surveille chaque déplacement de mise en page dans le contexte actuel, excluant ainsi le contenu des iframes.

Les déplacements de mise en page qui se produisent 500 ms après une interaction utilisateur active (comme un clic, une frappe, ou le redimensionnement de la fenêtre) n'ont aucun impact sur le CLS. Le survol, le défilement et le lancement de mise à jour ne sont pas considérés comme des interactions actives.

Chacun des autres déplacements de mise en page est noté en fonction de la zone totale affectée et de la distance parcourue par les éléments déplacés. Le Déplacement de Mise en Page Cumulatif est la somme de tous les scores des déplacements de mise en page considérés.

Selon les directives de Google, vos pages web devraient avoir un CLS inférieur à 0,1 pour au moins 75 % de vos utilisateurs (y compris le trafic desktop et mobile).

Exemple d'optimisation
Pour améliorer votre Déplacement de Mise en Page Cumulatif, assurez-vous que le navigateur peut allouer l'espace adéquat pour vos images et iframes (y compris les publicités), même avant de commencer à les charger, en définissant leur largeur et hauteur, ou leur ratio d'aspect.

Collecté depuis : Navigateur Web (API)

Premier Peinture de Contenu (FCP) mesure le temps qu'il faut pour que le contenu commence à apparaître sur la page.

Comprendre le Premier Peinture de Contenu (FCP)
La définition de FCP est très proche de celle de Début de Rendu. Cependant, FCP n'est pas calculé par analyse vidéo, mais fourni directement par le navigateur web (via l'API de Timing de Peinture).

Malgré sa définition, FCP peut être déclenché même lorsque rien n'est encore visible. Par exemple, lorsque le texte est disponible sur la page, mais invisible, car une police personnalisée (police web) est encore en cours de chargement.

Collecté à partir : API du navigateur web 

Le Délai de Première Interaction (FID) mesure le temps entre la première interaction d'un utilisateur et le temps qu'il faut pour que l'interaction soit traitée (l'interaction peut consister à cliquer ou à appuyer sur un lien ou un bouton). 

Le Délai de Première Interaction Potentiel Maximal (Max Potential FID) est la pire valeur qu'un Délai de Première Interaction pourrait avoir. Le Délai de Première Interaction (FID) est le délai qu'un utilisateur éprouve lorsqu'il interagit avec la page pour la première fois (exemple : délai pour obtenir un retour de la page lors du clic 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, tandis que le Max Potential FID peut être calculé sans utilisateur, la valeur étant le délai qu'un utilisateur rencontrerait en interagissant avec la page lorsque celle-ci est le moins réactive (scénario du pire cas).

Selon les directives de Google, vos pages web devraient avoir un FID inférieur à 100 ms pour au moins 75 % des utilisateurs (y compris le trafic mobile et desktop)

Comment il est calculé
Le Délai de Première Interaction Potentiel Maximal est calculé en trouvant la tâche la plus longue après le Premier Peinture de Contenu (car nous pouvons supposer qu'un utilisateur n'essaierait pas d'interagir avec une page avant qu'aucun contenu ne soit affiché).

Collecté à partir : Navigateur Web (API)

L'Interaction vers la Prochaine Peinture (INP) est une métrique qui évalue la réactivité d'une page web. Elle mesure le temps écoulé entre une interaction utilisateur, comme un clic ou une pression sur une touche, et la prochaine fois que l'utilisateur voit une mise à jour visuelle sur la page. (Veuillez noter que la mise à jour visuelle peut ne pas être liée à l'interaction).

Google a annoncé que le FID sera remplacé par l'INP en mars 2024. Le FID ne sera plus utilisé pour le classement des sites web mais l'INP le sera (avec le LCP et le CLS).

Différences entre l'INP et le FID 
 

• Le FID ne mesure que la première interaction de la page tandis que l'INP mesure toutes les interactions de la page. 
  
   
• Le FID mesure le délai entre l'interaction de l'utilisateur et le moment où le navigateur est réellement capable de commencer à traiter.
  
   
• L'INP mesure les détails entre l'interaction de l'utilisateur et le moment où il y a un changement d'IU subséquent.

L'INP est beaucoup plus représentatif du potentiel délai visuel de l'expérience de l'utilisateur lors de l'interaction avec une page. Le FID se concentre davantage sur un délai technique au début de la vue de la page (première interaction uniquement).

Comment fonctionne l'INP ?

L'INP vise à capturer la durée entre le moment où un utilisateur initie une interaction et le rendu subséquent du prochain cadre, s'efforçant d'atteindre cela pour la plupart, sinon toutes, les interactions utilisateur.

La valeur de l'INP est le pire délai observé (pour les vues de page avec plus de 50 interactions, les valeurs aberrantes sont exclues car l'INP sera la valeur du 98e centile)

Les interactions observées pour l'INP sont :

• Clic avec une souris
• Appuyer sur un appareil avec un écran tactile
• Appuyer sur une touche sur un clavier physique ou à l'écran

Note : Le survol de la souris et les défilements ne sont pas pris en compte dans l'INP.

Selon les directives de Google, vos pages web devraient avoir un INP inférieur à 200 ms pour au moins 75 % des utilisateurs (y compris le trafic mobile et desktop).
 

Collecté à partir : Navigateur Web (API)

La Plus Grande Peinture de Contenu (LCP) mesure la performance de chargement et fait partie des Core Web Vitals. Google utilise les Core Web Vitals comme signal de classement depuis 2021.

Comprendre la Plus Grande Peinture de Contenu (LCP)

La Plus Grande Peinture de Contenu (LCP) mesure le temps de rendu de l'élément de contenu le plus grand visible dans le viewport (avant que les utilisateurs ne fassent défiler).

Le LCP se concentre sur la vitesse de livraison du contenu le plus grand (excluant les images de fond, et excluant le contenu affiché en dehors du viewport, par ex. sous la ligne de flottaison) et cohérent (le contenu temporaire tel que les chargeurs ou les écrans de démarrage est ignoré).

Selon les directives de Google, vos pages web devraient avoir un LCP inférieur à 2,5 s, pour au moins 75 % de vos utilisateurs (y compris le trafic desktop et mobile). 

Les causes courantes d'un LCP lent incluent de grands éléments de design tels que des images, des vidéos et des scripts tiers.

Exemple d'optimisation
Optimiser les ressources, utiliser le chargement paresseux et réduire le JS à l'essentiel.

Collecté à partir : analyse du trafic réseau

Temps nécessaire pour que la page web se charge complètement (jusqu'à ce que le Suivi Synthétique détecte aucune autre activité réseau).

Comprendre Complètement Chargé

Le temps de chargement complet est affecté par toutes les requêtes liées au chargement de la page, y compris les ressources téléchargées, car les requêtes n'impactent pas directement l'expérience utilisateur (reciblage, etc.).

Collecté à partir de : API du navigateur

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).

Il a un début et une fin, car des écouteurs (un morceau de JavaScript qui observe les événements de la page pour exécuter du code) peuvent être attachés à l'événement pour déclencher l'exécution de JavaScript lorsque l'événement se déclenche. L'événement Load se déclenche lorsque le document HTML initial a été complètement chargé et analysé (sans attendre que les images et les iframes aient fini de se charger).

Les scripts externes avec un attribut "defer" et/ou "async" ont également été exécutés à ce stade. Ainsi que les feuilles de style avec l'attribut async.

Collecté à partir de : analyse vidéo

L'Index de vitesse est un indice qui reflète la vitesse d'affichage moyenne des composants de la page.

Comprendre l'Index de vitesse
L'Index de vitesse transcrit la vitesse d'affichage moyenne des pixels inclus dans la partie visible de la page web testée (au-dessus de la ligne de flottaison). En conséquence, cet indicateur prend en compte la progressivité d'affichage des différents éléments composant la page (plus la vitesse est faible, mieux c'est).

Google recommande un Index de vitesse inférieur à 1000s.

Exemple d'optimisation
Évitez les appels synchrones aux ressources statiques externes, hébergez localement les CSS et JS importants.

Réduisez la charge JS ou déplacez-les dans le pied de page.

Collecté à partir de : analyse vidéo

Le Début du rendu marque le premier affichage visible sur l'écran de l'utilisateur (avant cela, la page reste vide). Le Début du rendu est déterminé à partir de l'analyse vidéo du chargement de la page web.

Comprendre le Début du rendu
Comme l'analyse vidéo ne concerne que la partie visible de la page web testée (au-dessus de la ligne de flottaison), veuillez noter que le premier élément à être rendu n'est pas nécessairement un élément significatif (cela peut être un élément mineur comme une couleur de fond, un texte ou autre).

Exemples d'optimisation
Rendez le contenu critique disponible sur la page web, sans appels API supplémentaires.
Fournissez le CSS nécessaire pour le contenu en haut de la page dès le début, idéalement en ligne.

Collecté à partir de : analyse du trafic réseau

Le Temps jusqu'au premier octet (TTFB) indique le temps écoulé entre la demande d'une page par le navigateur et la réception du premier morceau de données par l'utilisateur (le code HTML de la page web concernée).

Comprendre le Temps jusqu'au premier octet
Le Temps jusqu'au premier octet est calculé à partir du temps de réponse du serveur web ajouté à la latence du réseau, une résolution DNS et le temps nécessaire pour établir une connexion TCP (et pour établir une connexion sécurisée si votre page web utilise HTTPs).

Les délais de redirection (non seulement 301 & 302 mais aussi les redirections JavaScript côté client) sont inclus dans le TTFB, car nous considérons le premier octet "valable" lié à la page web à charger.

Google recommande que le TTFB de votre site web soit de 200 millisecondes (0,2s) ou moins. La lenteur peut être due au contexte (bande passante à haute latence), à l'état du serveur, à la longueur de la chaîne de certificats, ou aux redirections, entre autres choses.

Exemple d'optimisation
Enquêtez sur les problèmes de cache en amont du backend.

Collecté à partir de : analyse du trafic réseau

Le Temps jusqu'au dernier octet mesure le délai entre la demande envoyée par le navigateur et la réception du dernier octet de la réponse concernée (le dernier morceau du document HTML).

Comprendre le Temps jusqu'au dernier octet (TTLB)
Le TTLB suit directement le Temps jusqu'au premier octet. Le Temps jusqu'au dernier octet compte un délai supplémentaire par rapport au Temps jusqu'au premier octet : le temps nécessaire pour télécharger les données.

Note : La différence entre le temps de début (TTFB) et le temps de fin (TTLB) est généralement mineure, sauf lorsque la page HTML a un poids élevé (par rapport à la bande passante en aval utilisée pour le test de vitesse).

Collecté à partir de : polyfill GoogleChromeLabs (en attente de l'implémentation native du navigateur)

Le Temps jusqu'à l'interaction (tel que proposé par Google) est un indicateur complexe ; le Temps jusqu'à l'interaction n'est pas le moment où une page devient interactive. Le Temps jusqu'à l'interaction est lorsque la page est durablement interactive. Pour plus de clarté, nous avons nommé cet indicateur Temps jusqu'à (Cohérente) Interaction dans le Suivi Synthétique.

Qu'est-ce qui rend une page durablement interactive ?

L'algorithme TTI est basé à la fois sur l'analyse de l'activité JavaScript et du réseau. Il détermine le moment à partir duquel une interaction utilisateur avec la page peut avoir lieu sans risque pour la fluidité de la réaction (pas de "jank", 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 remplies pendant au moins 5 secondes entières pour qu'une interaction se produise de manière satisfaisante. Si une tâche longue se produit dans cette fenêtre de 5 secondes, alors nous recommençons à attendre 5 secondes. Sinon, le Temps jusqu'à (Cohérente) Interaction est défini au début de la plage "silencieuse" de 5 secondes.

S'il n'y a pas de répit dans l'émergence de Longs Tâches (ce qui signifie que le navigateur effectue à plusieurs reprises des tâches qui le ralentissent), alors le Temps jusqu'à (Cohérente) Interaction ne peut pas être calculé, ni les métriques qui en dépendent, telles que le Temps Total de Blocage.

Collecté depuis : Navigateur Web (Long Task API + algorithme simple)

Le Temps de Blocage Total (TBT) mesure le montant total de temps pendant lequel une page est bloquée de répondre aux entrées de l'utilisateur (clics, pressions sur le clavier, etc.) après que la page a commencé à rendre le contenu.

Comment il est calculé
Le calcul du Temps de Blocage Total est basé sur les Longs Tâches. Une Longue Tâche est un traitement qui monopolise le navigateur web pendant un certain temps (>50 millisecondes) et bloque d'autres tâches critiques d'être exécutées (par ex. réagir à l'entrée de l'utilisateur).

Le Temps de Blocage Total est une somme, calculée en ajoutant la portion bloquante de toutes les Longues Tâches entre le Premier Peinture de Contenu et le Temps pour (de manière cohérente) Interactif. La portion bloquante de la longue tâche est la durée en excès de 50 ms.

Exemple d'une page se chargeant avec 3 longues tâches :
[longtask 1 : 55 ms] FCP [longtask 2 : 110 ms] [longtask 3 : 200 ms] TTI

• la longue tâche 1 est ignorée car se produisant avant le FCP
• la portion bloquante de la longue tâche 2 est de 60 ms (110 - 50).
• la portion bloquante de la longue tâche 3 est de 150 ms (200 - 50).
  
  Le Temps de Blocage Total est donc de 210 ms (60 + 150).

Pourquoi le Temps de Blocage Total n'est-il parfois pas calculé ?
Comme le Temps de Blocage Total est calculé entre le Premier Peinture de Contenu (FCP) et le Temps pour (de manière cohérente) Interactif, les deux métriques doivent être définies pour que le TBT existe. Lorsqu'il y a des Longs Tâches récurrents et répétés, il n'y a pas vraiment de moment où l'interface est de manière cohérente interactive, donc il n'y a pas de "fin" à la plage de temps dans laquelle le TBT devrait être calculé.

Si vous devez suivre vos Longs Tâches mais que le TBT ne peut pas être calculé, vous pouvez utiliser la métrique "Somme des Longs Tâches" à la place.

Collecté depuis : analyse vidéo

Visually Complete calcule combien de temps il faut pour que tout le contenu au-dessus de la ligne de flottaison soit visible.

Comprendre Visually Complete

Visually Complete mesure le temps nécessaire pour que la zone au-dessus de la ligne de flottaison soit rendue dans sa forme finale. (Cette métrique est mesurée à partir de l'analyse vidéo du chargement de la page web).

Cet état de rendu final est capturé à la fin de notre analyse, c'est-à-dire lorsque le Synthetic Monitoring a détecté la fin du trafic lié au chargement de la page. En analysant la vidéo, le Synthetic Monitoring identifie alors quand cet état de rendu final a été complété.

Cette détection de l'état final peut être affectée par des animations (comme des carrousels), car le rendu peut changer plusieurs fois alors que la page web semble totalement chargée. Afin de stabiliser vos résultats, le Synthetic Monitoring offre une option pour désactiver les animations.

Exemple d'optimisation
Mettez le de fond dans la couleur dominante pour charger en ligne avec votre CSS. Par ex. Mettez un de fond noir pour une image où le noir est dominant afin de réserver l'espace pendant son temps de chargement.