Entladen-Ereignis wird verworfen

Demián Renzulli

Barry Pollard

Veröffentlicht am 10. August 2023, zuletzt aktualisiert am 14. Juli 2026

Das unload Ereignis wird schrittweise eingestellt. Dazu wird die Standardeinstellung so geändert, dass unload Handler auf Seiten nicht mehr ausgelöst werden, es sei denn, eine Seite aktiviert sie explizit wieder.

Zeitachse für die Einstellung

Wir haben bereits im Januar 2019 darauf hingewiesen, dass sich das Verhalten beim Entladen von Seiten wahrscheinlich ändern wird, als wir unsere Absicht bekannt gaben, einen Back-Forward-Cache zu implementieren. Parallel zu den Implementierungsarbeiten haben wir eine große Informationskampagne durchgeführt, die zu einem deutlichen Rückgang der Nutzung von „unload“ geführt hat. Um diese Kampagne zu ergänzen, haben wir auch Möglichkeiten angeboten, die Auswirkungen der Einstellung von „unload“ ab Chrome 115 zu testen:

• Tests in der Praxis mit der Permission-Policy API für „unload“ in Chrome 115 (Juli 2023)
• Lokale Tests durch Aktivieren eines Flags in Chrome 117 (September 2023)

Im Laufe des Jahres 2024 haben wir mehrere Probleme behoben, die den Beginn der Einführung verhindert haben. Im Laufe des Jahres 2025 haben wir die Einstellung auf die 50 wichtigsten Websites ausgeweitet:

Im Jahr 2026 haben wir mit der Einführung für alle Ursprünge begonnen. Dies geschieht in acht Meilensteinen (oder etwa 32 Wochen), wie in der folgenden Tabelle beschrieben.

Die vollständige Einführung basiert auf Seitenaufrufen (mit Konsistenz im Zeitverlauf) und nicht auf einzelnen Nutzern oder Websites, um die Auswirkungen auf Nutzer oder Websites nicht zu verstärken, wie in der Absicht zur Einstellung beschrieben.

Wir bieten auch eine Reihe von Deaktivierungsoptionen an, falls diese Zeitachse für die Einstellung nicht ausreicht, um von „unload“ zu migrieren.

Hintergrund

unload wurde so konzipiert, dass es ausgelöst wird, wenn das Dokument entladen wird. Theoretisch kann es verwendet werden, um Code auszuführen, wenn ein Nutzer eine Seite verlässt, oder als Callback am Ende einer Sitzung.

Zu den Szenarien, in denen dieses Ereignis am häufigsten verwendet wurde, gehören:

• Nutzerdaten speichern: Daten speichern, bevor die Seite verlassen wird.
• Bereinigungsaufgaben ausführen: Offene Ressourcen schließen, bevor die Seite verlassen wird.
• Analysedaten senden: Daten zu Nutzerinteraktionen am Ende der Sitzung senden.

Das unload Ereignis ist jedoch äußerst unzuverlässig.

In Chrome und Firefox auf dem Computer ist unload relativ zuverlässig, hat aber negative Auswirkungen auf die Leistung einer Website, da die Verwendung des Back-Forward-Cache verhindert wird.

In mobilen Browsern wird unload oft nicht ausgeführt, da Tabs häufig in den Hintergrund verschoben und dann beendet werden. Aus diesem Grund priorisieren Browser den Back-Forward-Cache auf Mobilgeräten gegenüber unload, was sie noch unzuverlässiger macht. Safari verwendet dieses Verhalten auch auf dem Computer.

Das Chrome-Team ist der Ansicht, dass die Verwendung des mobilen Modells, bei dem der Back-Forward-Cache auf dem Computer gegenüber unload priorisiert wird, störend wäre, da es dort ebenfalls unzuverlässiger würde. Bisher war es in Chrome (und Firefox) relativ zuverlässig. Stattdessen soll das unload-Ereignis in Chrome vollständig entfernt werden. Bis dahin bleibt es auf dem Computer in Chrome für Nutzer, die die Einstellung explizit deaktiviert haben, zuverlässig.

Warum wird das unload-Ereignis eingestellt?

Die Einstellung von unload ist ein wichtiger Schritt hin zu einer viel umfassenderen Anerkennung des Webs, in dem wir heute leben. Das unload-Ereignis vermittelt ein falsches Gefühl der Kontrolle über den App-Lebenszyklus, das in der modernen Computerwelt immer weniger der Realität entspricht.

