Zusammenfassung

  • Der erste öffentliche W3C-Arbeitsentwurf zu Resource Timing vom 24. Mai 2011 beschrieb Zeitmarken für einzelne Ressourcen, darunter Bilder: Namensauflösung, Verbindung, Anfrage und Antwort bekamen eigene Abschnitte.
  • Der Kandidatentext zu Level 1 vom 30. März 2017 ordnete die Einträge einer Leistungschronik zu, regelte einen begrenzten Puffer und überließ die Freigabe genauer Fremdzeiten dem Header Timing-Allow-Origin.

Die Seite war langsam, und die Teile hatten sich auf eine gemeinsame Verteidigung geeinigt: Jeder zeigte auf den Nachbarn. Das große Bild verdächtigte das Stylesheet. Das Stylesheet schob das Skript vor. Das Skript blickte bedeutungsvoll zum Server. Die Gesamtzeit belegte, dass jemand gewartet hatte. Wer den Stau verursacht hatte, blieb hinter der großen Zahl verborgen. Resource Timing teilte jedem Ankömmling eine Stoppuhr aus.

Der erste öffentliche W3C-Arbeitsentwurf vom 24. Mai 2011 wollte Verzögerungen innerhalb einer Seite sichtbar machen. Als Beispiel diente die Abrufdauer eines Bildes. Die Navigation eines Dokuments und das Eintreffen seiner Bestandteile sind verschiedene Vorgänge. Bilder, Stylesheets und Skripte gehen eigene Wege; eines kann noch unterwegs sein, wenn anderes bereits auf dem Bildschirm steht. Eine einzige Seitenzeit ist dafür so brauchbar wie die Ankunftszeit eines Zuges ohne Liste der fehlenden Wagen.

Der Entwurf beschrieb je Ressource einen Namen, die Art ihres Auslösers und Zeitpunkte im Abruf. fetchStart, domainLookupStart, connectStart, requestStart, responseStart und responseEnd lassen Namensauflösung, Verbindungsaufbau, Anfrage und Antwort getrennt betrachten. Fällt ein Bild auf, kann die Redaktion die Phase prüfen, statt das Wort „Netz“ wie einen Allzweckstempel auf die Akte zu drücken. Der Eintrag liefert Fragen, denen man nachgehen kann.

Manche Zeitmarken liegen dicht beieinander. Der Browser kann eine vorhandene Verbindung erneut verwenden oder eine Ressource aus dem Cache holen. Dann entfällt ein Teil des üblichen Netzwerkwegs. Gleiche Zeitpunkte sind in diesem Fall kein defektes Messgerät. Wer zwei Besuche vergleicht, muss wissen, ob einer mit gefülltem Cache begann. Die Stoppuhr beschreibt diesen Abruf unter diesen Bedingungen, nicht das ewige Wesen eines Bildes.

In der W3C-Kandidatenempfehlung Resource Timing Level 1 vom 30. März 2017 stehen die Ressourceneinträge in einer Leistungschronik. Das Beispiel ruft performance.getEntriesByType('resource') auf, sucht initiatorType gleich img und vergleicht responseEnd mit startTime. Bilder lassen sich nach ihrer Dauer sortieren und anschließend abschnittsweise untersuchen. Andere Ressourcen folgen demselben Modell. Die Seite muss nicht mehr als Sammelverdächtige für den verspäteten Bildabruf auftreten.

Auch die Buchhaltung hat eine Kapazität. Der Text von 2017 beschreibt einen Puffer und Verfahren wie setResourceTimingBufferSize() und clearResourceTimings(). Eine Seite mit vielen Abrufen kann ihn füllen. Wer Messungen sammelt, entscheidet über Platz und Zeitpunkt des Löschens. Fehlen spätere Einträge, beweist das keine übernatürliche Beschleunigung. Möglicherweise war nur das Notizbuch voll. Die Messinfrastruktur gehört zum Betrieb und zur Auswertung.

Bei einer Ressource von einer anderen Herkunft kommt ein weiterer Entscheider hinzu. Der Browser kann ihren Abruf aufführen, schränkt genaue Abschnittswerte aber zunächst ein. Der fremde Server kann mit Timing-Allow-Origin bestimmten Herkunftsseiten tiefere Einblicke gewähren. Wer ein fremdes Bild einbettet, besitzt deshalb noch nicht dessen vollständiges Zeitprotokoll. Der Lieferant hält den Schlüssel zum feinen Zifferblatt.

Das ist für die Diagnose entscheidend. Ein fremder Eintrag kann Namen und Dauer zeigen, während DNS-, Verbindungs- und Antwortphasen verborgen bleiben. Die Lücke als „null Millisekunden Arbeit“ zu lesen, würde eine Sichtgrenze in einen Geschwindigkeitsrekord verwandeln. Öffnet der Lieferant die Details, gibt es mehr Anhaltspunkte. Sonst arbeitet die Redaktion mit dem, was tatsächlich sichtbar ist, und fragt gezielter nach.

Der W3C-Entwurf einer Kandidatenempfehlung vom 1. September 2026 führt die ressourcenbezogene Sicht weiter und beschreibt mehr Attribute sowie einen größeren Puffer als frühe Texte. Der Arbeitsentwurf von 2011, die Kandidatenempfehlung von 2017 und der spätere Entwurf sind drei Stationen, keine unveränderte Schnittstelle. Gemeinsam ist ihnen die überprüfbare Frage nach dem Weg einer einzelnen Ressource.

Das langsamste Bild muss trotzdem nicht der wichtigste Reparaturfall sein. Vielleicht liegt es weit unter dem sichtbaren Bereich. Ein etwas schnelleres Skript hält womöglich die Überschrift auf. Resource Timing erzählt vom Transport, das Layout von der Wirkung. Erst zusammen zeigen sie, ob ein Bild kleiner werden, anders geliefert, früher angefordert oder später geladen werden sollte. Die Uhr schreibt keinen Redaktionsplan.

Am Ende konnte das Team anders sprechen. „Die Seite ist langsam“ war eine Klage. „Dieses Bild wartete hier, das Stylesheet nutzte eine bestehende Verbindung, und der Fremdserver öffnete seine Details nicht“ war ein Arbeitsauftrag. Das Titelbild darf weiter über das Stylesheet schimpfen. Vorher muss es aber seinen eigenen Stundenzettel vorlegen.