Navigation Timing – Ladezeiten messen?

Ich möchte heute mal was zeigen und dann hinterher argumentieren, daß es Unsinn ist. Bin mal gespannt, wie das ankommt.

Es geht um Messungen der Ladezeit, also die Frage „We lange dauert es, bis der Benutzer den Inhalt sehen kann?“. Ganz salopp gesagt sollte diese Zeit so kurz sein wie möglich, und zwar erstens um Frustration beim potentiellen Kunden zu lindern, zweitens weil Mobilgeräte nicht so dicke Bandbreite haben.

Der naive Ansatz „von früher“[tm] war, mit Javascript jeweils am Anfang und Ende der Seite einen Zeitstempel zu setzen und einfach die Differenz auszurechnen. So hat das z.B. das getLoadTime() Plugin gemacht.

Mittlerweile gibt es einen besseren Ansatz (und eine neue Version von getLoadTime) der auf der Navigation Timing API aufsetzt. Und den möchte ich heute erklären.

Der neue Ansatz hat eine Reihe von Vorteilen, z.B. ist er sehr viel genauer als eine Messung mit Javascript.

Wirklich interessant finde ich allerdings, daß man mit Navigation Timing auch ab dem letzten Klick messen kann, also wie lange es dauert, bis der Benutzer als Reaktion auf einen Klick eine Seite sieht. Das ist mit JS nur mit Cookies zu machen.

Navigation Timing

Moderne Browser (IE9+, Chrome, FF, Opera) legen im sogenannten PerformanceTiming Interface 21 Zeitstempel offen, die sehr genau zeigen, was genau wann passiert ist. Das fängt mit dem Zeitpunkt des Klicks an, beinhaltet das Verwerfen der alten Seite, Redirects, DNS Lookups, Ladezeiten, Rendering und hört auf, wenn der Browser mit der Seite „fertig“ ist.

Die Definition des Interface möchte ich hier nicht wiederholen, die kann man beim W3 unter Navigation Timing nachlesen, inklusive Erklärung aller Zeitstempel.

Die Grafik unter Processing Model zeigt ganz gut, in welcher Reihenfolge die Zeitstempel auftreten und was sie bedeuten.

Ganz grob gesehen sind vermutlich folgende Zeiten interessant:

1. navigationStart — der Moment wenn der Browser „gemerkt hat, daß er eine neue Seite laden muß“. Das merkt er z.B. wenn der Benutzer einen Link zu einer anderen Seite anklickt.
2. fetchStart — zu diesem Zeitpunkt beschließt der Browser, daß er jetzt mit dem Laden der Seite beginnen wird.
3. requestStart — jetzt hat der Browser den Cache gecheckt, DNS Lookup gemacht und eine Connection aufgebaut und schickt den HTTP Request raus.
4. responseStart — Beginn der Übermittlung von Daten vom Server.
5. responseEnd — Ende der Datenübermittlung vom Server

Das sind erstmal die „technischen Zahlen“, an denen ich ablesen kann, wie Latenz im Netz und Antwortzeiten meines Servers aussehen.

5. domLoading — hier beginnt der Browser mit dem Aufbau der Seitenstruktur.
6. domComplete — der Browser hat die Seite fertig gebaut. Falls der Status mehrfach wieder weg und dann wieder auf „complete“ geht (z.B. weil mit JS Dinge an der Seite geändert werden), dann steht hier der erste, also früheste Zeitpunkt!
7. loadEventEnd — der Zeitpunkt, an dem der „load event“ komplett ausgeführt wurde.

Diese Zahlen sagen etwas aus über die Komplexität der Seite, also wie lange der Browser braucht um die Seite aufzubauen, nachdem sie aus dem Cache oder vom Server geladen wurde.

Ich habe die beiden Blöcke getrennt, weil potentiell unterschiedliche Teams für die Optimierung zuständig sind. Den ersten Block sollte das Netzwerkteam angehen, den zweiten die Webentwickler und Contentmanager.

