De unload-gebeurtenis wordt beëindigd

Demián Renzulli

Barry Pollard

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 te schakelen in Chrome 117 (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 opt-out-opties 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.

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 de 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 : gegevens verzenden 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 voorrang 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 achterhaald 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 de hidden 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. De pagehide gebeurtenis wordt niet geactiveerd wanneer de pagina simpelweg wordt geminimaliseerd of naar een ander tabblad wordt geschakeld. Houd er rekening mee dat, aangezien pagehide 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:

1. Open DevTools op uw pagina en navigeer vervolgens naar Toepassing > Achtergrondservices > Back-forward cache .

2. 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:

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 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 siteprestaties 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, omdat Chrome de standaardinstelling wijzigt om deze in de toekomst niet te activeren. Bekijk deze voorbeelden voor informatie over hoe u kunt blijven toestaan ​​dat unload handlers naar uw site 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 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:

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