> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser web vitals

<Note>
  Browser monitoring ist ein Beta-Feature von [AppSignal Labs](/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](https://discord.gg/EjF6ykYx63).
</Note>

Web vitals messen, wie schnell eine Seite lädt und reagiert. Sie zeigen außerdem, ob sich ihr Layout unerwartet verschiebt. AppSignal misst sie auf den Geräten und Verbindungen echter Nutzer.

Die Erfassung beginnt mit `init()`. Es gibt nichts zu konfigurieren.

<h2 id="what-each-metric-measures">
  Was jede Metrik misst
</h2>

| Metrik | Was sie misst | Gut | Verbesserungsbedarf | Schlecht |
| - | - | - | - | - |
| LCP (Largest Contentful Paint) | Wie lange das größte sichtbare Element zum Rendern braucht. | ≤ 2.500 ms | 2.500–4.000 ms | > 4.000 ms |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf eine Interaktion reagiert. | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark sich das Layout beim Laden unerwartet verschiebt. | ≤ 0,1 | 0,1–0,25 | > 0,25 |
| FCP (First Contentful Paint) | Wie lange es dauert, bis der erste Inhalt erscheint. | ≤ 1.800 ms | 1.800–3.000 ms | > 3.000 ms |
| TTFB (Time to First Byte) | Wie lange der Server braucht, um mit der Antwort zu beginnen. | ≤ 800 ms | 800–1.800 ms | > 1.800 ms |

LCP, INP und CLS sind die drei Core Web Vitals. FCP und TTFB helfen dabei, einen schlechten LCP zu erklären. Ein langsamer TTFB deutet auf den Server oder das Netzwerk hin. Ein schneller TTFB bei langsamem LCP deutet auf das Laden von Ressourcen oder das Rendering hin.

Jeder Wert wird an diesen Schwellenwerten bewertet. AppSignal versieht jeden Wert in der Zusammenfassung mit einer Bewertung. Die Tabelle pro Route verwendet dieselben Bewertungen.

<h2 id="how-values-are-attributed-to-routes">
  Wie Werte Routen zugeordnet werden
</h2>

LCP, FCP und TTFB messen den Seitenaufruf. Der Browser misst jeden davon einmal, beim ersten Laden der Seite, und danach nie wieder. In einer Single-Page-Anwendung gehören sie zu der zuerst geladenen Route. Spätere clientseitige Routen erhalten keine neuen Lade-Metriken. Sie erneut pro Route zu messen, bräuchte eine Browser-Funktion, die noch experimentell ist.

CLS und INP können sich aufbauen, solange eine Seite geöffnet ist. Unterstützt der Browser das, ordnet AppSignal beobachtete Werte der aktiven Route zu. Bei einer Navigation setzt es diese Werte zurück.

Damit Routen getrennt und lesbar bleiben, teilen Sie AppSignal bei jeder Navigation Ihres Routers das Route-Template mit:

<CodeGroup>
  ```js JavaScript theme={null}
  import { setRouteTemplate } from "@appsignal/browser";

  setRouteTemplate("/orders/:id");
  ```
</CodeGroup>

Ohne Template ersetzt der Prozessor erkennbare IDs in Web-vital-URLs, etwa Zahlen und UUIDs. Für Ihre App spezifische IDs kann er dabei übersehen. Fehler verwenden den Rohpfad, sofern Sie kein Template setzen, ein Aufruf verbessert also auch die [Fehlergruppierung](/browser/error-tracking#how-errors-are-grouped).

Es gibt einen zweiten Grund für Templates. AppSignal behält nur eine begrenzte Anzahl separater Routen pro Anwendung. Sobald Sie darüber hinausgehen, werden die übrigen zu einer unbenannten Gruppe zusammengefasst, die der Routen-Filter auslässt. Ohne explizite Templates kann dieses Limit bei Routen, deren IDs der Prozessor nicht erkennt, früher erreicht werden.

<h2 id="when-values-are-sent">
  Wann Werte gesendet werden
</h2>

Web vitals werden gestapelt und an Seiten- und Routengrenzen gesendet:

* Wenn die Seite verborgen wird, was das Wechseln von Tabs und das Verschieben der App in den Hintergrund abdeckt.
* Wenn die Seite geschlossen oder verlassen wird.
* Bei einem clientseitigen Routenwechsel.

Wenn eine Seite abstürzt oder erzwungen beendet wird, bevor eines davon passiert, wird für diesen Besuch nichts aufgezeichnet.

Bei Hash-basierten Routern behandelt AppSignal `#/orders` als Navigation. Einen einfachen Anker auf derselben Seite, etwa `#pricing`, behandelt es nicht als solche.

<h2 id="browser-support">
  Browser-Unterstützung
</h2>

Das SDK meldet eine Metrik nur, wenn der Browser die dafür nötigen Performance-Einträge bereitstellt. CLS benötigt `layout-shift`, INP benötigt `event-timing`. Browser ohne diese Entry-Typen tragen zu diesen Metriken nichts bei. LCP, FCP und TTFB werden, sofern verfügbar, über die `web-vitals`-Bibliothek erfasst.

<h2 id="reviewing-performance-in-appsignal">
  Performance in AppSignal ansehen
</h2>

Die Performance-Ansicht fasst jede Metrik für den gewählten Zeitraum zusammen. Filtern Sie sie nach Perzentil, Zeit, App-Version oder Route. Mehr dazu unter [Front-end-Performance in AppSignal](/browser-monitoring/performance).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.