Entladen-Ereignis wird verworfen

Demián Renzulli

Barry Pollard

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:

• Tests in der Praxis über die Permission-Policy API für das Entladen in Chrome 115 (Juli 2023)
• 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 begrenzte Phase, in der die Funktion „Unload“ nach und nach für die 50 beliebtesten Websites (Referenz zum Zeitpunkt der Erstellung dieses Artikels) deaktiviert wird.
  • Ab Chrome 120 (Ende November 2023) für 1% der Nutzer.
  • Bis Ende des 3. Quartals 2024 für alle Nutzer
• Außerdem planen wir ab dem 3. Quartal 2024 eine allgemeine Phase, in der die Funktion „Unload“ nach und nach auf allen Websites eingestellt wird. Zuerst für 1% der Nutzer und bis Ende des 1. Quartals 2025 für 100% der Nutzer.

Falls dieser Zeitplan für die Einstellung nicht ausreicht, um von der Funktion „Unload“ wegzukommen, bieten wir auch ein Menü mit Deaktivierungsoptionen an. Unser Ziel ist es, anhand dieser vorläufigen Einstellung den Zeitplan für die letzte Phase (endgültige Einstellung von „unload“) zu erstellen, in der diese Deaktivierungsoptionen entfernt oder reduziert werden.

Hintergrund

unload soll ausgelöst 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: Senden von Daten zu Nutzerinteraktionen am Ende der Sitzung.

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 dem Computer weiterhin zuverlässig für Nutzer, die die Einstellung ausdrücklich deaktiviert haben.

Warum wird das Ereignis unload eingestellt?

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 Entfernen des unload-Ereignisses als veraltet ist eine Anerkennung dafür, dass 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

Statt unload wird Folgendes empfohlen:

• visibilitychange: Damit wird festgelegt, wann sich die Sichtbarkeit einer Seite ändert. Dieses Ereignis tritt auf, wenn der Nutzer den Tab wechselt, das Browserfenster minimiert oder eine neue Seite öffnet. Der Status hidden ist der letzte zuverlässige Zeitpunkt, um App- und Nutzerdaten zu speichern.
• 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 Ereignis pagehide wird nicht ausgelöst, wenn die Seite einfach minimiert oder zu einem anderen Tab gewechselt wird. Da pagehide eine Seite nicht für den Back-Forward-Cache disqualifiziert, kann sie nach dem Auslösen dieses Ereignisses wiederhergestellt werden. 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.unload

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:

1. Öffnen Sie auf Ihrer Seite die DevTools und gehen Sie zu Anwendung > Hintergrunddienste > Vor-/Zurück-Cache.

2. Klicken Sie auf Back-Forward-Cache testen. Chrome leitet Sie automatisch zu chrome://terms/ und dann zurück zu Ihrer Seite. 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 Leicht 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.

Weitere Informationen finden Sie unter Mit der Reporting API Datenentladungen finden.

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

Das unload-Ereignis wird in Chrome nach und nach eingestellt. 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 funktioniert. So können Sie sich auf die bevorstehende Einstellung vorbereiten. Es gibt verschiedene Arten von Richtlinien:

• Richtlinie zu Berechtigungen: 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 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 schon vor der Einstellung von unload entsprechend angepasst werden.

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 Handler für das Entladen ausgelöst werden. Diese Aktivierung ist zeitlich begrenzt und sollte genutzt 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.

Optionen vergleichen

In der folgenden Tabelle sind die verschiedenen Verwendungsmöglichkeiten der zuvor beschriebenen Optionen zusammengefasst:

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.

Betreiber von Websites, die derzeit unload-Handler verwenden, sollten sich auf die bevorstehende Einstellung vorbereiten. Dazu sollten sie nach vorhandenen unload-Handlern suchen, diese entfernen oder migrieren oder, als letzten Ausweg, die Einstellung verschieben, falls 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