Warum Beforeunload vs Pagehide entscheidet, ob Analytics-Daten überleben

Warum ist beforeunload vs pagehide wichtig für das Flushen von Analytics-Daten?

Die richtige Wahl zwischen beforeunload vs pagehide entscheidet, ob ein Analytics-Event den Server tatsächlich erreicht, bevor ein Nutzer die Seite verlässt. MDN dokumentiert beforeunload als nicht zuverlässig auslösend, besonders auf Mobilgeräten: Ein Nutzer, der zu einer anderen App wechselt und den Browser später über den App-Manager schließt, löst das Event überhaupt nicht aus. Verwenden Sie pagehide oder visibilitychange statt beforeunload, um Daten zu flushen, und reservieren Sie beforeunload für die eine Aufgabe, die es noch erfüllt: einen Nutzer vor ungespeicherten Änderungen zu warnen. Das falsch zu machen ist einer der leiseren Gründe, warum ein Setup für Real User Monitoring Exits unterzählt.

Was macht das beforeunload-Event eigentlich?

Das beforeunload-Event löst kurz vor dem Entladen einer Seite aus und kann einen browsereigenen Bestätigungsdialog anzeigen, um einen Nutzer vor ungespeicherten Änderungen zu warnen. MDN empfiehlt selbst, den Listener nur hinzuzufügen, wenn ungespeicherte Änderungen zu schützen sind, und ihn wieder zu entfernen, sobald diese Änderungen gespeichert wurden, statt ihn für die gesamte Lebensdauer der Seite angehängt zu lassen. Genau dieser enge Anwendungsfall ist auch der einzige, für den es noch geeignet ist, denn seine Zuverlässigkeit als allgemeines Exit-Signal ist nicht gegeben.

Warum ist beforeunload auf Mobilgeräten unzuverlässig?

Beforeunload ist auf Mobilgeräten unzuverlässig, weil ein Browser, der über den App-Wechsler geschlossen wird, oder eine App, die in den Hintergrund gerät und nie wieder geöffnet wird, das Event vollständig überspringt, was MDN direkt mit dem Szenario App-Wechsel-dann-Schließen benennt. Ein Desktop-Tab, der über die Fenstersteuerung geschlossen wird, löst das Event aus; dieselbe Abfolge auf einem Smartphone, App in den Hintergrund schicken und dann über den App-Manager schließen, überspringt das Event vollständig. Jeder Analytics-Aufruf, der ausschließlich vom Auslösen von beforeunload abhängt, verliert Daten genau auf der Plattform, auf der Sitzungen auf diese Weise enden.

Wie wirkt sich beforeunload auf den Back-Forward-Cache aus?

Die Wirkung von beforeunload auf den Back-Forward-Cache unterscheidet sich je nach Browser: Firefox platziert eine Seite nicht im Bfcache, wenn ein beforeunload-Listener angehängt ist, während der Bfcache-Leitfaden von web.dev anmerkt, dass beforeunload eine Seite in anderen modernen Browsern nicht mehr vom Bfcache ausschließt, obwohl das früher der Fall war. Web.dev bezeichnet das Event weiterhin als "unzuverlässig, daher vermeiden Sie die Nutzung, außer wenn absolut notwendig", und empfiehlt, den Listener bedingt hinzuzufügen, nur solange ungespeicherte Änderungen bestehen, statt bei jedem Seitenaufruf. Eine Seite, die den Bfcache überspringt, lädt bei einer Zurück-Navigation von Grund auf neu, statt sofort aus dem Speicher wiederhergestellt zu werden.

Was macht das pagehide-Event anders?

Das pagehide-Event löst aus, wenn der Browser die aktuelle Seite verbirgt, während er eine andere Seite aus dem Sitzungsverlauf anzeigt, etwa bei einem Klick auf die Zurück-Schaltfläche, und anders als bei beforeunload und unload macht ein pagehide-Listener eine Seite nicht ungeeignet für den Bfcache. MDN empfiehlt visibilitychange zuerst als das zuverlässigere Signal, mit pagehide als Fallback für Browser, in denen visibilitychange nicht verfügbar ist. Hängen Sie die Flush-Logik an pagehide, wenn eine Seite einen bfcache-sicheren Listener braucht, der trotzdem in genau den Navigationsmomenten auslöst, die beforeunload eigentlich abfangen sollte, was auch der Moment ist, in dem eine Session-Timeout-Uhr sonst gegen eine Seite weiterlaufen würde, die niemand ansieht.

Wo passt sendBeacon neben pagehide?

sendBeacon passt neben pagehide als Zustellmechanismus, da es eine asynchrone POST-Anfrage einreiht, die der Browser weiter zu senden versucht, selbst während die Seite verschwindet, ohne die Navigation zu verzögern, die der Nutzer bereits vollzieht. MDN empfiehlt, es mit dem visibilitychange-Event als primärem Auslöser zu kombinieren und pagehide als Fallback zu nutzen, statt es von unload oder beforeunload aus aufzurufen. Ein einzelner sendBeacon-Aufruf ist auf rund 64 KiB begrenzt; eine größere Nutzlast braucht stattdessen fetch() mit der Option keepalive.

Wie sollte ein Analytics-Skript diese Events kombinieren?

