Browser monitoring ist ein Beta-Feature von AppSignal Labs. Das Paket
@appsignal/browser wird unter dem beta-Tag auf npm veröffentlicht, und
seine Konfiguration und API können sich zwischen Beta-Releases noch ändern.
Teilen Sie Ihr Feedback in unserer
Discord-Community.Zusammenfassung der web vitals
Für den gewählten Zeitraum werden fünf Metriken zusammengefasst: LCP, INP, CLS, FCP und TTFB. Jede zeigt ihren aktuellen Wert, eine Bewertung, ob dieser Wert gut ist oder Arbeit braucht, und eine Trendlinie. Die Trendlinie unterscheidet eine stabile Zahl von einer, die seit einer Weile steigt. Jeder Zeitraum wird außerdem mit dem gleich langen Zeitraum davor verglichen. Wenn Sie die letzten vier Stunden wählen, werden diese vier Stunden mit den vier davor verglichen, und genau das zeigt Ihnen, ob eine Zahl besser oder schlechter wird. Wenn ein Trend eine Spitze zeigt, prüfen Sie, wie viele Messungen dahinterstehen, bevor Sie sie als Regression behandeln. Eine Spitze aus einer einzigen Messung ist Rauschen. Die Bewertungen stammen aus den Schwellenwerten von Google, die zu jeder Metrik auf der Seite zu web vitals aufgeführt sind. Die drei Core Web Vitals sind LCP, INP und CLS. FCP und TTFB sind unterstützende Metriken, die einen schlechten LCP erklären helfen: Ein langsamer TTFB deutet auf den Server oder das Netzwerk hin, während ein schneller TTFB bei langsamem LCP auf das Front end deutet.Perzentile
Werte werden zu einem Perzentil Ihrer Wahl gemeldet: p75, p90 oder p95. Beginnen Sie mit p75. Es ist das Perzentil, gegen das die Schwellenwerte von Google definiert sind, und das richtige, wenn Sie wissen wollen, ob eine Seite gut ist oder nicht. Wechseln Sie zu p90 oder p95, wenn Sie wissen wollen, womit Ihre langsamsten Nutzer leben. Dort zeigen sich Probleme, die Durchschnittswerte verbergen.Aufschlüsselung pro Route
Unter der Zusammenfassung ist jede Route mit ihrer Anzahl an samples und ihrem Wert für jede der fünf Metriken aufgeführt. Die Anzahl der samples ist genauso wichtig wie die Werte: Eine Route mit vier samples ist ein Hinweis, kein Befund. In dieser Tabelle finden Sie die Arbeit. Sortieren nach LCP bringt die langsamsten Seiten nach oben, und wenn Sie eine Zeile von links nach rechts lesen, erfahren Sie, warum eine Seite langsam ist:- Ein langsamer TTFB bei akzeptablem LCP bedeutet, dass Ihr Server bremst.
- Ein schneller TTFB bei schlechtem CLS bedeutet, dass die Seite schnell ankommt, aber beim Fertigladen umherspringt.
Releases vergleichen
Ein Filter nach App-Version beschränkt die gesamte Ansicht, Zusammenfassung wie Tabelle, auf die Seitenaufrufe, die dieses Release gemeldet hat. Wenn Sie eine Version wählen, werden die Trendlinien damit beschriftet. Das ist der schnellste Weg, die Frage zu beantworten, ob ein Deploy etwas langsamer gemacht hat. Setzen SieappVersion auf Ihren Release-Tag oder Commit-SHA, dann trägt jede Messung diesen Wert.
Nach Route filtern
Ein Filter nach Route schränkt sowohl die Zusammenfassung als auch die Tabelle ein, sodass Sie die Zahlen für einen Teil der Anwendung lesen können, statt einen Durchschnitt über alles. Solche Durchschnitte sind für sich genommen oft nicht hilfreich. Eine schnelle Marketingseite und ein langsames dashboard ergeben zusammen eine einzige Zahl, die keines von beiden beschreibt.Was die Zahlen auslassen
Zwei Dinge, die Sie beim Deuten der Werte im Blick behalten sollten:- CLS und INP erfassen nur einen Teil Ihrer Nutzer. Beide beruhen auf Browser-Funktionen, die nur Chrome und andere Chromium-Browser haben, Besucher mit Safari und Firefox tragen also nichts dazu bei. LCP, FCP und TTFB erfassen alle. Mehr dazu unter Browser-Unterstützung.
- LCP, FCP und TTFB gehören zum Seitenaufruf, nicht zur Route. Der Browser misst sie einmal, beim ersten Laden der Seite. In einer Single-Page-Anwendung gehören sie zu der Route, die der Nutzer zuerst geöffnet hat, nicht zu denen, zu denen er danach gewechselt ist. CLS und INP werden pro Route gemessen. Mehr dazu unter Wie Werte Routen zugeordnet werden.