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
Cinq métriques sont résumées pour la période que vous sélectionnez : LCP, INP, CLS, FCP et TTFB. Chacune affiche sa valeur actuelle, une mention indiquant si cette valeur est bonne ou demande du travail, et une courbe de tendance. 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. Sélectionner les quatre dernières heures les compare aux quatre précédentes, et c’est ce qui vous dit si un chiffre s’améliore ou se dégrade. Quand une tendance montre un pic, vérifiez combien de mesures se cachent derrière avant de le traiter comme une régression. Un pic construit sur une seule mesure est du bruit. 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 sont des métriques d’appui qui aident à expliquer un mauvais LCP : un TTFB lent désigne le serveur ou le réseau, tandis qu’un TTFB rapide avec un LCP lent désigne le front end.Percentiles
Les valeurs sont rapportées au percentile de votre choix : p75, p90 ou p95. Commencez par p75, le percentile sur lequel les seuils de Google sont définis, et celui à utiliser quand vous voulez savoir si une page est bonne ou non. Passez à p90 ou p95 quand vous voulez savoir ce que vivent vos utilisateurs les plus lents : c’est là qu’apparaissent les problèmes que les moyennes masquent.Détail par route
Sous le résumé, chaque route est listée avec son nombre de samples et sa valeur pour chacune des cinq métriques. 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. Trier par LCP fait remonter les pages les plus lentes, et lire une ligne de bout en bout vous dit pourquoi une page est lente :- Un TTFB lent avec un LCP acceptable signifie que votre serveur est le frein.
- Un TTFB rapide avec un mauvais CLS signifie que la page arrive vite mais saute pendant qu’elle finit de charger.
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, ce qui vous permet de lire les chiffres d’une partie de l’application au lieu d’une moyenne sur l’ensemble. 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 :- CLS et INP ne couvrent qu’une partie de vos utilisateurs. Les deux reposent sur des fonctionnalités de navigateur que seuls Chrome et les autres navigateurs Chromium possèdent : les visiteurs sous Safari et Firefox n’y contribuent donc pas. LCP, FCP et TTFB couvrent tout le monde. 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.