Skip to main content
Browser monitoring est une fonctionnalité en beta d’AppSignal Labs. Le package @appsignal/browser est publié sous le tag beta sur npm, et sa configuration ainsi que son API peuvent encore changer d’une release beta à l’autre. Partagez vos retours dans notre communauté Discord.
Les web vitals mesurent la rapidité avec laquelle une page se charge et répond. Elles indiquent aussi si sa mise en page se décale de façon inattendue. AppSignal les mesure sur les appareils et les connexions des utilisateurs réels. La collecte démarre avec init(). Il n’y a rien à configurer.

​
Ce que mesure chaque métrique

LCP, INP et CLS sont les trois Core Web Vitals. FCP et TTFB aident à expliquer un mauvais LCP. Un TTFB lent désigne le serveur ou le réseau. Un TTFB rapide avec un LCP lent oriente plutôt vers le chargement des ressources ou le rendu. Chaque valeur est évaluée par rapport à ces seuils. AppSignal étiquette chaque valeur du résumé avec une évaluation. Le tableau par route utilise les mêmes évaluations.

​
Comment les valeurs sont attribuées aux routes

LCP, FCP et TTFB mesurent le chargement de la page. Le navigateur mesure chacun d’eux une fois, au premier chargement de la page, et plus jamais ensuite. Dans une application monopage, ils appartiennent à la route chargée en premier. Les routes côté client suivantes ne reçoivent pas de nouvelles métriques de chargement. Les mesurer de nouveau à chaque route nécessiterait une fonctionnalité de navigateur encore expérimentale. CLS et INP peuvent s’accumuler tant qu’une page reste ouverte. Quand le navigateur les prend en charge, AppSignal attribue les valeurs observées à la route active. Il les réinitialise à chaque navigation. Pour que les routes restent distinctes et lisibles, indiquez à AppSignal le template de route à chaque navigation de votre routeur :
Sans template, le processeur remplace les ID reconnaissables dans les URL de web vitals, comme les nombres et les UUID. Il peut passer à côté d’ID propres à votre application. Les erreurs utilisent le chemin brut tant que vous ne définissez pas de template, un seul appel améliore donc aussi le regroupement des erreurs. Il y a une seconde raison d’utiliser des templates. AppSignal ne conserve qu’un nombre limité de routes distinctes par application. Au-delà, les autres sont regroupées dans un unique groupe sans nom que le filtre de route laisse de côté. Sans templates explicites, les routes dont le processeur ne reconnaît pas les ID peuvent atteindre cette limite plus tôt.

​
Quand les valeurs sont envoyées

Les web vitals sont regroupées par lots et envoyées aux frontières de page et de route :
  • Quand la page est masquée, ce qui couvre le changement d’onglet et le passage de l’application en arrière-plan.
  • Quand la page est fermée ou quittée.
  • Lors d’un changement de route côté client.
Si une page plante ou est fermée de force avant qu’un de ces événements se produise, rien n’est enregistré pour cette visite. Pour les routeurs basés sur le hash, AppSignal traite #/orders comme une navigation. Il ne traite pas une simple ancre sur la page, comme #pricing, comme telle.

​
Prise en charge par les navigateurs

Le SDK ne signale une métrique que si le navigateur fournit les entrées de performance nécessaires pour la mesurer. CLS nécessite layout-shift ; INP nécessite event-timing. Les navigateurs sans ces types d’entrée ne contribuent pas à ces métriques. LCP, FCP et TTFB sont collectées via la bibliothèque web-vitals quand elle est disponible.

​
Examiner les performances dans AppSignal

La vue Performance résume chaque métrique pour la période sélectionnée. Filtrez-la par percentile, période, version d’application ou route. Pour en savoir plus, consultez les performances front-end dans AppSignal.