Das unload-Ereignis wird nach und nach eingestellt. Dabei wird die Standardeinstellung schrittweise geändert, sodass unload-Handler auf Seiten nicht mehr ausgelöst werden, es sei denn, eine Seite hat ausdrücklich zugestimmt, dass sie wieder aktiviert wird.
Zeitplan für die Einstellung
Wir haben festgestellt, dass sich das Verhalten beim Entladen wahrscheinlich bereits ab Januar 2019 ändern wird, als wir unsere Absicht bekannt gegeben haben, einen Back-Forward-Cache zu implementieren. Parallel zur Implementierung haben wir umfangreiche Maßnahmen ergriffen, was zu einem deutlichen Rückgang der Nutzung von Unload geführt hat. Als Ergänzung dazu bieten wir jetzt Möglichkeiten an, die Auswirkungen der Einstellung von Unload von Chrome 115 zu testen:
- In der Praxis über die Permission-Policy API für Unload in Chrome 115 (Juli 2023)
- Lokale Tests durch Aktivieren eines Flags in Chrome 117 (September 2023)
Nach der Kontaktaufnahme und der Testphase wird die vorläufige Einstellung voraussichtlich in Kraft treten:
- Eine auf einen Bereich reduzierte Phase, in der das Entladen nach und nach für die 50 beliebtesten Websites eingestellt wird (Referenz zum Zeitpunkt der Erstellung dieses Dokuments).
- Ab 1% der Nutzer*innen ab Chrome 120 (Ende November 2023).
- Endet bis Ende des 3. Quartals 2024 bei 100% der Nutzer*innen
- Darüber hinaus möchten wir ab dem 3. Quartal 2024 eine allgemeine Phase einleiten, in der Unload nach und nach auf allen Websites nicht mehr funktioniert – beginnend mit 1% der Nutzer und Ende des 1. Quartals 2025 bei 100% der Nutzer.
Hinweis: Wir bieten auch ein Menü mit Deaktivierungsoptionen für den Fall an, dass der Zeitplan für die langsame Einstellung nicht genügend Zeit für eine Migration weg von der Entladung gibt. Unser Ziel ist die vorläufige Einstellung, um den Zeitplan für die letzte Phase (harte Einstellung der Entladefunktion) zu informieren, in der diese Deaktivierungen entfernt oder reduziert werden.
Hintergrund
unload wird beim Entladen des Dokuments ausgelöst. Theoretisch kann damit immer dann Code ausgeführt werden, wenn ein Nutzer eine Seite verlässt, oder als Callback 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: Offene Ressourcen werden geschlossen, bevor die Seite verlassen wird.
- Analysedaten senden: Es werden Daten zu Nutzerinteraktionen am Ende der Sitzung gesendet.
Das Ereignis unload ist jedoch extrem unzuverlässig.
In Chrome und Firefox auf dem Computer ist unload relativ zuverlässig, wirkt sich aber negativ auf die Leistung einer Website aus, da die Nutzung von 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 gelöscht werden. Aus diesem Grund haben Browser den bfcache auf Mobilgeräten gegenüber unload priorisiert, wodurch sie noch unzuverlässiger werden. Safari verwendet dieses Verhalten auch auf Desktop-Computern.
Das Chrome-Team ist der Meinung, dass das mobile Modell, bei dem der bfcache-Speicher auf dem Computer Vorrang vor unload hat, Störungen verursachen würde, da dies auch dort unzuverlässiger wäre, obwohl dies in Chrome (und Firefox) bisher relativ zuverlässig war. Stattdessen wird das unload-Ereignis vollständig entfernt. Bis dahin funktioniert es weiterhin zuverlässig auf Desktop-Computern, wenn Nutzer sich ausdrücklich gegen die Einstellung entschieden haben.
Warum sollte das unload-Ereignis eingestellt werden?
Die Einstellung von unload ist ein wichtiger Schritt, um das Web, in dem wir heute leben, deutlich besser sichtbar zu machen. Das unload-Ereignis vermittelt ein Gefühl der Kontrolle über den App-Lebenszyklus, was in der modernen Computerwelt immer unwahr wird.
Mobile Betriebssysteme frieren häufig Webseiten ein oder entladen sie, um Arbeitsspeicher zu sparen, und Desktop-Browser tun dies aus denselben Gründen immer häufiger. Auch ohne das Eingreifen des Betriebssystems wechseln Nutzer häufig zwischen den Tabs und löschen alte Tabs, ohne die Seiten offiziell zu verlassen.
Das Entfernen des unload-Ereignisses als veraltet ist uns die Erkenntnis, dass wir als Webentwickler dafür sorgen müssen, dass unser Paradigma dem der Realität entspricht und nicht von veralteten Konzepten abhängig ist, die nicht mehr gültig sind – falls sie es jemals getan haben.
Alternativen zu unload-Ereignissen
Anstelle von unload wird empfohlen, Folgendes zu verwenden:
visibilitychange: Damit wird festgelegt, wann sich die Sichtbarkeit einer Seite ändert. Dieses Ereignis tritt ein, wenn der Nutzer den Tab wechselt, das Browserfenster minimiert oder eine neue Seite öffnet. Derhidden-Status ist der letzte zuverlässige Zeitpunkt zum Speichern von App- und Nutzerdaten.pagehide: Damit wird festgestellt, wann der Nutzer die Seite verlassen hat. Dieses Ereignis tritt ein, wenn der Nutzer die Seite verlässt, sie 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:pagehideführt nicht dazu, dass eine Seite nicht für den Back-Forward-Cache infrage kommt. Es ist aber möglich, dass sie nach dem Auslösen dieses Ereignisses wiederhergestellt werden kann. Wenn Sie bei 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 sich um ein stornierbares Ereignis handelt. Sie wird häufig verwendet, um Nutzer vor nicht gespeicherten Änderungen zu warnen, wenn sie die Seite verlassen. Dieses Ereignis ist ebenfalls nicht realisierbar, 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. Verwende stattdessen die oben genannten Ereignisse für die meisten unload-Ersetzungen.
Weitere Informationen finden Sie in diesem Hinweis zur Verwendung des unload-Handlers.
Nutzung von unload erkennen
Es gibt verschiedene Tools, mit denen du die Darstellung des unload-Ereignisses auf deinen Seiten finden kannst. So können Websites feststellen, ob sie dieses Ereignis verwenden – entweder in ihrem eigenen Code oder über Bibliotheken – und sind daher möglicherweise von der bevorstehenden Einstellung betroffen.
Leuchtturm
In Lighthouse gibt es eine no-unload-listeners-Prüfung, bei der Entwickler gewarnt werden, wenn auf ihren Seiten JavaScript-Code (auch JavaScript-Code aus Drittanbieterbibliotheken) einen unload-Event-Listener hinzufügt.
Chrome-Entwicklertools
Die Chrome-Entwicklertools umfassen eine back-foward-cache-Prüfung, mit deren Hilfe du Probleme identifizieren kannst, die möglicherweise verhindern, dass deine Seite den Back-Forward-Cache verwenden kann. Dazu gehört auch die Nutzung des unload-Handlers.
So testen Sie den Back-Forward-Cache:
Öffnen Sie auf Ihrer Seite die Entwicklertools und gehen Sie 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 Browserschaltflächen „Zurück“ und „Weiter“ klicken.
Wenn Ihre Seite nicht für das Back-Forward-Caching infrage kommt, 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 zusammen mit einer schreibgeschützten Berechtigungsrichtlinie verwendet werden, um die Nutzung von unload durch die Nutzer Ihrer Website zu ermitteln.
Weitere Informationen finden Sie unter Unloads mit der Reporting API finden.
Bfcache-notRestoredReasons-API
Die notRestoredReasons-Property, die der Klasse PerformanceNavigationTiming hinzugefügt wurde, enthält Informationen darüber, ob und warum der bfcache für Dokumente blockiert wurde. Hier finden Sie eine Nutzungsanleitung. Hier sehen Sie ein Beispiel dafür, wie die Antwortobjektwarnung eines vorhandenen unload-Listeners aussieht:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
Zugriff auf unload steuern
Das unload-Ereignis wird in Chrome schrittweise 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 Techniken verlassen sollten und dass Sie so schnell wie möglich zu den Alternativen wechseln 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 Admin-Konsole konfiguriert werden.
- Chrome-Flags: Mit dieser Einstellung kann ein einzelner Entwickler die Einstellung von
unloadändern, um die Auswirkungen auf verschiedene Websites zu testen.
Berechtigungsrichtlinie
In Chrome 115 wurde eine Berechtigungsrichtlinie hinzugefügt, die es Websites ermöglicht, die Verwendung von unload-Handlern zu deaktivieren und sofort vom bfcache zu profitieren, um die Websiteleistung zu verbessern. In diesen Beispielen sehen Sie, wie Sie dies für Ihre Website festlegen können. Dadurch können Websites die Einstellung von unload schonen.
Diese Funktion wird in Chrome 117 erweitert, damit Websites umgekehrt vorgehen und weiterhin versuchen, unload-Handler auszulösen, da Chrome die Standardeinstellung so ändert, dass sie nicht mehr ausgelöst wird. Diese Beispiele zeigen, wie Sie weiterhin zulassen, dass Unload-Handler für Ihre Website ausgelöst werden. Diese Aktivierung gilt nicht für immer. Sie sollte verwendet werden, um Websites etwas Zeit zu nehmen, weg von unload-Handlern zu migrieren.
Unternehmensrichtlinie
Unternehmen, deren Software auf das unload-Ereignis angewiesen ist, damit sie korrekt funktioniert, können mithilfe der Richtlinie ForcePermissionPolicyUnloadDefaultEnabled verhindern, dass die von ihnen kontrollierten Geräte schrittweise eingestellt werden. Wenn du diese Richtlinie aktivierst, ist unload weiterhin für alle Ursprünge aktiviert. Bei Bedarf können für eine Seite jedoch strengere Richtlinien festgelegt werden. Wie die Deaktivierungsrichtlinie für Berechtigungen handelt es sich auch hier um ein Tool, um potenzielle funktionsgefährdende Änderungen abzuschwächen. Es sollte jedoch nicht auf unbestimmte Zeit verwendet werden.
Chrome-Flags und Befehlszeilen-Switches
Neben der Unternehmensrichtlinie können Sie die Einstellung für einzelne Nutzer mithilfe der Chrome-Flags und Befehlszeilen-Switches deaktivieren:
Wenn Sie chrome://flags/#deprecate-unload auf enabled setzen, wird die Standardeinstellung für die Einstellung übernommen und unload-Handler können nicht mehr ausgelöst werden. Sie können zwar weiterhin auf Websitebasis über die Berechtigungsrichtlinie überschrieben werden, werden aber weiterhin standardmäßig ausgelöst.
Diese Einstellungen können auch über Befehlszeilen-Switches gesteuert werden.
Optionen im Vergleich
In der folgenden Tabelle sind die verschiedenen Verwendungsmöglichkeiten der oben erläuterten Optionen zusammengefasst:
| Einstellung fördern | Einstellung fördern (mit Ausnahmen) | Einstellung vermeiden, um den Zeitpunkt einer 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 |
| Chrome-Befehlszeilenschalter (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 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, entfernen oder migrieren oder als letzte Option die Einstellung verzögern, falls mehr Zeit benötigt wird.
Danksagungen
Vielen Dank an Kenji Baheux, Fergal Daly, Adriana Jara und Jeremy Wagner für die Unterstützung beim Durchlesen dieses Artikels.
Hero-Image von Anja Bauermann auf Unsplash