Zusammenfassung

  • Die W3C-Empfehlung Performance Timeline von 2013 gab Messungen als PerformanceEntry mit Name, Typ, Startzeit und Dauer aus; Methoden wie getEntriesByType() lasen vorhandene Einträge.
  • Ein Level-2-Entwurf von 2015 brachte PerformanceObserver: Neue passende Einträge erreichen eine Rückruffunktion, wenn der Browser sie erfasst. Die Texte von 2016 und heute präzisieren Zustellung und Puffer.

„Die Seite ist langsam“ klingt nach einem einfachen Befund. Bei der Suche nach der Ursache wird daraus eine kleine Ermittlungsakte. Der Browser hält Zeiten für Navigation, Ressourcen und eigene Markierungen der Autoren bereit. Die W3C-Empfehlung Performance Timeline vom Dezember 2013 ordnete sie als Einträge mit Namen, Typ, Beginn und Dauer. getEntries() oder getEntriesByType() lieferte Kopien der bereits gesammelten Karten. Die Akte lag im Schrank; der Ermittler musste sie selbst abholen.

Die Seite arbeitet nach dem ersten Blick weiter. Ein Bild kommt an, ein Skript setzt eine Marke, eine weitere Ressource ist fertig. Eine Anwendung kann die Schublade ständig erneut öffnen und nach neuen Karten suchen. Dabei sitzt der Browser direkt am Schreibtisch, auf dem jede Karte geschrieben wird. Warum sollte der Ermittler immer wieder fragen, ob etwas eingetroffen ist, wenn der Schreiber bei Ankunft klingeln kann?

Der Performance-Timeline-Level-2-Entwurf vom September 2015 stellte beide Arten der Arbeit in Beispielen dar. Die ältere liest gespeicherte Einträge. Die neue erzeugt einen PerformanceObserver, übergibt eine Rückruffunktion und wählt die beobachteten Typen. Sobald passende Messungen entstehen, erhält die Funktion eine Liste. Sie kann mehrere Einträge gemeinsam bearbeiten und die Beobachtung beenden, wenn die Untersuchung abgeschlossen ist. Der Browser meldet, was er gerade notiert hat.

Die W3C-Publikationsgeschichte datiert den ersten öffentlichen Level-2-Entwurf auf den 16. Juli 2015. Die Kandidatenempfehlung vom 8. Dezember 2016 beschreibt Registrierung, Eintragstypen und Rückrufzustellung genauer. Der Leser bekam dadurch keine neue Geduld. Das Messteam gewann eine bessere Arbeitsteilung: Die Uhr meldet neue Zahlen, die Menschen untersuchen ihren Grund.

Ein Beobachter braucht einen Auftrag. Bei langsam wirkenden Bildern kann das Team Ressourceneinträge verfolgen. Bei einer zähen Bedienhandlung setzt es Markierungen rund um die betreffenden Schritte. Der Browser stellt das gemeinsame Kartenformat und die Benachrichtigung bereit. Die Website entscheidet, welche Daten ihre Frage beantworten. Wer jede verfügbare Karte bestellt und keine liest, hat bloß die Klingel lauter gestellt.

Die heutige Performance-Timeline-Spezifikation behandelt neue Einträge und, je nach Typ, auch gepufferte ältere Einträge. Sie beschreibt Puffer je Eintragstyp und zählt verlorene Einträge, wenn ein Puffer voll wird. Der Aktenschrank ist endlich. Für eine belastbare Diagnose muss das Team wissen, wann es zu beobachten begann und wie viele Karten unterwegs verlorengingen.

Der Browser trägt Zeiten ein und meldet neue Befunde. Autoren ordnen die Zahlen der Erfahrung ihrer Leser zu und entscheiden, was sie an der Seite ändern. Die Uhr weiß, wann ein Bild geladen wurde. Ob dieses Bild auf der Startseite überhaupt so groß sein musste, weiß die Redaktion.