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.Résumé des web vitals
La vue comporte des tuiles pour cinq métriques : LCP, INP, CLS, FCP et TTFB. Les valeurs, évaluations et tendances apparaissent dès que des mesures sont disponibles. C’est la courbe de tendance qui distingue un chiffre stable d’un chiffre qui grimpe. Chaque période est également comparée à celle qui la précède, de même durée. Par exemple, sélectionner les quatre dernières heures les compare aux quatre précédentes. Cela montre si une valeur a changé. Quand une tendance montre un pic, vérifiez combien de mesures se cachent derrière. Une seule mesure ne suffit pas à établir une régression. Les évaluations proviennent des seuils de Google, listés avec chaque métrique sur la page des web vitals. Les trois Core Web Vitals sont LCP, INP et CLS. 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 vers le chargement des ressources ou le rendu.Percentiles
Les valeurs sont rapportées au percentile de votre choix : p75, p90 ou p95. Commencez par p75. Les seuils de Google s’appuient sur ce percentile pour évaluer les Core Web Vitals. Utilisez p90 ou p95 pour voir les expériences plus lentes qu’une moyenne peut masquer.Détail par route
Sous le résumé, le tableau affiche jusqu’à 20 pages, avec un nombre de samples et les métriques disponibles pour chacune. Le nombre de samples compte autant que les valeurs : une route avec quatre samples est un indice, pas un constat. C’est dans ce tableau que vous trouvez le travail à faire. Le tableau priorise les pages avec le plus de mesures, puis trie celles qui s’affichent par LCP. Comparez les métriques d’une même ligne pour trouver des indices :- Un TTFB lent indique du temps passé à attendre le serveur ou le réseau avant que le rendu puisse commencer.
- Un TTFB rapide avec un mauvais CLS signifie que la réponse démarre vite, mais que la mise en page se déplace de façon inattendue.
Comparer des releases
Filtrer par version d’application restreint toute la vue, résumé comme tableau, aux chargements de page rapportés par cette release. Sélectionner une version étiquette également les courbes de tendance avec celle-ci. C’est le moyen le plus rapide de savoir si un deploy a ralenti quelque chose. DéfinissezappVersion avec votre tag de release ou votre SHA de commit, et chaque mesure le porte.
Filtrer par route
Filtrer par route restreint à la fois le résumé et le tableau. Vous pouvez alors examiner une seule partie de l’application. Ces moyennes sont souvent peu utiles à elles seules. Une page marketing rapide et un dashboard lent se combinent en un chiffre unique qui ne décrit ni l’un ni l’autre.Ce que les chiffres laissent de côté
Deux points à garder en tête pour interpréter ce que vous voyez :- La disponibilité des métriques varie selon le navigateur. CLS et INP nécessitent des entrées de performance spécifiques ; les navigateurs qui ne les prennent pas en charge ne contribuent donc pas à ces valeurs. Pour en savoir plus, consultez la prise en charge par les navigateurs.
- LCP, FCP et TTFB appartiennent au chargement de page, pas à la route. Le navigateur les mesure une fois, au premier chargement de la page. Dans une application monopage, ils appartiennent à la route que l’utilisateur a ouverte en premier, pas à celles vers lesquelles il s’est déplacé ensuite. CLS et INP sont mesurés par route. Pour en savoir plus, consultez comment les valeurs sont attribuées aux routes.