Tracken

Und was tracke ich jetzt genau?

Das getLoadTime() Plugin trackt einen Wert, nämlich von requestStart bis „genau jetzt“. Das umfaßt je nach Postition des Pluginaufrufs alles bis domComplete oder sogar loadEventEnd, nicht jedoch Check des Cache, DNS und Verbindungsaufbau, also alles was vor dem HTTP Request passiert.

Ich will jetzt gar nicht über Sinn und Unsinn schwadronieren, das kommt weiter unten. Bleiben wir mal technisch und sehen uns an, was man sonst noch so tracken könnte…

Wer des Englischen mächtig ist, kann sich Measuring Page Load Speed with Navigation Timing ansehen, da wird viel und gut erklärt. Für alle Anderen fasse ich mal zusammen.

Da alle Datenpunkte Zeitstempel im Unixformat sind, also Millisekunden seit 1.1.1970, ist es sinnvoll, sich Differenzen anzusehen statt einzelner Werte.

„Netzwerklatenz“ wäre zum Beispiel responseEnd - fetchStart. Die „Ladezeit“ wäre loadEventEnd - responseEnd und die komplette Zeit „von Klick bis fertig“ wäre loadEventEnd - navigationStart.

Man muß bei einigen der Werte aufpassen, weil sie je nach Situation „0“ sein können, z.B. die Zeitpunkte für redirect und unload.

Aus Sicht der Webanalyse würde man vermutlich zwei Dinge ansehen wollen, und zwar die schon erwähnte Zeit „von Klick bis fertig“, sowie vielleicht — als Stellvertreter für Komplexität der Seite — loadEventEnd - domLoading oder sogar loadEventEnd - responseStart.

Beispielhaft könnte das so aussehen:

	var t = performance.timing;
	s.contextData['timing.clickToComplete'] = 
		(t.loadEventEnd - t.navigationStart) / 100;
	s.contextData['timing.loadToComplete'] = 
		(t.loadEventEnd - t.responseStart) / 100;

Da Millisekunden etwas arg hochauflösend sind (siehe „Uniques exceeded“), teilen wir durch 100, bekommen also Zehntelsekunden. Das sollte reichen.

Diese Zahlen könnte man mit geolocation korrelieren, oder vielleicht mit dem Typ des Endgerätes (dauert das alles auf einem Telefon signifikant länger als auf einem Desktop?). Und vielleicht könnte man ein wenig segmentieren und untersuchen, ob diese Zeiten Auswirkungen haben auf Warenwert, Konversion oder sonstige Success Events.

Unsinn

Soweit alles verständlich? Gut.

Mir stellt sich jetzt die Frage, was das eigentlich soll. Was genau habe ich als Analyst davon wenn ich weiß, daß meine Benutzer meine Seiten nach durchschnittlich 1.8 Sekunden sehen können?

Mein Verdacht: Nichts.

Grundsätzlich sollte man ja nur solche Dinge reporten, anhand derer man etwas ändern wird, zumindest theoretisch. Das bedeutet, daß man möglichst gezielt analysieren und eben auch tracken sollte. So.

Änderungen an der Site bzgl. Ladezeiten sind sinnvoll, keine Frage. Je schneller desto besser. Aber ist das eine Frage für den Analysten? Gibt es ein erstrebenswertes Ziel? „10% meines Bonus bekomme ich, wenn die durchschnittliche Ladezeit auf <1.5325s geht“? Hat der Analyst überhaupt ein Interesse daran oder den nötigen Einfluß?

Oder andersrum gefragt: Wenn IT (als die Betreiber der Site) die Ladezeiten verbessern wollen, brauchen sie dann Zahlen aus SiteCatalyst Adobe Analytics? Oder reicht es denen, das Profiling in Chrome anzusehen?

Genau.

Eine schöne Gelegenheit, mal Nein zu sagen.