De unload
gebeurtenis wordt geleidelijk afgeschaft door de standaardinstelling geleidelijk te wijzigen, zodat unload
handlers niet meer op pagina's worden geactiveerd, tenzij een pagina er expliciet voor kiest om ze opnieuw in te schakelen.
Tijdlijn voor beëindiging
We merkten op dat het ontlaadgedrag waarschijnlijk al in januari 2019 aan veranderingen onderhevig zou zijn, toen we onze intentie aankondigden om een back/forward cache te implementeren . Parallel aan de implementatiewerkzaamheden hebben we een grote outreach uitgevoerd, wat resulteerde in een aanzienlijke daling van het losgebruik . Als aanvulling op dit bereik zijn we ook begonnen met het aanbieden van manieren om het effect van het beëindigen van het verwijderen uit Chrome 115 te testen:
- In het wild testen via de Permission-Policy API voor verwijderen in Chrome 115 (juli 2023)
- Lokaal testen door een vlag in Chrome 117 in te schakelen (september 2023)
Na deze outreach- en proeffasen verwachten we dat de zachte beëindiging als volgt zal worden uitgerold:
- Een fase waarin het ontladen geleidelijk zal ophouden te functioneren voor de top 50 van populaire sites ( referentie op het moment van schrijven).
- Te beginnen met 1% van de gebruikers vanaf Chrome 120 (eind november 2023).
- Eindigt met 100% van de gebruikers tegen het einde van het derde kwartaal van 2024
- Daarnaast zijn we van plan om vanaf het derde kwartaal van 2024 een generieke fase te starten waarin het lossen geleidelijk zal stoppen met functioneren op alle sites, te beginnen met 1% van de gebruikers en eindigend met 100% van de gebruikers tegen het einde van het eerste kwartaal van 2025.
Houd er rekening mee dat we ook een menu met afmeldingsopties bieden voor het geval deze tijdlijn voor zachte beëindiging niet voldoende tijd biedt om te migreren van het verwijderen. Ons doel is om deze zachte afschaffing te gebruiken om de tijdlijn te bepalen voor de laatste fase ( harde afschaffing van unload ) waarin deze opt-outs zullen worden verwijderd of verminderd.
![Tijdlijn van de beëindiging van het verwijderen.](https://developer.chrome.google.cn/static/docs/web-platform/deprecating-unload/image/unload-deprecation-timeline.png?authuser=9&hl=nl)
Achtergrond
unload
is ontworpen om te vuren wanneer het document wordt verwijderd. In theorie kan het worden gebruikt om code uit te voeren telkens wanneer een gebruiker een pagina verlaat, of als terugroepactie aan het einde van een sessie.
Scenario's waarin deze gebeurtenis het meest werd gebruikt, zijn onder meer:
- Gebruikersgegevens opslaan : sla gegevens op voordat u de pagina verlaat.
- Opruimtaken uitvoeren : open bronnen sluiten voordat de pagina wordt verlaten.
- Analyses verzenden : het verzenden van gegevens met betrekking tot gebruikersinteracties aan het einde van de sessie.
De unload
is echter uiterst onbetrouwbaar .
Op desktop-Chrome en Firefox is unload
redelijk betrouwbaar, maar het heeft een negatieve invloed op de prestaties van een site door het gebruik van bfcache (back/forward cache) te voorkomen.
Op mobiele browsers wordt unload
vaak niet uitgevoerd, omdat tabbladen vaak op de achtergrond worden geplaatst en vervolgens worden afgesloten. Om deze reden kiezen browsers ervoor om de bfcache op mobiel prioriteit te geven boven unload
, waardoor ze nog onbetrouwbaarder worden. Safari gebruikt dit gedrag ook op desktops.
Het Chrome-team is van mening dat het gebruik van het mobiele model, waarbij prioriteit wordt gegeven aan bfcache boven unload
op de desktop , disruptief zou zijn omdat het daar ook onbetrouwbaarder zou worden, terwijl dit voorheen redelijk betrouwbaar was in Chrome (en Firefox). In plaats daarvan is het doel van Chrome om de unload
gebeurtenis volledig te verwijderen. Tot die tijd blijft het betrouwbaar op de desktop voor degenen die zich expliciet hebben afgemeld voor de beëindiging.
Waarom zou u de unload
gebeurtenis afschaffen?
Het afschaffen van unload
is een belangrijke stap in een veel grotere erkenning van het web waarin we nu leven. De unload
gebeurtenis geeft een vals gevoel van controle over de levenscyclus van een app, wat steeds minder waar is voor de manier waarop we op internet surfen in de moderne computerwereld.
Mobiele besturingssystemen bevriezen of laden webpagina's vaak uit om geheugen te besparen, en desktopbrowsers doen dit nu ook steeds vaker om dezelfde redenen. Zelfs zonder tussenkomst van het besturingssysteem wisselen gebruikers zelf regelmatig van tabblad en sluiten ze oude tabbladen af zonder formeel "pagina's te verlaten".
Het verwijderen van de unload
gebeurtenis als verouderd is een erkenning dat wij als webontwikkelaars ervoor moeten zorgen dat ons paradigma overeenkomt met dat van de echte wereld en niet afhankelijk moeten zijn van verouderde concepten die niet langer waar zijn – als ze dat ooit al hebben gedaan.
Alternatieven om evenementen unload
In plaats van unload
wordt aanbevolen om het volgende te gebruiken:
-
visibilitychange
: Om te bepalen wanneer de zichtbaarheid van een pagina verandert. Deze gebeurtenis vindt plaats wanneer de gebruiker van tabblad wisselt, het browservenster minimaliseert of een nieuwe pagina opent. Beschouw dehidden
status als de laatste betrouwbare tijd om app- en gebruikersgegevens op te slaan. -
pagehide
: Om te bepalen wanneer de gebruiker de pagina heeft verlaten. Deze gebeurtenis vindt plaats wanneer de gebruiker de pagina verlaat, de pagina opnieuw laadt of het browservenster sluit. Depagehide
gebeurtenis wordt niet geactiveerd wanneer de pagina simpelweg wordt geminimaliseerd of naar een ander tabblad wordt geschakeld. Houd er rekening mee dat, aangezienpagehide
een pagina niet ongeschikt maakt voor de back/forward cache, het mogelijk is dat een pagina kan worden hersteld nadat deze gebeurtenis is geactiveerd. Als u in deze gebeurtenis bronnen opruimt, moeten deze mogelijk worden hersteld via paginaherstel.
De beforeunload
gebeurtenis heeft een iets ander gebruiksscenario voor unload
, omdat het een annuleerbare gebeurtenis is. Het wordt vaak gebruikt om gebruikers te waarschuwen voor niet-opgeslagen wijzigingen wanneer ze wegnavigeren. Deze gebeurtenis is ook onbetrouwbaar omdat deze niet wordt geactiveerd als een achtergrondtabblad wordt gedood. Het wordt aanbevolen om het gebruik van beforeunload
te beperken en het alleen voorwaardelijk toe te voegen . Gebruik in plaats daarvan de bovenstaande gebeurtenissen voor de meeste unload
.
Voor meer details, zie dit advies over het nooit gebruiken van de unload
.
Detecteer het gebruik van unload
Er zijn verschillende hulpmiddelen waarmee u de weergave van de unload
op pagina's kunt vinden. Hierdoor kunnen sites ontdekken of ze deze gebeurtenis gebruiken (in hun eigen code of via bibliotheken) en dus mogelijk worden beïnvloed door de aanstaande beëindiging.
Chrome-ontwikkelaarstools
Chrome DevTools bevat een back-forward-cache
audit waarmee u problemen kunt identificeren die ervoor kunnen zorgen dat uw pagina niet in aanmerking komt voor back-forward-cache, inclusief het gebruik van de unload
handler.
Volg deze stappen om de back-/forward-cache te testen:
Open DevTools op uw pagina en navigeer vervolgens naar Toepassing > Achtergrondservices > Back-forward cache .
Klik op Terug/vooruit-cache testen. Chrome brengt u automatisch naar
chrome://terms/
en terug naar uw pagina. U kunt ook op de knoppen Vorige en Volgende van de browser klikken.
Als uw pagina niet in aanmerking komt voor back-forward-caching, ziet u op het tabblad Back-forward-cache een lijst met problemen. Onder Actionable kun je zien of je unload
gebruikt:
![Chrome DevTools Back-forward cache-testtool die aangeeft dat er een unload-handler is gebruikt](https://developer.chrome.google.cn/static/docs/web-platform/deprecating-unload/image/chrome-devtools-forward-8640f1ef515a1.png?authuser=9&hl=nl)
Rapportage-API
De Reporting API kan worden gebruikt in combinatie met een alleen-lezen toestemmingsbeleid om het gebruik van unload
van uw websitegebruikers te detecteren.
Voor meer details, zie Rapportage-API gebruiken om lossingen te vinden
Bfcache notRestoredReasons
-API
De eigenschap notRestoredReasons
, toegevoegd aan de klasse PerformanceNavigationTiming
, rapporteert informatie over de vraag of documenten zijn geblokkeerd voor het gebruik van de bfcache bij navigatie, en waarom. Gebruiksinstructies vindt u hier . Dit is een voorbeeld van hoe de responsobjectwaarschuwing van een bestaande unload
listener eruit ziet:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
Controleer de toegang tot unload
Chrome beëindigt de unload
gebeurtenis geleidelijk. In de tussentijd kunt u verschillende tools gebruiken om dit gedrag onder controle te houden en u voor te bereiden op de komende beëindiging. Houd er rekening mee dat u op de lange termijn niet op deze technieken moet vertrouwen, en dat u van plan moet zijn om zo snel mogelijk naar de alternatieven te migreren.
Met de volgende opties kunt u unload
handlers in- of uitschakelen om te testen hoe uw site zonder deze zou werken, zodat u zich kunt voorbereiden op de komende beëindiging. Er zijn verschillende soorten beleid:
- Machtigingenbeleid : Dit is een platform-API waarmee site-eigenaren de toegang tot functies kunnen controleren, op site- of individueel paginaniveau, via het gebruik van HTTP-headers.
- Bedrijfsbeleid : tools waarmee IT-beheerders Chrome kunnen configureren voor hun organisatie of bedrijf. Ze kunnen worden geconfigureerd via een beheerdersdashboard, zoals de Google-beheerdersconsole .
- Chrome-vlaggen : hiermee kan een individuele ontwikkelaar de beëindigingsinstelling voor
unload
wijzigen om de impact op verschillende sites te testen.
Machtigingenbeleid
Er is een machtigingsbeleid toegevoegd vanuit Chrome 115 waarmee sites zich kunnen afmelden voor het gebruik van unload
handlers en onmiddellijk kunnen profiteren van de bfcache om de prestaties van de site te verbeteren. Bekijk deze voorbeelden om te zien hoe u dit voor uw site kunt instellen . Hierdoor kunnen sites een voorsprong nemen op de beëindiging van de unload
.
Dit wordt uitgebreid in Chrome 117 , zodat sites het omgekeerde kunnen doen en ervoor kunnen kiezen om te blijven proberen unload
handlers te activeren, aangezien Chrome de standaardinstelling wijzigt om deze in de toekomst niet te activeren. Bekijk deze voorbeelden om te zien hoe u kunt blijven toestaan dat unload handlers naar uw locatie vuren . Deze opt-in zal niet eeuwig blijven bestaan en moet worden gebruikt om sites de tijd te geven om weg te migreren van unload
.
Ondernemingsbeleid
Bedrijven die software hebben die afhankelijk is van de unload
gebeurtenis om correct te functioneren, kunnen het ForcePermissionPolicyUnloadDefaultEnabled
-beleid gebruiken om de geleidelijke afschaffing van apparaten onder hun beheer te voorkomen. Als je dit beleid inschakelt, blijft unload
standaard ingeschakeld voor alle oorsprongen. Een pagina kan nog steeds een strenger beleid instellen als hij dat wil. Net als de opt-out voor het toestemmingsbeleid is dit een hulpmiddel om potentiële brekende wijzigingen te beperken, maar het mag niet voor onbepaalde tijd worden gebruikt.
Chrome-vlaggen en opdrachtregelschakelaars
Naast het bedrijfsbeleid kunt u de beëindiging voor individuele gebruikers uitschakelen via de Chrome-vlaggen en opdrachtregelopties:
Als u chrome://flags/#deprecate-unload
dit enabled
wordt de standaardafschaffing naar voren gehaald en wordt voorkomen dat unload
handlers worden geactiveerd. Ze kunnen nog steeds per site worden overschreven via het machtigingsbeleid, maar blijven standaard actief.
Deze instellingen kunnen ook worden beheerd via opdrachtregelopties .
Vergelijking van opties
De volgende tabel vat de verschillende toepassingen van de eerder besproken opties samen:
Breng de afschrijving naar voren | Beëindiging vervroegen (met uitzonderingen) | Voorkom beëindiging om tijd vrij te maken voor een migratie | |
---|---|---|---|
Machtigingenbeleid (van toepassing op pagina's/sites) | Ja | Ja | Ja |
Ondernemingsbeleid (geldt voor apparaten) | Nee | Nee | Ja |
Chromen vlaggen (geldt voor individuele gebruikers) | Ja | Nee | Nee |
Chrome-opdrachtregelschakelaars (geldt voor individuele gebruikers) | Ja | Nee | Ja |
Conclusie
unload
handlers worden afgeschaft. Ze zijn lange tijd onbetrouwbaar geweest en het is niet gegarandeerd dat ze worden ontslagen in alle gevallen waarin een document wordt vernietigd. Bovendien zijn unload
handlers incompatibel met bfcache .
Sites die momenteel gebruik maken van unload
handlers moeten zich voorbereiden op deze aanstaande beëindiging door te testen op bestaande unload
handlers, deze te verwijderen of te migreren of, als laatste redmiddel, de beëindiging uit te stellen als er meer tijd nodig is.
Dankbetuigingen
Met dank aan Kenji Baheux, Fergal Daly, Adriana Jara en Jeremy Wagner voor hulp bij het beoordelen van dit artikel.
Hero-afbeelding door Anja Bauermann op Unsplash