Mobile Betriebssysteme frieren häufig Webseiten ein oder entladen sie, um Arbeitsspeicher zu sparen. Desktopbrowser tun dies aus denselben Gründen immer häufiger. Auch ohne Eingriffe des Betriebssystems wechseln Nutzer häufig zwischen Tabs und schließen alte Tabs, ohne Seiten offiziell zu verlassen.

Die Entfernung des unload-Ereignisses als veraltet ist ein Zeichen dafür, dass wir als Webentwickler dafür sorgen müssen, dass unser Paradigma der Realität entspricht und nicht auf veralteten Konzepten basiert, die nicht mehr zutreffen – falls sie es jemals getan haben.

Alternativen zu unload-Ereignissen

Statt unload wird Folgendes empfohlen:

• visibilitychange: Hiermit können Sie festlegen, 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. Betrachten Sie den Status hidden als den letzten zuverlässigen Zeitpunkt, um App- und Nutzerdaten zu speichern.
• pagehide: Hiermit können Sie festlegen, wann der Nutzer die Seite verlassen hat. Dieses Ereignis tritt ein, wenn der Nutzer die Seite verlässt, die Seite neu lädt oder das Browserfenster schließt. Das pagehide-Ereignis wird nicht ausgelöst, wenn die Seite minimiert oder zu einem anderen Tab gewechselt wird. Da pagehide eine Seite nicht für den Back-Forward-Cache ungeeignet macht, kann eine Seite nach dem Auslösen dieses Ereignisses wiederhergestellt werden. Wenn Sie in diesem Ereignis Ressourcen bereinigen, müssen sie möglicherweise bei der Wiederherstellung der Seite wiederhergestellt werden.

Das beforeunload-Ereignis hat einen etwas anderen Anwendungsfall als unload, da es abgebrochen werden kann. Es wird häufig verwendet, um Nutzer vor nicht gespeicherten Änderungen zu warnen, wenn sie die Seite verlassen. Dieses Ereignis ist ebenfalls unzuverlässig, da es nicht ausgelöst wird, wenn ein Hintergrundtab beendet wird. Es wird empfohlen, die Verwendung von beforeunload einzuschränken und es nur bedingt hinzuzufügen. Verwenden Sie stattdessen die zuvor genannten Ereignisse für die meisten unload-Ersetzungen.

Weitere Informationen finden Sie in diesem Hinweis zur Vermeidung der Verwendung des unload Handlers.

Verwendung von unload erkennen

Es gibt verschiedene Tools, mit denen Sie Vorkommen des unload-Ereignisses auf Seiten finden können. So können Websites herausfinden, ob sie dieses Ereignis verwenden – entweder in ihrem eigenen Code oder mit Bibliotheken – und daher von der bevorstehenden Einstellung betroffen sein könnten.

Chrome-Entwicklertools

Chrome-Entwicklertools enthalten eine back-forward-cache Prüfung, mit der Sie Probleme ermitteln 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 Entwicklertools und rufen Sie dann Anwendung > Hintergrunddienste > Back-Forward-Cache auf.

2. Klicken Sie auf Back-Forward-Cache testen . Chrome führt Sie automatisch zu chrome://terms/ und zurück zu Ihrer Seite. Alternativ können Sie auf die Schaltflächen „Zurück“ und „Weiter“ des Browsers klicken.

Wenn Ihre Seite nicht für den Back-Forward-Cache infrage kommt, wird auf dem Tab Back-Forward-Cache eine Liste mit Problemen angezeigt. Unter Aktionen können Sie sehen, ob Sie unload verwenden:

Reporting API

Die Reporting API kann in Verbindung mit einer schreibgeschützten Berechtigungsrichtlinie verwendet werden, um die Verwendung von unload durch Ihre Website-Nutzer zu erkennen.

Weitere Informationen finden Sie unter Reporting API verwenden, um „unload“-Ereignisse zu finden.

Bfcache notRestoredReasons API

Die notRestoredReasons Property wurde der PerformanceNavigationTiming Klasse hinzugefügt. Sie enthält Informationen dazu, ob Dokumente bei der Navigation an der Verwendung des bfcache gehindert wurden und warum. Hier sehen Sie ein Beispiel dafür, wie die Warnung des Antwortobjekts vor einem vorhandenen unload-Listener aussieht:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

Zugriff auf unload steuern

Chrome stellt das unload-Ereignis schrittweise ein. In der Zwischenzeit können Sie verschiedene Tools verwenden, um dieses Verhalten zu steuern und sich auf die bevorstehende Einstellung vorzubereiten. Beachten Sie, dass Sie sich nicht langfristig auf diese Techniken verlassen sollten und so bald wie möglich zu den Alternativen migrieren sollten.

