HTML-Tools

Kostenlose PerformanceObserver Snippet Generator

Generieren Sie PerformanceObserver-Code fur Core Web Vitals (LCP, INP, CLS) mit good/needs-improvement/poor-Schwellenwerten.

Tool wird geladen...

Was ist PerformanceObserver Snippet Generator?

PerformanceObserver ist eine Browser-API, die es Entwicklern ermöglicht, Performance-Messungsereignisse in Echtzeit zu beobachten. Anstatt die Performance-Zeitleiste abzufragen oder sich auf manuelle Timing-Messungen zu verlassen, abonniert PerformanceObserver bestimmte Eintragstypen (wie largest-contentful-paint, layout-shift, first-input, paint und navigation) und empfängt Einträge, sobald sie aufgezeichnet werden. Dies ist der von der Web Performance Working Group empfohlene Standardansatz zur Messung von Core Web Vitals. Die API unterstützt ein buffered-Flag, das historische Einträge sofort bei der Registrierung zurückgibt, sodass Sie keine Metriken verpassen, die vor der Einrichtung Ihres Observers gefeuert wurden. Baseline 2025, unterstützt in Chrome 73+, Edge 73+, Safari 14.1+ und Firefox 84+.

Kurze Antwort

PerformanceObserver bietet Echtzeit-Überwachung der Core Web Vitals (LCP, INP, CLS, FID, FCP, TTFB) durch ein effizientes Observer-Muster mit gepufferter Eintragsunterstützung. Klassifizieren Sie jede Metrik anhand der Google-Schwellenwerte (good/needs-improvement/poor) und berichten Sie optional per navigator.sendBeacon für zuverlässige Analytics-Zustellung. Baseline 2025 (Chrome 73+, Safari 14.1+, Firefox 84+). Effizienter als Polling und der empfohlene Ansatz für die Produktionsmessung von Web Vitals.

Last updated: 2026-06-02

Einschränkungen

PerformanceObserver-Einträge bleiben nicht über Seitennavigationen hinweg erhalten - jeder Seitenaufbau beginnt mit einer frischen Zeitleiste. Bei SPA-Routenänderungen müssen Observer manuell neu verbunden werden, um die Verfolgung von Metriken auf der neuen Route fortzusetzen.
Einige Performance-Eintragstypen haben browserspezifische Verfügbarkeit oder Verhalten. Zum Beispiel sind layout-shift-Einträge nicht in allen Browsern verfügbar (Firefox hat Unterstützung in Version 134 hinzugefügt), und INP-Beobachtung erfordert Chrome 121+ oder Safari 18+. Prüfen Sie immer die Unterstützung, bevor Sie Observer registrieren.
PerformanceObserver hat einen begrenzten Puffer für jeden Eintragstyp. Wenn der Puffer gefüllt ist, bevor der Observer registriert wird und buffered: true nicht gesetzt ist, können ältere Einträge verworfen werden. Registrieren Sie Observer früh im Seitenladelebenszyklus und verwenden Sie buffered: true, um Einträge zu erfassen, die während des kritischen Rendering-Pfads gefeuert wurden.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

So nutzt du dieses Tool

Wählen Sie die zu beobachtenden Performance-Metriken aus: Core Web Vitals (LCP, INP, CLS, FID, FCP, TTFB) oder einzelne Eintragstypen wie paint, layout-shift, largest-contentful-paint, first-input und navigation.
Konfigurieren Sie die Schwellenwertklassifizierung: jede Metrik wird automatisch als good, needs-improvement oder poor basierend auf den Google Web Vitals Schwellenwerten klassifiziert. Passen Sie die Schwellenwerte optional für Ihre spezifischen Anforderungen an.
Wählen Sie eine Berichtsmethode: protokollieren Sie Ergebnisse in der Konsole, senden Sie Daten per navigator.sendBeacon an einen Analytics-Endpunkt oder geben Sie eine benutzerdefinierte Callback-Funktion zur Integration mit Ihrem bestehenden Monitoring an.
Kopieren Sie das generierte JavaScript-Snippet. Die Ausgabe enthält ein vollständiges PerformanceObserver-Setup mit mehreren Observern, gepufferter Eintragsunterstützung, Schwellenwertklassifizierung und optionaler sendBeacon-Berichterstattung.

Wofür du es nutzen kannst

Verfolgen Sie Core Web Vitals in der Produktion und berichten Sie sie an einen Analytics-Endpunkt mit sendBeacon für zuverlässige, nicht blockierende Datenübertragung auch während des Seitenentladens.
Überwachen Sie LCP in Echtzeit während der Entwicklung, um zu überprüfen, ob Performance-Optimierungen (Bildkompression, Schriftartenladen, Lazy Loading) die LCP-Zeiten tatsächlich reduzieren.
Erkennen Sie unerwartete Layout-Verschiebungen (CLS) auf einer Live-Seite, indem Sie jeden layout-shift-Eintrag mit seinem Shift-Score und den betroffenen Knoten protokollieren.

Anwendungsfalle

Praxisbeispiele

Beispiel

Produktions-Core-Web-Vitals-Monitoring mit sendBeacon

Eine E-Commerce-Seite setzt das generierte PerformanceObserver-Snippet auf ihren Produktseiten ein. Der Observer verfolgt LCP, INP, CLS, FCP und TTFB. Jede Metrik wird gegen Google-Schwellenwerte klassifiziert: good LCP unter 2500ms, needs-improvement 2500-4000ms, poor über 4000ms. Metriken werden alle 30 Sekunden per navigator.sendBeacon an /analytics/cwv gesendet. Das Team richtet Dashboard-Benachrichtigungen ein, wenn eine Seite 10% poor LCP oder poor CLS über 0,25 überschreitet.

