Was ist die User Timing API?

Was ist die User Timing API?

Die User Timing API gehört zur Web Performance API. Mit ihr setzt Ihr eigenes JavaScript benannte Zeitstempel (Marks) und die Zeit dazwischen (Measures) auf die hochauflösende Performance Timeline des Browsers. So messen Sie Schritte, die nur Ihre App kennt, etwa "Suchergebnisse gerendert" oder "Checkout-Formular bereit".

So funktioniert es

• performance.mark(name) erzeugt zum aktuellen Zeitpunkt ein PerformanceMark (Eintragstyp mark). Optionen: startTime und detail.
• performance.measure(name, startMark, endMark) erzeugt ein PerformanceMeasure (Eintragstyp measure). Seine duration ist Ende minus Start. Alternativ übergeben Sie ein Optionsobjekt mit start, end, duration und detail. Ohne Ende endet die Messung jetzt.
• Einträge lesen Sie mit einem PerformanceObserver, laut MDN der bevorzugte Weg, oder mit performance.getEntriesByType('measure'). Entfernen können Sie sie mit clearMarks() und clearMeasures().

Im Performance-Panel der Chrome DevTools erscheint ein Mark, dessen detail ein devtools-Objekt mit dataType: 'marker' enthält, in der Spur "Timings". Measures mit dataType: 'track-entry' zeichnen eigene Spuren (in den Aufnahmeeinstellungen "Show custom tracks" aktivieren). Die Unterstützung dieser Erweiterung hängt vom Browser ab. Details: MDN.

Beispiel

So messen Sie, wie lange eine Suche von der Anfrage bis zu den gerenderten Ergebnissen dauert:

performance.mark('search-start');
const data = await fetch('/api/search?q=shoes').then(r => r.json());
renderResults(data);
performance.mark('search-rendered');
performance.measure('search-total', 'search-start', 'search-rendered');
const [m] = performance.getEntriesByName('search-total');
console.log(m.duration);

Das Ergebnis ist ein Eintrag search-total mit einer Dauer in Millisekunden, sichtbar im Code und in den Entwicklertools.

User Timing im Vergleich zu den Nachbarn

Navigation Timing deckt die eingebauten Phasen des Seitenladens ab, der Server-Timing-Header liefert Backend-Zeiten. User Timing ist für die Schritte dazwischen, die nur Ihr Code benennen kann. Senden Sie die Messwerte an Ihre Analytics, haben Sie Real User Monitoring für Ihre eigenen Abläufe. Für Seitenladezeit und Core Web Vitals von festen Standorten siehe LoadFocus Page-Speed-Monitoring. Einen breiteren Überblick gibt der Leitfaden zu Frontend-Performance-Tests.

Häufige Fehler

• Messen, bevor die End-Marke existiert. Eine fehlende benannte Marke löst einen SyntaxError aus.
• Optionsformen vermischen. duration ist nur mit genau einem von start oder end gültig, sonst gibt es einen TypeError.
• Einen Namen für verschiedene Schritte wiederverwenden. getEntriesByName() liefert dann mehrere Einträge, benennen Sie jeden Schritt eindeutig.
• Einträge in einer langlebigen Single-Page-App nie löschen. Löschen Sie Marks und Measures, die Sie schon gemeldet haben.
• Marks in engen Schleifen setzen. Das überflutet die Timeline und versteckt die wichtigen Schritte.

Häufige Fragen: User Timing API

Was ist der Unterschied zwischen Mark und Measure?

Ein Mark ist ein benannter Zeitpunkt. Ein Measure ist die Dauer zwischen zwei Punkten, das können zwei Marks, Zeitstempel oder je eines davon sein.

Brauche ich einen PerformanceObserver?

Nein, er ist aber die bessere Wahl, weil er Sie bei neuen Einträgen benachrichtigt. Die get-Methoden liefern nur bereits vorhandene Einträge.

Wie sehe ich Marks und Measures in den DevTools?

Zeichnen Sie im Performance-Panel ein Profil auf. Mit einem devtools-Objekt in detail landen Marker in der Spur "Timings" und Measures in eigenen Spuren.

Ist das dasselbe wie performance.now()?

Nein. performance.now() liefert einen Zeitstempel. User Timing legt benannte Einträge auf der Performance-Timeline ab, die Tools und Observer lesen können.

Funktioniert es in Web Workern?

Ja, MDN führt performance.measure() als in Workern verfügbar auf.