Mit den folgenden Optionen können Sie unload-Handler aktivieren oder deaktivieren, um zu testen, wie Ihre Website ohne sie funktioniert, damit Sie sich auf die bevorstehende Einstellung vorbereiten können. Es gibt verschiedene Arten von Richtlinien:

• Berechtigungsrichtlinie: Dies ist eine Plattform-API für Websiteinhaber, mit der sie den Zugriff auf Funktionen auf Website- oder Seitenebene mithilfe von HTTP-Headern steuern können.
• Unternehmensrichtlinien: Tools für IT-Administratoren zum Konfigurieren von Chrome für ihre Organisation oder ihr Unternehmen. Sie können über ein Administratorfeld wie die Google Admin Console konfiguriert werden.
• Chrome-Flags: Damit kann ein einzelner Entwickler die Einstellung für die unload Einstellung ändern, um die Auswirkungen auf verschiedene Websites zu testen.

Berechtigungsrichtlinie

Ab Chrome 115 wurde eine Berechtigungsrichtlinie hinzugefügt, mit der Websites die Verwendung von unload Handlern deaktivieren und sofort vom Back-Forward-Cache profitieren können, um die Websiteleistung zu verbessern. In diesen Beispielen erfahren Sie, wie Sie diese Richtlinie für Ihre Website festlegen. So können Websites die Einstellung von unload vorwegnehmen.

Diese wurde in Chrome 117 erweitert, damit Websites das Gegenteil tun und sich dafür entscheiden können, weiterhin zu versuchen, unload Handler auszulösen, wie sie es jetzt tun. Chrome ändert die Standardeinstellung für diese Handler so, dass sie in Zukunft nicht mehr ausgelöst werden. In diesen Beispielen erfahren Sie, wie Sie weiterhin zulassen können, dass „unload“-Handler für Ihre Website ausgelöst werden. Wir empfehlen Websiteinhabern zwar, die Verwendung von unload-Handlern aufgrund ihrer Unzuverlässigkeit einzustellen, aber wir planen, diese Deaktivierungsoption für Websites, die sie verwenden müssen, noch lange zu unterstützen. Wenn Sie die Deaktivierung rückgängig machen, werden unload-Handler auf Mobilgeräten nicht zuverlässiger. Es wird lediglich der aktuelle Status quo wiederhergestellt.

Unternehmensrichtlinie

Unternehmen, deren Software auf das unload Ereignis angewiesen ist, um ordnungsgemäß zu funktionieren, können mit der ForcePermissionPolicyUnloadDefaultEnabled Richtlinie die schrittweise Einstellung für Geräte unter ihrer Kontrolle verhindern. Wenn Sie diese Richtlinie aktivieren, ist unload standardmäßig weiterhin für alle Ursprünge aktiviert. Eine Seite kann bei Bedarf eine strengere Richtlinie festlegen. Wie die Deaktivierung der Berechtigungsrichtlinie ist dies ein Tool, um potenzielle Breaking Changes zu vermeiden. Auch hier empfehlen wir Websiteinhabern, sich nicht mehr auf unload-Handler zu verlassen. Chrome plant jedoch, diese Deaktivierungsoption für Unternehmen für Websites, die sie verwenden müssen, noch lange zu unterstützen.

Chrome-Flags und Befehlszeilenoptionen

Neben der Unternehmensrichtlinie können Sie die Einstellung für einzelne Nutzer auch mit den Chrome-Flags und Befehlszeilenoptionen deaktivieren:

Wenn Sie chrome://flags/#deprecate-unload auf enabled setzen, wird die Standardeinstellung für die Einstellung vorverlegt und verhindert, dass unload Handler ausgelöst werden. Sie können weiterhin auf Websitebasis mit der Berechtigungsrichtlinie ü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 Verwendungszwecke der zuvor beschriebenen Optionen zusammengefasst:

Fazit

unload-Handler werden eingestellt. Sie sind seit Langem unzuverlässig und es gibt keine Garantie, dass sie in allen Fällen ausgelöst werden, in denen ein Dokument zerstört wird. Außerdem sind unload Handler nicht mit dem bfcache kompatibel.

Websites, die unload-Handler verwenden, sollten sich auf diese bevorstehende Einstellung vorbereiten, indem sie nach vorhandenen unload-Handlern suchen, sie entfernen oder migrieren oder die Einstellung als letzten Ausweg verzögern, wenn mehr Zeit benötigt wird.

Danksagungen

Vielen Dank an Kenji Baheux, Fergal Daly, Adriana Jara und Jeremy Wagner für ihr hilfreiches Feedback.

Titelbild von Anja Bauermann auf Unsplash