Aufschlüsselung der Performance API

Die Performance API von JavaScript ist ratsam, da sie Werkzeuge zur *genauen* Messung der Performance von Webseiten bereitstellt, was, obwohl schon lange zuvor praktiziert, nie wirklich einfach oder präzise genug wurde.

Allerdings ist es nicht so einfach, mit der API zu beginnen, wie sie tatsächlich zu nutzen. Obwohl ich gesehen habe, dass Erweiterungen davon hier und da in anderen Beiträgen behandelt werden, ist das Gesamtbild, das alles zusammenhält, schwer zu finden.

Ein Blick auf jedes Dokument, das die globale performance-Schnittstelle (der Zugangspunkt für die Performance API) erklärt, und Sie werden mit einer Flut von anderen Spezifikationen bombardiert, darunter die High Resolution Time API, die Performance Timeline API und die Navigation API, unter dem Gefühl von vielen, vielen anderen. Das reicht aus, um das übergreifende Konzept mehr als verwirrend zu machen, was die API *genau* misst, aber vor allem, um die spezifischen Vorteile, die wir damit erhalten, leicht zu übersehen.

Hier ist eine Veranschaulichung, wie all diese Teile zusammenpassen. Das kann sehr verwirrend sein, daher kann ein visuelles Hilfsmittel helfen, zu klären, worüber wir sprechen.

Wollen wir mal eintauchen?

High Resolution Time API

Die performance-Schnittstelle ist Teil der High Resolution Time API.

„Was ist High Resolution Time?“, könnten Sie fragen. Das ist ein Schlüsselkonzept, das wir nicht übersehen dürfen.

Eine auf Date basierende Zeit ist auf die Millisekunde genau. Eine High-Resolution-Zeit hingegen ist präzise bis auf Bruchteile von Millisekunden. Das ist ziemlich präzise und macht sie ideal für genaue Zeitmessungen.

Es ist erwähnenswert, dass eine High-Resolution-Zeit, die vom User Agent (UA) gemessen wird, sich bei Änderungen der Systemzeit nicht ändert, da sie von einer globalen, monoton steigenden Uhr stammt, die vom UA erstellt wird. Die Zeit steigt *immer* und kann nicht reduziert werden. Das ist eine nützliche Einschränkung für die Zeitmessung.

Jede Zeitmessung in der Performance API ist eine High-Resolution-Zeit. Das macht sie nicht nur zu einer sehr präzisen Methode zur Messung der Performance, sondern auch dazu, dass die API ein *Teil* der High Resolution Time API ist und warum wir die beiden oft zusammen erwähnt sehen.

Performance Timeline API

Die Performance Timeline API ist eine Erweiterung der Performance API. Das bedeutet, dass dort, wo die Performance API Teil der High Resolution Time API ist, die Performance Timeline API Teil der Performance API ist.

Oder, um es prägnanter auszudrücken:

High Resolution Time API
└── Performance API
    └── Performance Timeline API

Die Performance Timeline API gibt uns Zugriff auf *fast* alle Messungen und Werte, die wir aus der gesamten Performance API selbst erhalten können. Das sind viele Informationen auf unseren Fingerspitzen mit einer einzigen API, und deshalb zeigt das Diagramm am Anfang dieses Artikels sie fast auf derselben Ebene.

Es gibt viele Erweiterungen der Performance API. Jede von ihnen liefert Performance-bezogene Einträge, und *alle davon* können über die Performance Timeline abgerufen und sogar gefiltert werden, was sie zu einer unverzichtbaren API für jeden macht, der mit Performance-Messungen beginnen möchte. Sie sind so eng miteinander verbunden und ergänzen sich, dass es sinnvoll ist, mit beiden vertraut zu sein.

Die folgenden sind drei Methoden der Performance Timeline API, die in der performance-Schnittstelle enthalten sind:

• getEntries()
• getEntriesByName()
• getEntriesByType()

Jede Methode gibt eine Liste von (optional gefilterten) Performance-Einträgen zurück, die aus allen anderen Erweiterungen der Performance API gesammelt wurden, und wir werden uns im weiteren Verlauf damit vertrauter machen.

Eine weitere wichtige Schnittstelle, die in der API enthalten ist, ist PerformanceObserver. Sie beobachtet neue Einträge in einer gegebenen Liste von Performance-Einträgen und benachrichtigt darüber. Ziemlich praktisch für die Echtzeitüberwachung!

Die Performance-Einträge

Die Dinge, die wir mit der Performance API messen, werden als „Einträge“ bezeichnet und sie alle bieten viel Einblick in die Webperformance.

Neugierig, was sie sind? MDN hat eine vollständige Liste, die wahrscheinlich aktualisiert wird, wenn neue Elemente veröffentlicht werden, aber das ist, was wir derzeit haben:

