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 eines Flags in Chrome 117 (September 2023)
Im Anschluss an diese Einrichtungs- und Testphasen wird die vorläufige 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 1% der Nutzer von Chrome 120 (Ende November 2023).
- Ende bei 100% der Nutzenden bis Ende des 3. Quartals 2024
- 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.
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: 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 funktioniert unload oft nicht, da Tabs häufig im Hintergrund geladen und dann abgebrochen 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 glaubt, dass ein mobiles Modell, bei dem bfcache auf Computern priorisiert wird, störender sein würde, da es auch dort unzuverlässiger wird, wenn dies in Chrome (und Firefox) bisher relativ zuverlässig war.unload Stattdessen wird das unload-Ereignis in Chrome vollständig entfernt. Bis dahin bleibt die Funktion auf Computern zuverlässig für diejenigen, die sich ausdrücklich gegen die Einstellung entschieden 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 in das Betriebssystem wechseln Nutzer häufig zwischen Tabs und löschen alte Tabs, ohne dass sie dazu „Seiten 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: 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. 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 ein, wenn der Nutzer die Seite verlässt, die Seite neu lädt oder das Browserfenster schließt. Daspagehide-Ereignis wird nicht ausgelöst, wenn die Seite einfach 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.
Nutzung von unload erkennen
Es gibt verschiedene Tools, mit denen du die Auftritte des unload-Ereignisses auf Seiten finden kannst. 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 umfassen eine back-forward-cache-Prüfung, mit der du Probleme erkennen kannst, durch die deine Seite möglicherweise nicht für den Back-Forward-Cache verwendet werden kann. Dies schließt die Verwendung des unload-Handlers ein.
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 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 das Back-Forward-Caching geeignet ist, 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.
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 sehen Sie ein Beispiel dafür, wie die Antwortobjektwarnung eines vorhandenen unload-Listeners aussieht:
{
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 langfristig nicht auf diese Methoden verlassen und stattdessen so schnell 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 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.
- Unternehmensrichtlinien: Tools, mit denen IT-Administratoren 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 können einzelne Entwickler die Einstellung von
unloadändern, um die Auswirkungen auf verschiedenen Websites zu testen.
Berechtigungsrichtlinie
Aus Chrome 115 wurde eine Berechtigungsrichtlinie hinzugefügt, die es Websites ermöglicht, unload-Handler zu deaktivieren und sofort vom bfcache zu profitieren und so 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. 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. Auf einer Seite können auf Wunsch trotzdem strengere Richtlinien 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 zwar weiterhin für einzelne Websites über die Berechtigungsrichtlinie überschrieben werden, werden aber standardmäßig weiterhin ausgelöst.
Diese Einstellungen können auch über Befehlszeilenschalter gesteuert werden.
Optionen vergleichen
In der folgenden Tabelle sind die verschiedenen Verwendungsmöglichkeiten der zuvor beschriebenen Optionen zusammengefasst:
| Einstellung vorziehen | Einstellung voranbringen (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 |
| 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 derzeit 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 Lektüre dieses Artikels.
Hero-Image von Anja Bauermann auf Unsplash