Gepubliceerd: 10 augustus 2023, Laatst bijgewerkt: 29 januari 2026
De unload gebeurtenis zal geleidelijk worden uitgefaseerd door de standaardinstellingen stapsgewijs aan te passen, zodat unload handlers niet langer worden geactiveerd op pagina's, tenzij een pagina er expliciet voor kiest om ze opnieuw in te schakelen.
Tijdschema voor uitfasering
We merkten al in januari 2019 op dat het gedrag van de unload-functie waarschijnlijk zou veranderen, toen we onze intentie aankondigden om een back/forward-cache te implementeren . Parallel aan de implementatie hebben we een grootschalige campagne gevoerd, wat resulteerde in een aanzienlijke daling van het gebruik van de unload-functie . Als aanvulling op deze campagne zijn we ook begonnen met het aanbieden van mogelijkheden om het effect van het afschaffen van de unload-functie vanaf Chrome 115 te testen.
- In de praktijk testen met de Permission-Policy API voor het verwijderen van elementen in Chrome 115 (juli 2023)
- Lokale tests door een vlag in Chrome 117 (september 2023) in te schakelen.
In de loop van 2024 hebben we verschillende problemen aangepakt die de start van de uitrol belemmerden, en in de loop van 2025 hebben we de uitfasering uitgerold naar de 50 belangrijkste websites.
| Mijlpaal | Mijlpaaldatum | Top 50 websites | % van andere oorsprong |
|---|---|---|---|
| 135 | 26 maart 2025 | 1 ( www.google.com ) | 0 |
| 139 | 30 juli 2025 | 5 | 0 |
| 140 | 27 augustus 2025 | 10 | 0 |
| 141 | 24 september 2025 | 25 | 0 |
| 142 | 22 oktober 2025 | 50 | 0 |
Nu we de uitfasering voor de 50 meest gebruikte sites hebben afgerond, hebben we verdere goedkeuring gekregen om dit in 8 fasen (of ongeveer 32 weken) uit te rollen naar alle sites, zoals gedetailleerd in de volgende tabel.
| Mijlpaal | Mijlpaaldatum | Top 50 websites | Percentage van Chrome-paginaladingen voor alle sites |
|---|---|---|---|
| 146 | 10 maart 2026 | 50 | 1 |
| 147 | 7 april 2026 | 50 | 5 |
| 148 | 5 mei 2026 | 50 | 10 |
| 149 | 2 juni 2026 | 50 | 20 |
| 150 | 30 juni 2026 | 50 | 40 |
| 151 | 28 juli 2026 | 50 | 60 |
| 152 | 25 augustus 2026 | 50 | 80 |
| 153 | 22 september 2026 | 50 | 100 |
De volledige uitrol is gebaseerd op paginaweergaven (met consistentie in de tijd), in plaats van op individuele gebruikers of sites, om te voorkomen dat bepaalde gebruikers of sites meer worden getroffen dan anderen, zoals beschreven in het voornemen tot uitfasering .
Houd er rekening mee dat we ook een menu met opt-out-opties aanbieden voor het geval deze afbouwperiode niet voldoende tijd biedt om van unload over te stappen. Ons doel is om deze geleidelijke afbouw te gebruiken als basis voor de planning van de laatste fase ( de definitieve afbouw van unload ), waarin deze opt-out-opties zullen worden verwijderd of beperkt.
Achtergrond
unload is ontworpen om te worden uitgevoerd wanneer het document wordt afgesloten. In theorie kan deze functie worden gebruikt om code uit te voeren wanneer een gebruiker een pagina verlaat, of als een callback-functie aan het einde van een sessie.
Scenario's waarin deze gebeurtenis het meest werd gebruikt, zijn onder andere:
- Gebruikersgegevens opslaan : Sla gegevens op voordat u de pagina verlaat.
- Opruimtaken uitvoeren : geopende bronnen sluiten voordat de pagina wordt verlaten.
- Analysegegevens verzenden : Gegevens met betrekking tot gebruikersinteracties verzenden aan het einde van de sessie.
Het unload de gegevens is echter uiterst onbetrouwbaar .
Op desktopversies van Chrome en Firefox is unload redelijk betrouwbaar, maar het heeft een negatieve invloed op de prestaties van een website doordat het gebruik van bfcache (back/forward cache) wordt geblokkeerd.
Op mobiele browsers wordt unload vaak niet uitgevoerd, omdat tabbladen regelmatig naar de achtergrond worden geplaatst en vervolgens worden gesloten. Om die reden geven browsers op mobiele apparaten prioriteit aan bfcache 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 bfcache prioriteit krijgt boven unload , op desktops storend zou zijn en de betrouwbaarheid ervan zou verminderen . Voorheen was dit in Chrome (en Firefox) juist redelijk betrouwbaar. Daarom wil Chrome de unload gebeurtenis volledig verwijderen. Tot die tijd blijft de functie betrouwbaar op desktops voor gebruikers die zich expliciet hebben afgemeld voor deze afschaffing.
Waarom wordt de unload gebeurtenis afgeschaft?
Het afschaffen van unload is een belangrijke stap in een bredere erkenning van het web waarin we nu leven. De unload gebeurtenis geeft een vals gevoel van controle over de levenscyclus van de applicatie, wat steeds minder overeenkomt met hoe we tegenwoordig op het web surfen.
Mobiele besturingssystemen bevriezen of sluiten webpagina's regelmatig af om geheugen te besparen, en desktopbrowsers doen dit nu ook steeds vaker om dezelfde redenen. Zelfs zonder tussenkomst van het besturingssysteem wisselen gebruikers zelf vaak tussen tabbladen en sluiten ze oude tabbladen af zonder de pagina's formeel te verlaten.
Het verwijderen van de unload gebeurtenis als verouderd is een erkenning dat wij als webontwikkelaars ervoor moeten zorgen dat ons paradigma aansluit bij de realiteit en niet afhankelijk zijn van verouderde concepten die niet langer opgaan – als ze dat al ooit deden.
Alternatieven voor unload van gebeurtenissen
In plaats van unload wordt aangeraden om het volgende te gebruiken:
-
visibilitychange: Hiermee wordt bepaald wanneer de zichtbaarheid van een pagina verandert. Dit gebeurt wanneer de gebruiker van tabblad wisselt, het browservenster minimaliseert of een nieuwe pagina opent. Beschouw dehiddenstatus als het laatste betrouwbare moment waarop app- en gebruikersgegevens zijn opgeslagen. -
pagehide: Deze gebeurtenis wordt gebruikt om te bepalen wanneer de gebruiker de pagina heeft verlaten. Dit gebeurt wanneer de gebruiker de pagina verlaat, de pagina opnieuw laadt of het browservenster sluit. Depagehidegebeurtenis wordt niet geactiveerd wanneer de pagina wordt geminimaliseerd of naar een ander tabblad wordt overgeschakeld. Houd er rekening mee dat, aangezienpagehideeen 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 resources opschoont, moeten deze mogelijk opnieuw worden hersteld wanneer de pagina wordt hersteld.
De beforeunload gebeurtenis heeft een iets ander gebruiksdoel dan unload , omdat het een annuleerbare gebeurtenis is. Het wordt vaak gebruikt om gebruikers te waarschuwen voor niet-opgeslagen wijzigingen bij het verlaten van een venster. Deze gebeurtenis is echter onbetrouwbaar, omdat deze niet wordt geactiveerd als een tabblad op de achtergrond wordt gesloten. Het is aan te raden het gebruik van beforeunload te beperken en het alleen voorwaardelijk toe te voegen . Gebruik in plaats daarvan de eerder genoemde gebeurtenissen voor de meeste vervangingen unload .
Zie voor meer informatie dit advies over het nooit gebruiken van de unload handler .
Detecteer het gebruik van unload
Er zijn verschillende tools waarmee je kunt achterhalen of de unload -gebeurtenis op pagina's voorkomt. Hierdoor kunnen websites ontdekken of ze deze gebeurtenis gebruiken – in hun eigen code of via libraries – en dus mogelijk getroffen worden door de aanstaande afschaffing ervan.
Chrome-ontwikkelaarstools
Chrome DevTools bevat een back-forward-cache audit waarmee u problemen kunt opsporen die ervoor kunnen zorgen dat uw pagina niet in aanmerking komt voor back-forward-caching, waaronder het gebruik van de unload handler.
Volg deze stappen om de back/forward-cache te testen:
Open op je pagina de ontwikkelaarstools en ga vervolgens naar Toepassing > Achtergrondservices > Back/forward cache .
Klik op 'Terug/Vooruit cache testen'. Chrome brengt je automatisch naar
chrome://terms/en vervolgens terug naar je pagina. Je kunt ook de terug- en vooruitknoppen van de browser gebruiken.
Als uw pagina niet in aanmerking komt voor back/forward-caching, toont het tabblad Back/forward-cache een lijst met problemen. Onder 'Actiepunten' kunt u zien of u unload gebruikt.
Rapportage-API
De rapportage-API kan in combinatie met een alleen-lezen toegangsbeleid worden gebruikt om het gebruik van unload door websitegebruikers te detecteren.
Zie voor meer informatie: De 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 werden geblokkeerd voor het gebruik van de bfcache tijdens navigatie, en waarom. Dit is een voorbeeld van hoe het responsobject eruitziet dat waarschuwt voor een bestaande unload listener:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-listener"}
],
src: null,
url: "https://www.example.com/page/"
}
Beheer de toegang tot unload
Chrome zal de unload gebeurtenis geleidelijk uitfaseren. In de tussentijd kunt u verschillende tools gebruiken om dit gedrag te beheren en u voor te bereiden op de aanstaande uitfasering. Houd er rekening mee dat u op de lange termijn niet op deze technieken moet vertrouwen en dat u zo snel mogelijk moet overstappen op alternatieven.
Met de volgende opties kunt u unload handlers in- of uitschakelen om te testen hoe uw site zonder deze handlers zou werken, zodat u zich kunt voorbereiden op de aanstaande uitfasering. Er zijn verschillende soorten beleidsregels:
- Toegangsbeleid : Dit is een platform-API waarmee site-eigenaren de toegang tot functies kunnen beheren, op site- of paginaniveau, met behulp van HTTP-headers.
- Bedrijfsbeleid : Hulpmiddelen voor IT-beheerders om Chrome te configureren voor hun organisatie of bedrijf. Dit kan worden geconfigureerd via een beheerderspaneel, zoals de Google Admin Console .
- Chrome-vlaggen : Hiermee kan een individuele ontwikkelaar de instelling voor het afschaffen van de
unload-functie wijzigen om de impact ervan op verschillende websites te testen.
Toestemmingsbeleid
Vanaf Chrome versie 115 is er een machtigingsbeleid toegevoegd waarmee websites kunnen afzien van het gebruik van unload handlers en direct kunnen profiteren van bfcache om de siteprestaties te verbeteren. Bekijk deze voorbeelden om te zien hoe u dit voor uw site kunt instellen . Dit stelt websites in staat om de uitfasering van unload handlers voor te zijn.
In Chrome 117 wordt dit uitgebreid, zodat websites het omgekeerde kunnen doen en ervoor kunnen kiezen om te blijven proberen unload handlers te activeren, aangezien Chrome de standaardinstelling hiervoor in de toekomst wijzigt naar niet-activeren. Zie deze voorbeelden over hoe u kunt blijven toestaan dat unload-handlers voor uw website worden geactiveerd . Deze opt-in blijft niet permanent en moet worden gebruikt om websites de tijd te geven om over te stappen van unload handlers naar een ander systeem.
Ondernemingsbeleid
Bedrijven met software die afhankelijk is van de unload -gebeurtenis voor een correcte werking, kunnen het beleid ForcePermissionPolicyUnloadDefaultEnabled gebruiken om de geleidelijke uitfasering voor apparaten onder hun beheer te voorkomen. Door dit beleid in te schakelen, blijft unload standaard ingeschakeld voor alle origins. Een pagina kan desgewenst nog steeds een strenger beleid instellen. Net als de opt-out voor het machtigingsbeleid is dit een hulpmiddel om potentiële ingrijpende wijzigingen te beperken, maar het mag niet onbeperkt worden gebruikt.
Chrome-vlaggen en commandoregelopties
Naast het bedrijfsbeleid kunt u de afschaffing ook voor individuele gebruikers uitschakelen met behulp van Chrome-vlaggen en opdrachtregelopties:
Door chrome://flags/#deprecate-unload this op enabled te zetten, wordt de standaardwaarde voor het afschaffen van de functie geactiveerd en worden unload handlers niet meer uitgevoerd. Deze handlers kunnen nog steeds per site worden overschreven met behulp van het machtigingsbeleid, maar zullen standaard wel blijven werken.
Deze instellingen kunnen ook worden beheerd via opdrachtregelparameters .
Vergelijking van opties
De volgende tabel geeft een overzicht van de verschillende toepassingen van de eerder besproken opties:
| Versnel de afschrijving. | Vervroeg de afschaffing (met uitzonderingen) | Voorkom dat functies verouderd raken om tijd vrij te maken voor een migratie. | |
|---|---|---|---|
| Toestemmingsbeleid (Van toepassing op pagina's/sites) | Ja | Ja | Ja |
| Ondernemingsbeleid (geldt voor apparaten) | Nee | Nee | Ja |
| Chrome-vlaggen (geldt voor individuele gebruikers) | Ja | Nee | Nee |
| Chrome-opdrachtregelopties (geldt voor individuele gebruikers) | Ja | Nee | Ja |
Conclusie
unload handlers worden uitgefaseerd. Ze zijn al lange tijd onbetrouwbaar en het is niet gegarandeerd dat ze in alle gevallen worden geactiveerd wanneer een document wordt verwijderd. Bovendien zijn unload handlers incompatibel met bfcache .
Websites die gebruikmaken van unload handlers moeten zich voorbereiden op deze aanstaande uitfasering door te controleren of er nog unload handlers bestaan, deze te verwijderen of te migreren, of, als laatste redmiddel, de uitfasering uit te stellen als meer tijd nodig is.
Dankbetuigingen
Met dank aan Kenji Baheux, Fergal Daly, Adriana Jara en Jeremy Wagner voor hun hulp bij het nakijken van dit artikel.
Hoofdafbeelding door Anja Bauermann op Unsplash