Veröffentlicht: 10. August 2023, zuletzt aktualisiert: 11. März 2025
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
Bereits im Januar 2019 haben wir angekündigt, dass wir einen Back-Forward-Cache implementieren möchten. Dabei haben wir darauf hingewiesen, dass das Verhalten beim Entladen wahrscheinlich geändert wird. 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 mit der Permission-Policy API for unload in Chrome 115 (Juli 2023)
- Lokale Tests durch Aktivieren einer Flag in Chrome 117 (September 2023)
Im Laufe des Jahres 2024 haben wir mehrere Probleme behoben, die den Start des Roll-outs verhindert haben.
Hier ist der aktuelle Zeitplan für die Einstellung des Ereignisses unload:
| Meilenstein | Meilensteindatum | Top 50-Websites | % der anderen Quellen |
|---|---|---|---|
| 135 | 26. März 2025 | 1 (www.google.com) |
0 |
| 136 | 23. April 2025 | 5 | 0 |
| 137 | 21. Mai 2025 | 25 | 0 |
| 138 | 18. Juni 2025 | 50 | 0 |
Nach Abschluss der Einführung auf den 50 wichtigsten Websites werden wir die Einführung pausieren und ein bis zwei Meilensteine abwarten. Anschließend holen wir weitere Genehmigungen ein, um die Funktion über die nächsten acht Meilensteine (ca. 32 Wochen) auf alle Ursprünge auszuweiten. Das würde vorläufig so aussehen:
| Meilenstein | Meilensteindatum | Top 50-Websites | % der anderen Quellen |
|---|---|---|---|
| 140 | 27. August 2025 | 50 | 1 |
| 141 | 24. September 2025 | 50 | 5 |
| 142 | 22. Oktober 2025 | 50 | 10 |
| 143 | 19. November 2025 | 50 | 20 |
| 144 | 17. Januar 2026 | 50 | 40 |
| 145 | 4. Februar 2026 | 50 | 60 |
| 146 | 4. März 2026 | 50 | 80 |
| 147 | 1. April 2026 | 50 | 100 |
Falls Sie nicht rechtzeitig von der Funktion „Unload“ migrieren können, bieten wir Ihnen ein Menü mit Deaktivierungsoptionen. Wir möchten mit dieser vorläufigen Einstellung den Zeitplan für die letzte Phase (endgültige Einstellung von „unload“) festlegen, 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 Rückruf 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 vor 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 höheren Unzuverlässigkeit führen würde, obwohl es in Chrome (und Firefox) bisher relativ zuverlässig war. Stattdessen wird das unload-Ereignis in Chrome vollständig entfernt. Bis dahin ist die Funktion auf Computern für Nutzer verfügbar, die die Einstellung ausdrücklich deaktiviert haben.
Warum wird das Ereignis unload eingestellt?
Die Einstellung von unload ist ein wichtiger Schritt in Richtung einer viel größeren Anerkennung 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 geschieht jetzt auch immer häufiger aus denselben Gründen in Desktop-Browsern. 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
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 Statushiddenist 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 Ereignispagehidewird nicht ausgelöst, wenn die Seite minimiert oder zu einem anderen Tab gewechselt wird. Dapagehideeine Seite nicht für den Back-Forward-Cache disqualifiziert, kann eine Seite 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 mithilfe von 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:
Öffnen Sie auf Ihrer Seite die DevTools und gehen Sie zu Anwendung > Hintergrunddienste > Vor-/Zurück-Cache.
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. Hier ein Beispiel für die Warnung im Antwortobjekt eines vorhandenen unload-Listeners:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-listener"}
],
src: null,
url: "https://www.example.com/page/"
}
Zugriff auf unload steuern
Das Ereignis unload 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. Sie sollten diese Techniken jedoch nicht langfristig verwenden, sondern so bald wie möglich zu den Alternativen migrieren.
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 mithilfe 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 Administrator-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 zu 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 festlegen. 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 nicht dauerhaft verfügbar 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 mithilfe der 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 auf Websiteebene mithilfe der Berechtigungsrichtlinie überschrieben werden, werden aber weiterhin standardmäßig 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:
| Einstellung vorziehen | Einstellung vorziehen (mit Ausnahmen) | Einstellung verhindern, um Zeit für eine Migration zu haben | |
|---|---|---|---|
| Richtlinie zu Berechtigungen (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 |
| Chrome-Befehlszeilenoptionen (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.
Betreiber von Websites, die unload-Handler verwenden, sollten sich auf die bevorstehende Einstellung vorbereiten. Prüfen Sie, ob vorhandene unload-Handler vorhanden sind, entfernen oder migrieren Sie sie oder verschieben Sie die Einstellung als letzten Ausweg, falls Sie mehr Zeit benötigen.
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