Das unload-Ereignis wird nach und nach eingestellt. Dazu wird die Standardeinstellung schrittweise geändert, sodass unload-Handler auf Seiten nicht mehr ausgelöst werden, es sei denn, eine Seite hat explizit ihre Reaktivierung aktiviert.
Zeitplan für die Einstellung
Wir haben festgestellt, dass sich das Unload-Verhalten wahrscheinlich schon ab Januar 2019 ändern wird, als wir angekündigt haben, einen Back-Forward-Cache zu implementieren. Parallel zur Implementierung führten wir eine größere Reichweite durch, was zu einem erheblichen Rückgang der Unload-Nutzung führte. Als Ergänzung zu dieser Einführung bieten wir außerdem Möglichkeiten an, die Auswirkungen der Einstellung des Unloads von 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 eines Flags in Chrome 117 (September 2023)
Nach diesen Einrichtungs- und Testphasen erwarten wir mit der vorläufigen Einstellung Folgendes:
- 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
- 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. Wir möchten diese vorläufige Einstellung nutzen, um einen Zeitplan für die letzte Phase (vollständige Einstellung von Unload) festzulegen, in der diese Deaktivierungen entfernt oder reduziert werden.
Hintergrund
unload wurde so entwickelt, dass sie beim Entladen des Dokuments ausgelöst wird. Theoretisch kann sie verwendet werden, um Code immer dann auszuführen, wenn ein Nutzer eine Seite verlässt, oder als Rückruf am Ende der Sitzung.
Szenarien, in denen dieses Ereignis am häufigsten verwendet wurde:
- Nutzerdaten speichern: Sie können Daten speichern, bevor Sie die Seite verlassen.
- Bereinigungsaufgaben ausführen: Schließen Sie alle geöffneten Ressourcen, bevor Sie die Seite verlassen.
- Analysedaten senden: Es werden Daten zu den Nutzerinteraktionen am Ende der Sitzung gesendet.
Allerdings ist das unload-Ereignis äußerst unzuverlässig.
In Chrome und Firefox für Computer ist unload relativ zuverlässig, wirkt sich aber negativ auf die Leistung der Website aus, da die Verwendung von bfcache (Back-Forward-Cache) verhindert wird.
In mobilen Browsern funktioniert unload häufig nicht, da Tabs häufig im Hintergrund geladen und dann abgebrochen werden. Aus diesem Grund priorisieren Browser den bfcache auf Mobilgeräten gegenüber unload und sind somit noch unzuverlässiger. Safari verwendet dieses Verhalten auch auf Desktop-Computern.
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 wäre, wenn dies in Chrome (und Firefox) bisher relativ zuverlässig war.unload Stattdessen ist das Ziel von Chrome, das unload-Ereignis vollständig zu entfernen. Bis dahin bleibt die Funktion auf Computern zuverlässig für diejenigen, die sich ausdrücklich gegen die Einstellung entschieden haben.
Warum sollte das Ereignis unload eingestellt werden?
Die Einstellung von unload ist ein wichtiger Schritt, um das Web, in dem wir leben, besser zu erkennen. Das unload-Ereignis vermittelt ein falsches Gefühl der Kontrolle des Anwendungslebenszyklus, was in der modernen Computerwelt immer unwahrer wird, wie wir im Web surfen.
Mobile Betriebssysteme frieren häufig ein oder entladen Webseiten, um Speicher zu sparen, und Desktop-Browser tun dies inzwischen immer mehr 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 unload-Ereignis als veraltet zu entfernen, ist eine Erkenntnis, dass wir als Webentwickler dafür sorgen müssen, dass unser Paradigma dem der realen Welt entspricht. Sie dürfen nicht von veralteten Konzepten abhängig sein, die nicht mehr wahr sind, falls sie das jemals getan haben sollten.
Alternativen zu unload-Veranstaltungen
Anstelle von unload wird 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 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. 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 in diesem Termin Ressourcen bereinigen, müssen sie möglicherweise bei der Seitenwiederherstellung wiederhergestellt werden.
Das Ereignis beforeunload hat einen etwas anderen Anwendungsfall als unload, da es ein abgebrochenes 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 unzuverlässig, da es nicht ausgelöst wird, wenn ein Hintergrund-Tab gelöscht wird. Es wird empfohlen, die Verwendung von beforeunload einzuschränken und nur bedingt hinzuzufügen. Verwenden Sie stattdessen für die meisten unload-Ersetzungen die oben genannten Ereignisse.
Weitere Informationen finden Sie in dieser Empfehlung, den unload-Handler niemals zu verwenden.
Nutzung von unload erkennen
Es gibt verschiedene Tools, mit denen du die Auftritte des unload-Ereignisses auf Seiten finden kannst. So können Websites feststellen, ob sie dieses Ereignis verwenden – entweder in ihrem eigenen Code oder über Bibliotheken – und können von der bevorstehenden Einstellung betroffen sein.
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 auf deiner Seite die Entwicklertools und gehe 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 auf die Zurück- und Vorwärts-Schaltflächen des Browsers 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.
Bfcache notRestoredReasons-API
Das Attribut notRestoredReasons, das der Klasse PerformanceNavigationTiming hinzugefügt wurde, gibt Informationen dazu, ob und aus welchem Grund das Verwenden des bfcache durch Dokumente blockiert wurde. Eine Nutzungsanleitung finden Sie 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
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 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 funktioniert. So sind Sie auf die bevorstehende Einstellung vorbereitet. 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.
- Unternehmensrichtlinien: Tools, mit denen IT-Administratoren Chrome für ihre Organisation oder ihr Unternehmen konfigurieren können. Diese lassen sich über ein Admin-Steuerfeld wie die Admin-Konsole konfigurieren.
- 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. Diese Beispiele zeigen, wie Sie dies für Ihre Website festlegen. So können Websites die Einstellung von unload vorantreiben.
Dies wird in Chrome 117 erweitert, damit Websites umgekehrt werden und weiterhin versuchen können, unload-Handler auszulösen, da Chrome die Standardeinstellung so ändert, dass diese in Zukunft nicht ausgelöst werden. Diese Beispiele zeigen, wie Sie weiterhin zulassen, dass Unload-Handler für Ihre Website 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 auf das unload-Ereignis angewiesen ist, um ordnungsgemäß zu funktionieren, können mit der Richtlinie ForcePermissionPolicyUnloadDefaultEnabled verhindern, dass ihre verwalteten Geräte nach und nach eingestellt werden. Wenn Sie diese Richtlinie aktivieren, ist unload weiterhin standardmäßig für alle Ursprünge aktiviert. Auf einer Seite können auf Wunsch trotzdem strengere Richtlinien festgelegt werden. Wie bei der Deaktivierung der Berechtigungsrichtlinie ist auch dieses Tool ein Tool zum Minimieren potenzieller funktionsgefährdender Änderungen. Es sollte jedoch nicht unbegrenzt verwendet werden.
Chrome-Flags und Befehlszeilenparameter
Neben der Unternehmensrichtlinie können Sie die Einstellung für einzelne Nutzer über die Chrome-Flags und Befehlszeilen-Switches deaktivieren:
Wenn Sie chrome://flags/#deprecate-unload auf enabled setzen, wird die Standardeinstellung für die Einstellung übernommen und es wird verhindert, dass unload-Handler ausgelöst werden. 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.
Vergleich der Optionen
In der folgenden Tabelle sind die verschiedenen Verwendungsmöglichkeiten der zuvor erläuterten Optionen zusammengefasst:
| Einstellung vorantreiben | Einstellung voranbringen (mit Ausnahmen) | Einstellung verhindern, um den Zeitpunkt für eine Migration zu sichern | |
|---|---|---|---|
| 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 schon lange unzuverlässig und werden nicht in allen Fällen ausgelöst, in denen ein Dokument zerstört 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 Lektüre dieses Artikels.
Hero-Image von Anja Bauermann auf Unsplash