Summary

  • Der erste öffentliche W3C-Entwurf vom 26. Oktober 2010 beschrieb das Problem einer Stoppuhr, die erst mit dem Seitenskript beginnt und die vorherige Wartezeit verpasst.
  • Die Empfehlung vom 17. Dezember 2012 definierte Zeitmarken vom Navigationsbeginn über DNS, Verbindung und Antwort bis zur Dokumentverarbeitung. Die Website musste weiterhin selbst entscheiden, was sie untersucht und verbessert.

Im Hotel klagt ein Gast über die lange Anreise. Er hat auf den Wagen gewartet, die Adresse gesucht und vor der Tür angestanden. Der Portier drückt erst am Empfang auf die Stoppuhr, überreicht nach zwanzig Sekunden den Schlüssel und lobt die Schnelligkeit des Hauses. Seine Zahl stimmt. Sie beantwortet nur eine andere Frage als die des Gastes. Genau so maß eine Webseite ihre Ladezeit, wenn sie erst im eigenen Skript mit dem Zählen anfing.

Der erste öffentliche Entwurf von Navigation Timing vom 26. Oktober 2010 führt diesen Fehler vor. Ein Skript im Kopf des Dokuments notiert seine Startzeit; beim Ladeereignis wird die Differenz berechnet. Doch bevor das Skript ausgeführt werden kann, muss das Dokument überhaupt erst eintreffen. Anfrage, Verbindung und Antwort können bereits Zeit gekostet haben. Für den Leser beginnt die Wartezeit vorher. Für die Stoppuhr existiert sie nicht.

Die Abhilfe bestand darin, den Browser nach seinem eigenen Protokoll zu fragen. navigationStart setzte den Ausgangspunkt, weitere Werte in performance.timing dokumentierten die folgenden Stationen. Die Rechnung „Ladeende minus Navigationsbeginn“ war einfach. Entscheidend war, wer den Beginn bezeugen konnte. Eine Seite kann ihre Vergangenheit nicht aus einem später gestarteten Skript zurückrechnen; der Browser war bereits am Tatort.

Sein Protokoll trennte die Etappen. fetchStart bezeichnete den Beginn des Abrufs oder einer Cache-Prüfung. domainLookupStart und domainLookupEnd rahmten die Namensauflösung ein, connectStart und connectEnd den Verbindungsaufbau. requestStart, responseStart und responseEnd zeigten Anfrage und Eintreffen des Dokuments. Danach folgten Marken für das Laden des Dokuments, seine Interaktivität und die DOM-Ereignisse. Aus „die Seite war langsam“ wurden prüfbare Vermutungen: lag die Verzögerung vor dem ersten Byte oder arbeitete die Seite nach dessen Ankunft lange weiter?

Die Kandidatenfassung vom 2. Juni 2011 markiert den weiteren Standardisierungsweg. Die W3C-Empfehlung vom 17. Dezember 2012 legte die bekannte PerformanceTiming-Schnittstelle fest. Die Publikationsgeschichte des W3C zeigt den Weg vom Entwurf 2010 über die Kandidatenstufen 2011 bis zum Abschluss 2012. Eine Rechnung taugt erst als Beleg, wenn ihre Posten eine vereinbarte Bedeutung haben.

Manche Posten fallen zusammen. Bei einer wiederverwendeten Verbindung gibt es keinen neuen Verbindungsaufbau zu messen. Ein Treffer im Cache verändert ebenfalls die Netzwerkstrecke. Gleiche Zeitmarken bedeuten daher nicht automatisch einen defekten Zähler. Wer aus jeder Null einen Ausfall macht, stellt dem Gast eine zweite Taxifahrt in Rechnung, obwohl er im Wagen geblieben ist. Die Empfehlung beschreibt diese Fälle, damit Wiederverwendung nicht wie Datenverlust aussieht.

Sie verlangte auch eine monotone Uhr. Eine Änderung der Systemzeit während des Ladevorgangs sollte keine negativen Intervalle zwischen aufeinanderfolgenden Ereignissen erzeugen. Wenn die Hotelrechnung behauptet, der Aufzug sei vor seiner Abfahrt angekommen, ist die Diskussion über seine Geschwindigkeit zunächst erledigt. Verlässliche Messung braucht eine verlässliche Reihenfolge, nicht nur viele Nachkommastellen.

An einer anderen Stelle blieb die Rechnung absichtlich unvollständig. Führte eine Weiterleitung über verschiedene Origins, wurden die detaillierten Weiterleitungszeiten auf null gesetzt. Die Zielseite sollte die Bewegung auf einer fremden Seite nicht aus Zeitspuren erschließen können. Der Text von 2012 nannte zudem das Problem verschiedener Autoren auf demselben Host: Was für den Browser als ein Origin gilt, kann in der Wirklichkeit mehreren Parteien gehören. Die Grenze des Messbaren musste also ebenso definiert werden wie die Messung selbst.

Navigation Timing sammelte keine Daten für die Website und beschleunigte keine langsame Anwendung. Schon der Entwurf von 2010 überließ Sammeln, Speichern und Berichten der Anwendung. Die Empfehlung warnte außerdem davor, die Schnittstelle als pauschalen Browser-Benchmark zu behandeln. Ein einzelner Seitenaufruf hängt von Gerät, Cache, Netz und Seitencode ab. Die Zeitmarken beschreiben diesen Besuch. Erst ein Betreiber entscheidet, welche Besuche vergleichbar sind und welche Stellschraube er bewegt.

Das veränderte den Streit um Ladezeiten. Statt „das Netz ist schuld“ konnte ein Team fragen, ob die Antwort spät kam oder das Dokument nach der Antwort trödelte. Ein Browser konnte einen Teil der Reise bezeugen, den die Seite selbst verpasst hatte. Mit dieser Rechnung am Empfang wurde die Ausrede vom langsamen Aufzug etwas schwieriger.