Das unload-Ereignis wird eingestellt, indem die Standardeinstellung schrittweise geändert wird, sodass unload-Handler auf Seiten nicht mehr ausgelöst werden, es sei denn, sie werden auf einer Seite ausdrücklich wieder aktiviert.
Zeitplan für die Einstellung
Wir haben bereits im Januar 2019 angekündigt, dass das Entladeverhalten wahrscheinlich geändert wird, wenn wir einen Back-Forward-Cache implementieren. Parallel zur Implementierung haben wir eine umfangreiche Aufklärungskampagne durchgeführt, die zu einem deutlichen Rückgang der Nutzung von Unload-Listenern geführt hat. Um diese Aufklärung zu ergänzen, haben wir auch Möglichkeiten angeboten, die Auswirkungen der Einstellung von Unload ab Chrome 115 zu testen:
- In Chrome 115 in der Praxis (Juli 2023) über die Permission-Policy API für das Entladen
- Lokale Tests durch Aktivieren einer Flag in Chrome 117 (September 2023)
Nach diesen Informations- und Testphasen wird die einfache Einstellung voraussichtlich so eingeführt:
- Eine auf einen Bereich reduzierte Phase, in der das Entladen für die 50 beliebtesten Websites nach und nach nicht mehr funktioniert (Referenz zum Zeitpunkt der Erstellung dieses Dokuments).
- Ab Chrome 120 (Ende November 2023) für 1 % der Nutzer
- Ende bei 100% der Nutzenden bis Ende des 3. Quartals 2024
- Darüber hinaus beabsichtigen wir, ab dem 3. Quartal 2024 eine allgemeine Phase zu starten, in der das Entfernen auf allen Websites nach und nach eingestellt wird – beginnend mit 1% der Nutzer*innen und bis zum Ende des 1. Quartals 2025 bei 100% der Nutzer*innen enden.
Hinweis: Wir bieten auch ein Menü mit Deaktivierungsoptionen für den Fall, dass dieser Zeitplan für die vorläufige Einstellung nicht ausreicht, um nach dem Entladen zu migrieren. Unser Ziel ist es, anhand dieser vorläufigen Einstellung den Zeitplan für die letzte Phase (endgültige Einstellung von „Unload“) festzulegen, in der diese Deaktivierungsoptionen entfernt oder reduziert werden.
Hintergrund
unload wurde entwickelt, um ausgelöst zu werden, wenn das Dokument entladen wird. Theoretisch kann damit Code ausgeführt werden, wann immer ein Nutzer eine Seite verlässt, oder als Callback am Ende der Sitzung.
Zu den Szenarien, in denen dieses Ereignis am häufigsten verwendet wurde, gehören:
- Nutzerdaten speichern: Speichern Sie die Daten, bevor Sie die Seite verlassen.
- Bereinigungsaufgaben ausführen: Offene Ressourcen schließen, bevor die Seite verlassen wird.
- Analysedaten senden: Es werden Daten zu den Nutzerinteraktionen am Ende der Sitzung gesendet.
Das Ereignis unload ist jedoch extrem unzuverlässig.
Unter Chrome und Firefox auf dem Computer ist unload relativ zuverlässig, wirkt sich aber negativ auf die Leistung einer Website aus, da die Verwendung des bfcache (Back-/Forward-Cache) verhindert wird.
In mobilen Browsern wird unload häufig nicht ausgeführt, da Tabs häufig im Hintergrund ausgeführt und dann beendet werden. Aus diesem Grund priorisieren Browser auf Mobilgeräten den bfcache gegenüber unload, was sie noch unzuverlässiger macht. Dieses Verhalten wird auch in Safari auf dem Computer verwendet.
Das Chrome-Team ist der Meinung, dass die Verwendung des mobilen Modells, bei dem der bfcache gegenüber unload priorisiert wird, disruptiv wäre, da es auch dort zu einer geringeren Zuverlässigkeit führen würde, obwohl es bisher in Chrome (und Firefox) relativ zuverlässig war. Stattdessen wird das unload-Ereignis in Chrome vollständig entfernt. Bis dahin funktioniert die Funktion auf Computern weiterhin zuverlässig für Nutzer, die die Einstellung ausdrücklich deaktiviert haben.
Warum sollte das Ereignis unload eingestellt werden?
Die Einstellung von unload ist ein wichtiger Schritt in Richtung eines viel besseren Verständnisses des Webs, in dem wir heute leben. Das Ereignis unload vermittelt ein falsches Gefühl der Kontrolle über den App-Lebenszyklus, das immer weniger der Realität entspricht, wie wir im Internet surfen.
Mobile Betriebssysteme frieren oder entladen häufig Webseiten, um Arbeitsspeicher zu sparen. Dies tun jetzt auch immer mehr Desktop-Browser aus denselben Gründen. Auch ohne Eingriffe des Betriebssystems wechseln Nutzer häufig den Tab und schließen alte Tabs, ohne die Seiten offiziell zu verlassen.
Das Ereignis unload wird als veraltet eingestuft, weil wir als Webentwickler dafür sorgen müssen, dass unser Paradigma dem der realen Welt entspricht und nicht auf veralteten Konzepten basiert, die nicht mehr zutreffen – wenn sie das überhaupt jemals getan haben.
Alternativen zu unload-Ereignissen
Anstelle von unload wird Folgendes empfohlen:
visibilitychange: Mit diesem Parameter legen Sie fest, wann sich die Sichtbarkeit einer Seite ändert. Dieses Ereignis tritt ein, wenn der Nutzer zwischen Tabs wechselt, das Browserfenster minimiert oder eine neue Seite öffnet. Derhidden-Status ist die letzte zuverlässige Zeit zum Speichern von App- und Nutzerdaten.pagehide: Damit wird ermittelt, wann der Nutzer die Seite verlassen hat. Dieses Ereignis tritt auf, wenn der Nutzer die Seite verlässt, sie neu lädt oder das Browserfenster schließt. Das Ereignispagehidewird nicht ausgelöst, wenn die Seite einfach minimiert oder zu einem anderen Tab gewechselt wird. Hinweis: Da eine Seite durchpagehidenicht für den Back-Forward-Cache zugelassen wird, kann sie möglicherweise wiederhergestellt werden, nachdem dieses Ereignis ausgelöst wurde. Wenn Sie bei diesem Ereignis Ressourcen bereinigen, müssen diese möglicherweise beim Wiederherstellen der Seite wiederhergestellt werden.
Das Ereignis beforeunload hat einen etwas anderen Anwendungsfall als unload, da es ein abwählbares Ereignis ist. Sie wird häufig verwendet, um Nutzer vor nicht gespeicherten Änderungen zu warnen, wenn sie die Seite verlassen. Dieses Ereignis ist außerdem nicht zuverlässig, da es nicht ausgelöst wird, wenn ein Hintergrundtab beendet wird. Wir empfehlen, die Verwendung von beforeunload einzuschränken und nur bedingt hinzuzufügen. Verwenden Sie stattdessen die oben genannten Ereignisse für die meisten unload-Ersetzungen.
Weitere Informationen finden Sie in diesem Artikel.
Nutzung von unload erkennen
Es gibt verschiedene Tools, mit denen Sie die Aufrufe des Ereignisses unload auf Seiten finden können. So können Website-Betreiber feststellen, ob sie dieses Ereignis entweder in ihrem eigenen Code oder über Bibliotheken verwenden und daher von der bevorstehenden Einstellung betroffen sind.
Chrome-Entwicklertools
Die Chrome-Entwicklertools enthalten eine back-forward-cache-Prüfung, mit der Sie Probleme erkennen können, die verhindern, dass Ihre Seite für den Back-Forward-Cache infrage kommt, einschließlich der Verwendung des unload-Handlers.
So testen Sie den Back-/Forward-Cache:
Öffne die Entwicklertools auf deiner Seite und gehe dann zu Anwendung > Hintergrunddienste > Back-Forward-Cache.
Klicken Sie auf Back-Forward-Cache testen. Chrome leitet Sie automatisch zu
chrome://terms/und zurück zu Ihrer Seite weiter. Alternativ können Sie auch auf die Schaltflächen „Zurück“ und „Weiter“ im Browser klicken.
Wenn Ihre Seite nicht für den Back-Forward-Cache infrage kommt, wird auf dem Tab Back-Forward-Cache eine Liste der Probleme angezeigt. Unter Umsetzbar sehen Sie, ob Sie unload verwenden:
Reporting API
Die Reporting API kann in Verbindung mit einer schreibgeschützten Berechtigungsrichtlinie verwendet werden, um die Nutzung von unload durch Ihre Websitenutzer zu erkennen.
Bfcache notRestoredReasons-API
Die Property notRestoredReasons, die der Klasse PerformanceNavigationTiming hinzugefügt wurde, enthält Informationen dazu, ob die Verwendung des bfcache bei der Navigation für Dokumente blockiert wurde und warum. Eine Anleitung zur Verwendung findest du hier. Hier ein Beispiel für die Warnung im Antwortobjekt eines vorhandenen unload-Listeners:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
Zugriff auf unload steuern
Chrome wird das unload-Ereignis schrittweise einstellen. In der Zwischenzeit können Sie verschiedene Tools verwenden, um dieses Verhalten zu steuern und sich auf die bevorstehende Einstellung vorzubereiten. Denken Sie daran, dass Sie sich nicht langfristig auf diese Techniken verlassen sollten. Planen Sie stattdessen so bald wie möglich eine Migration zu den Alternativen.
Mit den folgenden Optionen können Sie unload-Handler aktivieren oder deaktivieren, um zu testen, wie Ihre Website ohne sie funktionieren würde. So können Sie sich auf die bevorstehende Einstellung vorbereiten. Es gibt verschiedene Arten von Richtlinien:
- Berechtigungsrichtlinie: Dies ist eine Plattform-API, mit der Websiteinhaber den Zugriff auf Funktionen auf Website- oder Seitenebene über die Verwendung von HTTP-Headern steuern können.
- Enterprise-Richtlinien: Tools für IT-Administratoren, mit denen sie Chrome für ihre Organisation oder ihr Unternehmen konfigurieren können. Sie können über ein Admin-Steuerfeld wie die Google Admin-Konsole konfiguriert werden.
- Chrome-Flags: Damit kann ein einzelner Entwickler die Einstellung für die Einstellung von
unloadändern, um die Auswirkungen auf verschiedene Websites zu testen.
Richtlinie für Berechtigungen
Ab Chrome 115 wurde eine Berechtigungsrichtlinie hinzugefügt, mit der Websites die Verwendung von unload-Handlern deaktivieren und sofort vom bfcache profitieren können, um die Websiteleistung zu verbessern. In diesen Beispielen wird gezeigt, wie Sie dies für Ihre Website einrichten. So können Websites die Einstellung von unload vorantreiben.
In Chrome 117 wird diese Funktion erweitert, damit Websites das Gegenteil tun und weiterhin versuchen können, unload-Handler auszulösen, da Chrome standardmäßig festlegt, dass diese in Zukunft nicht mehr ausgelöst werden. In diesen Beispielen wird gezeigt, wie Sie weiterhin zulassen, dass für Ihre Website Entlade-Handler ausgelöst werden. Dieses Opt-in bleibt nicht für immer bestehen und sollte verwendet werden, um Websites Zeit für die Migration von unload-Handlern zu geben.
Unternehmensrichtlinie
Unternehmen, deren Software für die ordnungsgemäße Funktion auf das unload-Ereignis angewiesen ist, können mit der ForcePermissionPolicyUnloadDefaultEnabled-Richtlinie die schrittweise Einstellung für von ihnen verwaltete Geräte verhindern. Wenn Sie diese Richtlinie aktivieren, ist unload standardmäßig weiterhin für alle Ursprünge aktiviert. Für eine Seite kann jedoch auch eine strengere Richtlinie festgelegt werden. Wie die Deaktivierung der Berechtigungsrichtlinie ist dies ein Tool, mit dem potenzielle Unterbrechungen von Änderungen abgemildert werden können. Es sollte jedoch nicht auf unbestimmte Zeit verwendet werden.
Chrome-Flags und Befehlszeilenoptionen
Neben der Enterprise-Richtlinie können Sie die Einstellung für einzelne Nutzer auch über die Chrome-Flags und Befehlszeilenschalter deaktivieren:
Wenn Sie chrome://flags/#deprecate-unload auf enabled festlegen, wird die Standardeinstellung für die Einstellung vorgezogen und das Auslösen von unload-Handlern verhindert. Sie können weiterhin über die Berechtigungsrichtlinie für einzelne Websites überschrieben werden, werden aber standardmäßig weiterhin ausgelöst.
Diese Einstellungen können auch über Befehlszeilenoptionen gesteuert werden.
Vergleich der Optionen
In der folgenden Tabelle sind die verschiedenen Verwendungsmöglichkeiten der zuvor erläuterten Optionen zusammengefasst:
| Einstellung vorziehen | Einstellung vorziehen (mit Ausnahmen) | Einstellung verhindern, um Zeit für eine Migration zu haben | |
|---|---|---|---|
| Berechtigungsrichtlinie (gilt für Seiten/Websites) |
Ja | Ja | Ja |
| Unternehmensrichtlinie (gilt für Geräte) |
Nein | Nein | Ja |
| Chrome-Flags (gilt für einzelne Nutzer) |
Ja | Nein | Nein |
| Befehlszeileneinstellungen in Chrome (gilt für einzelne Nutzer) |
Ja | Nein | Ja |
Fazit
unload-Handler werden nicht mehr unterstützt. Sie sind seit langem unzuverlässig und werden nicht garantiert in allen Fällen ausgelöst, in denen ein Dokument gelöscht wird. Außerdem sind unload-Handler nicht mit bfcache kompatibel.
Websites, für die derzeit unload-Handler verwendet werden, sollten sich auf die bevorstehende Einstellung vorbereiten, indem sie vorhandene unload-Handler testen, sie entfernen oder migrieren oder als letzte Option die Einstellung verzögern, wenn mehr Zeit benötigt wird.
Danksagungen
Vielen Dank an Kenji Baheux, Fergal Daly, Adriana Jara und Jeremy Wagner für die Hilfe bei der Überprüfung dieses Artikels.
Hero-Image von Anja Bauermann auf Unsplash