Zusammenfassung

  • Der erste öffentliche Beacon-Entwurf des W3C vom Oktober 2013 benannte die Tricks, mit denen Analysedaten das Verlassen einer Seite verzögerten: synchrones XMLHttpRequest, Bildladevorgänge und leere Warteschleifen.
  • Der Kandidatenentwurf vom August 2022 beschreibt navigator.sendBeacon() für kleine Einwegberichte, die der Browser übernimmt und ohne Wartepflicht für den Leser sendet.

Stellen Sie sich einen Kellner vor, der Ihnen am Ausgang hinterherläuft. „Einen Moment, ich muss der Zentrale melden, dass Sie gegangen sind.“ Der Satz ist kurz, das Warten weniger. Eine Webseite konnte ihre Statistik auf ähnliche Weise behandeln: Die nächste Seite durfte gefühlt erst beginnen, wenn die vorige ihren letzten Zettel abgegeben hatte.

Der erste öffentliche W3C-Arbeitsentwurf vom 29. Oktober 2013 erklärte, warum Entwickler zu solchen Mitteln griffen. Analyse- und Diagnosecode wollte Daten übermitteln, während das Dokument entladen wurde. Eine gewöhnliche asynchrone Anfrage konnte mit der verschwindenden Seite enden. Also setzte man mitunter synchrones XMLHttpRequest ein, lud ein Bild oder ließ eine sinnlose Schleife Sekunden verbrauchen. Der Entwurf beschrieb die Folge: Der Wechsel zur nächsten Seite wirkte langsamer.

Der damalige Vorschlag übertrug die Sendearbeit an den User Agent. Die frühe Methode hieß beacon und sah anders aus als das spätere navigator.sendBeacon(). Wer die alte Skizze als heutiges Codebeispiel liest, überspringt neun Jahre Entwicklung. Die dauerhafte Idee lag im Aufgabentausch: Die Seite liefert den Bericht ab, der Browser kümmert sich um den Weg.

Ein letzter Bericht hat durchaus einen Zweck. Manche Information entsteht erst am Ende einer Sitzung. Jede Kleinigkeit sofort zu senden beansprucht Netzwerk und Akku. Alles für den Abschied zu sammeln erhöht wiederum das Risiko, dass die Seite verschwindet, bevor der Bericht hinausgeht. Die schlechte Lösung ließ den Besucher diese Spannung mit Wartezeit bezahlen. Beacon gab dem Browser einen Platz, an dem der kleine Auftrag weiterleben konnte.

Der W3C-Kandidatenentwurf vom 3. August 2022 beschreibt navigator.sendBeacon(url, data) als asynchrone, nicht blockierende Übergabe kleiner Einwegdaten. Der Browser kann deren Übertragung priorisieren, mit anderer Netzwerkarbeit abstimmen und Anfragen unter Umständen bündeln. Ein Klick, eine Animation oder der Aufbau der nächsten Seite muss nicht hinter dem Statistikformular anstehen.

Das Beispiel von 2022 reagiert auf visibilitychange: Wird das Dokument verborgen, legt die Seite ihren Sitzungsbericht in die Hände des Browsers. Auf dem Telefon kann eine Anwendung in den Hintergrund rutschen und später vom System beendet werden, ohne dass ein ordentliches unload stattfindet. Auf eine feierliche Verabschiedung zu warten, ist unter solchen Bedingungen keine gute Arbeitsanweisung. Das Verbergen ist der frühere praktische Hinweis.

Die Rückgabe von sendBeacon() ist nüchtern. true bedeutet, dass der Browser die Daten in seine Warteschlange aufnehmen konnte. Ob sie beim Server angekommen sind, zeigen dessen Aufzeichnungen. Einen Rückruf zur Verarbeitung einer Antwort bietet die Methode nicht. Der Kurier hat den Brief entgegengenommen; eine Unterschrift des Empfängers liegt noch nicht auf dem Tisch.

Der Umschlag bleibt klein. Der Entwurf von 2022 bindet die Übertragung an fetch mit keepalive und begrenzt die Datenmenge, die dafür anstehen darf. Benötigt eine Anwendung eigene Header, eine andere Methode oder eine Antwort, führt der Weg über passende fetch-Funktionen. Der Beacon-Kurier trägt einen Brief, keinen Umzugswagen.

Die W3C-Publikationsgeschichte verzeichnet den ersten öffentlichen Entwurf 2013, einen Candidate Recommendation Snapshot 2017 und den Candidate Recommendation Draft 2022. Das sind Stationen der Spezifikation. Hinter allen steht dieselbe handfeste Frage: Wer trägt die letzte Nachricht weiter, wenn der Leser schon den Ausgang gewählt hat?

Gelingt die Übergabe, merkt der Leser vor allem, was ausbleibt. Die alte Seite verlangt keine zusätzliche Pause. Ihr kleiner Bericht bleibt eine Aufgabe des Browsers, während die nächste Seite beginnen kann. Der Kellner darf seine Liste führen. Der Gast muss ihm dabei nicht über die Schulter sehen.