Beispiel

LCP-Debugging während der Entwicklung mit detaillierter Protokollierung

Ein Entwickler, der an Bildoptimierung arbeitet, fügt einen PerformanceObserver für largest-contentful-paint-Einträge mit Konsolenprotokollierung hinzu. Jeder LCP-Eintrag zeigt das Element-Tag, seine URL für Bilder, Renderzeit und Größe. Durch den Vergleich von LCP-Einträgen vor und nach der Umstellung auf moderne Formate und dem Hinzufügen von fetchpriority='high' zum Hero-Bild bestätigt der Entwickler eine 40-prozentige Reduzierung der LCP-Zeit.

Haufige Fehler

PerformanceObserver nach dem Seitenladen ohne das buffered-Flag zu registrieren - Metriken wie FCP und TTFB feuern vor der Ausführung des meisten JavaScripts. Setzen Sie immer buffered: true in den Observer-Optionen, um historische Einträge zu erhalten, die vor der Registrierung des Observers aufgezeichnet wurden.
layout-shift-Einträge zu beobachten, ohne hadRecentInput zu prüfen - viele Layout-Verschiebungen treten während Benutzerinteraktionen (Tippen, Klicken, Größenändern) auf und sollten nicht zu CLS zählen. Filtern Sie Einträge heraus, bei denen hadRecentInput true ist, um der Google CLS-Definition zu entsprechen.
Performance-Daten synchron beim Seitenentladen zu senden anstatt sendBeacon zu verwenden - reguläre fetch- oder XHR-Anfragen während des Entladens können vom Browser abgebrochen werden. navigator.sendBeacon garantiert die Zustellung durch die Verwendung der Browser-Hintergrundverarbeitungswarteschlange.

Überprüfung

Öffnen Sie das generierte HTML in Chrome DevTools auf einer Seite mit ausreichend Inhalt. Öffnen Sie die Konsole und überprüfen Sie, dass PerformanceObserver jede registrierte Metrik mit ihrem Wert, ihrer Klassifizierung (good/needs-improvement/poor) und ihrem Eintragstyp protokolliert. Scrollen Sie nach unten, interagieren Sie mit der Seite und bestätigen Sie, dass INP- und CLS-Einträge nach Benutzerinteraktion erscheinen.
Konfigurieren Sie den Observer für die Verwendung von sendBeacon-Berichterstattung und geben Sie eine gültige Endpunkt-URL an. Laden Sie die Seite und prüfen Sie dann den Network-Tab in DevTools auf eine Beacon-Anfrage mit Performance-Daten. Überprüfen Sie, dass die Payload Metriknamen, Werte, Schwellenwertklassifizierungen und einen Zeitstempel enthält.

FAQ

Fragen zu PerformanceObserver Snippet Generator

Welche Performance-Metriken kann PerformanceObserver außer Core Web Vitals überwachen?

PerformanceObserver unterstützt über 15 Eintragstypen, darunter mark, measure, resource, navigation, paint, largest-contentful-paint, first-input, layout-shift, longtask, element, visibility-state und event für INP. Das generierte Snippet konzentriert sich auf Core Web Vitals, aber Sie können es erweitern, um jeden unterstützten Eintragstyp zu beobachten, indem Sie den entsprechenden Typ-String zur Liste der beobachteten Eintragstypen hinzufügen.

Wie handhabt PerformanceObserver mehrere Observer für denselben Metriktyp?

Mehrere PerformanceObserver-Instanzen können denselben Eintragstyp gleichzeitig ohne Konflikte beobachten. Jeder Observer empfängt unabhängig eine Kopie der Einträge. Dies ist nützlich zur Trennung von Belangen - zum Beispiel sendet ein Observer Daten an Analytics, während ein anderer detaillierte Debug-Informationen in der Konsole protokolliert. Jeder Observer muss einzeln über observer.disconnect() getrennt werden, wenn er nicht mehr benötigt wird.

Bleiben PerformanceObserver-Einträge über Seitennavigationen in einer SPA erhalten?

Nein. PerformanceObserver-Einträge werden pro Navigation gesammelt und gelöscht, wenn die Seite verlassen wird. In Single-Page-Anwendungen mit clientseitigem Routing müssen Sie Observer nach jedem Routenwechsel neu verbinden. Das generierte Snippet enthält eine Hilfsfunktion, die alle Observer bei Routenänderungsereignissen neu verbindet. Für Cross-Origin-Navigationen sind Performance-Einträge der vorherigen Seite nicht zugänglich.

Welche good/needs-improvement/poor-Schwellenwerte verwendet der generierte Code?

Die Schwellenwerte folgen den Google Web Vitals Richtlinien. LCP unter 2500ms ist good, 2500-4000ms needs improvement, über 4000ms ist poor. FID unter 100ms ist good, 100-300ms needs improvement, über 300ms ist poor. CLS unter 0,1 ist good, 0,1-0,25 needs improvement, über 0,25 ist poor. INP unter 200ms ist good, 200-500ms needs improvement, über 500ms ist poor. FCP folgt den LCP-Schwellenwerten (2500ms/4000ms). TTFB unter 800ms ist good, 800-1800ms needs improvement, über 1800ms ist poor. Alle Schwellenwerte sind im generierten Snippet konfigurierbar.

Verwandte Tools