Eintrag	Was es misst	Übergeordnete API
frame	Misst Frames, die eine Schleife der Arbeit darstellen, die ein Browser benötigt, um Dinge wie DOM-Ereignisse, Größenänderungen, Scrollen und CSS-Animationen zu verarbeiten.	Frame Timing API
Mark	Erstellt einen Zeitstempel in der Performance-Timeline, der Werte für einen Namen, eine Startzeit und eine Dauer liefert.	User Timing API
measure	Ähnlich wie mark, insofern als es Punkte auf der Timeline sind, aber sie sind für Sie benannt und zwischen Marks platziert. Grundsätzlich sind sie ein Mittelpunkt zwischen Marks ohne benutzerdefinierten Namen.	User Timing API
navigation	Bietet Kontext für den Ladevorgang, wie z. B. die Arten von Ereignissen, die auftreten.	Navigation Timing API
paint	Meldet Momente, in denen Pixel auf dem Bildschirm gerendert werden, wie z. B. First Paint, First Paint mit Inhalt, Startzeit und Gesamtdauer.	Paint Timing API
resource	Misst die Latenz von Abhängigkeiten für die Darstellung des Bildschirms, wie Bilder, Skripte und Stylesheets. Hier macht Caching einen Unterschied!	Resource Timing API

Betrachten wir einige Beispiele, die veranschaulichen, wie jede API in der Anwendung aussieht. Um mehr über sie zu erfahren, können Sie die Spezifikationen in der obigen Tabelle nachschlagen. Die Frame Timing API ist noch in Arbeit.

Die Paint Timing API wurde, wie der Name schon sagt, bereits ausführlich auf CSS-Tricks behandelt, aber hier ist ein Beispiel für das Abrufen des Zeitstempels für den Beginn des Renderns:

// Time when the page began to render 
console.log(performance.getEntriesByType('paint')[0].startTime)

Die User Timing API kann die Performance von Entwickler-Skripten messen. Zum Beispiel, wenn Sie Code haben, der eine hochgeladene Datei validiert. Wir können messen, wie lange die Ausführung dauert.

// Time to console-print "hello"
// We could also make use of "performance.measure()" to measure the time
// instead of calculating the difference between the marks in the last line.
performance.mark('')
console.log('hello')
performance.mark('')
var marks = performance.getEntriesByType('mark')
console.info(`Time took to say hello ${marks[1].startTime - marks[0].startTime}`)

Die Navigation Timing API zeigt Metriken für das Laden der aktuellen Seite, sogar Metriken vom Entladen der vorherigen Seite. Wir können mit hoher Präzision messen, wie lange eine aktuelle Seite zum Laden benötigt.

// Time to complete DOM content loaded event
var navEntry = performance.getEntriesByType('navigation')[0]
console.log(navEntry.domContentLoadedEventEnd - navEntry.domContentLoadedEventStart)

Die Resource Timing API ist der Navigation Timing API ähnlich, insofern als sie Ladezeiten misst, außer dass sie alle Metriken für das Laden der angeforderten *Ressourcen* einer aktuellen Seite misst, anstatt der aktuellen Seite selbst. Zum Beispiel können wir messen, wie lange ein auf einem anderen Server gehostetes Bild, wie z. B. ein CDN, zum Laden auf der Seite benötigt.

// Response time of resources
performance.getEntriesByType('resource').forEach((r) => {
console.log(`response time for ${r.name}: ${r.responseEnd - r.responseStart}`);
});

Die Navigationsanomalie

Wollen Sie eine interessante Anekdote über die Navigation Timing API hören?

Sie wurde *vor* der Performance Timeline API konzipiert. Deshalb können Sie zwar einige Navigationsmetriken über die Performance Timeline API abrufen (durch Filterung des navigation-Eintrags), aber die Navigation Timing API selbst hat zwei Schnittstellen, die direkt von der Performance API abgeleitet sind:

• performance.timing
• performance.navigation

Alle von performance.navigation bereitgestellten Metriken können von navigation-Einträgen der Performance Timeline API bereitgestellt werden. Die Metriken, die Sie von performance.timing abrufen, sind jedoch nur teilweise über die Performance Timeline API zugänglich.

Daher verwenden wir performance.timing, um die Navigationsmetriken für die aktuelle Seite zu erhalten, anstatt die Performance Timeline API über performance.getEntriesByType("navigation") zu verwenden.

// Time from start of navigation to the current page to the end of its load event
addEventListener('load', () => {
	with(performance.timing) 
		console.log(navigationStart - loadEventEnd);
})

Fassen wir zusammen

Ich würde sagen, Ihr bester Ansatz, um mit der Performance API zu beginnen, ist, sich zunächst mit allen Performance-Eintragsarten und ihren Attributen vertraut zu machen. Dies wird Sie schnell mit den Endergebnissen aller APIs vertraut machen – und mit der Leistung, die diese API für die Messung der Performance bietet.

Als zweiter Schritt machen Sie sich damit vertraut, wie die Performance Timeline API diese verfügbaren Metriken durchdringt. Wie wir bereits erwähnt haben, sind die beiden eng miteinander verbunden, und das Zusammenspiel zwischen ihnen kann interessante und hilfreiche Messmethoden eröffnen.

Zu diesem Zeitpunkt können Sie sich dem Meistern der Kunst widmen, die anderen erweiterten APIs zu nutzen. Dort fügt sich alles zusammen, und Sie sehen endlich das Gesamtbild, wie all diese APIs, Methoden und Einträge miteinander verbunden sind.