Ein Analytics-Skript sollte auf visibilitychange lauschen und document.visibilityState === "hidden" als primären Flush-Auslöser prüfen, pagehide als Fallback für Browser oder Situationen ergänzen, in denen visibilitychange nicht auslöst, und in beiden Handlern sendBeacon aufrufen, um die Nutzlast zu senden, ohne die Navigation zu blockieren. Flowserys schlankes Skript bleibt unter 10 KB, genau damit diese Listener-Logik einer Seite, die ohnehin gerade zu verlassen versucht, kaum Gewicht hinzufügt. Direkt auf beforeunload für diese Aufgabe zu setzen ist die eine Abkürzung, die auf Mobilgeräten am meisten Daten kostet, und dieselbe Abkürzung, die eine Zählung von Bounce Rate vs Exit Rate still und leise nach unten drückt, wenn das letzte Event einer Seite nie den Server erreicht.

Häufig gestellte Fragen

Ist beforeunload noch für irgendetwas nützlich?

Beforeunload ist weiterhin nützlich, um einen Nutzer über einen browsereigenen Bestätigungsdialog vor ungespeicherten Änderungen zu warnen. MDN empfiehlt selbst, den Listener nur anzuhängen, solange ungespeicherte Änderungen bestehen, und ihn nach dem Speichern zu entfernen, statt ihn als allgemeines Seiten-Exit-Signal zu nutzen.

Warum blockiert pagehide den Back-Forward-Cache nicht so, wie es beforeunload einst tat?

Pagehide blockiert den Bfcache nicht, weil es als Teil der Page Lifecycle API entwickelt wurde, um gezielt einen Seitenübergang zu signalisieren, ohne die Nebenwirkungen, die unload und beforeunload mit sich bringen. MDN stellt klar fest, dass ein pagehide-Listener, anders als unload und beforeunload, eine Seite nicht ungeeignet für den Bfcache macht.

Sollte visibilitychange pagehide vollständig ersetzen?

Visibilitychange sollte das primäre Signal sein, mit pagehide als Fallback, laut MDNs eigener Empfehlung. Manche Browser oder Kontexte lösen visibilitychange nicht in jedem Exit-Szenario aus, sodass pagehide die Fälle abfängt, die visibilitychange verpasst, statt es vollständig zu ersetzen.

Was passiert, wenn ein Analytics-Aufruf beim Verlassen der Seite fetch statt sendBeacon verwendet?

Ein einfacher fetch-Aufruf, der beim Verlassen der Seite gestartet wird, kann abgebrochen werden, bevor der Browser ihn fertig gesendet hat, da die Seite bereits entladen wird. sendBeacon existiert genau deshalb: Der Browser akzeptiert die Anfrage und versucht weiter, sie zuzustellen, unabhängig davon, ob die Seite bereits verschwunden ist, bis zu seiner Grenze von rund 64 KiB.

Beeinflusst der Back-Forward-Cache Analytics überhaupt?

Der Back-Forward-Cache stellt eine Seite bei einer Zurück- oder Vorwärts-Navigation aus dem Speicher wieder her, statt sie neu zu laden, was bedeutet, dass das JavaScript einer Seite nicht erneut ausgeführt wird und jede Pageview-Logik, die von einem frischen Seitenaufruf abhängt, nicht erneut auslöst. Ein pageshow-Event mit event.persisted === true ist das Signal dafür, dass eine Wiederherstellung stattgefunden hat, worauf die Analytics-Logik separat von einem ersten Laden prüfen muss.

Warum behandelt Firefox beforeunload beim Bfcache anders als andere Browser?

Firefox schließt eine Seite vom Bfcache aus, wenn ein beforeunload-Listener angehängt ist, eine strengere Haltung als bei Browsern, die aufgehört haben, Seiten mit beforeunload vom Bfcache auszuschließen, nachdem sie das zuvor getan hatten. Die sicherste Wahl über alle Browser hinweg bleibt, einen beforeunload-Listener nur hinzuzufügen, wenn ungespeicherte Änderungen bestehen, denn das hält den Listener genau während der Navigationen von der Seite fern, bei denen die Bfcache-Eignung am meisten zählt.

Was passiert, wenn eine Analytics-Payload größer ist als das 64-KiB-Limit von sendBeacon?

Ein sendBeacon-Aufruf ist auf rund 64 KiB begrenzt und lehnt eine größere Payload komplett ab, sodass sie den Server nie erreicht. Der Wechsel zu fetch mit der keepalive-Option verarbeitet Payloads über dieser Grenze und übersteht trotzdem eine Seite, die sich bereits im Entladen befindet.

Ist das unload-Event ein sichereres Fallback als beforeunload?

Unload ist schlechter, nicht sicherer. MDN nennt es auf Mobilgeräten extrem unzuverlässig, und es blockiert auf dem Desktop in Chrome und Firefox weiterhin den bfcache, genau die Kosten, die pagehide vermeiden sollte. Es gehört als Legacy-Code vermieden, nicht als Fallback eingesetzt.

Machen pagehide- und visibilitychange-Listener eine Seite schwerer?

Flowsery liefert sein Skript unter 10 KB aus, genau damit diese Listener-Logik kaum zusätzliches Gewicht auf eine Seite bringt, die ohnehin schon dabei ist, zu verschwinden. Die eigentlichen Kosten stecken in der Größe der sendBeacon-Payload, nicht in den Event-Listenern selbst.

Wie wirkt sich das Flushen bei pagehide auf das Session-Timeout-Tracking aus?

Pagehide feuert genau in dem Moment, in dem eine Seite hinter einer anderen aus dem Session-Verlauf verschwindet, also genau dann, wenn eine Session-Timeout-Uhr sonst gegen eine Seite weiterlaufen würde, die niemand mehr ansieht. Das Flushen an dieser Stelle schließt die Session zum richtigen Zeitpunkt ab, statt Leerlaufzeit gegen einen bereits verlassenen Tab anzusammeln.