Wycofuję zdarzenie unload

Demián Renzulli

Barry Pollard

Data publikacji: 10 sierpnia 2023 r., ostatnia aktualizacja: 29 stycznia 2026 r.

unloadZdarzenie będzie stopniowo wycofywane przez stopniowe zmienianie ustawienia domyślnego, tak aby moduły obsługi unload przestały uruchamiać się na stronach, chyba że strona wyraźnie włączy je ponownie.

Harmonogram wycofywania

Zauważyliśmy, że zachowanie funkcji unload prawdopodobnie ulegnie zmianom już w styczniu 2019 r., kiedy ogłosiliśmy zamiar wdrożenia pamięci podręcznej stanu strony internetowej. Równolegle z wdrażaniem zmian prowadziliśmy szeroko zakrojone działania informacyjne, które doprowadziły do znacznego spadku użycia funkcji zwalniania. Aby uzupełnić te działania, zaczęliśmy też oferować sposoby testowania wpływu wycofania zdarzenia unload w Chrome 115:

• Testowanie w warunkach rzeczywistych przy użyciu interfejsu Permission-Policy API dla zdarzenia unload w Chrome 115 (lipiec 2023 r.)
• Testowanie lokalne przez włączenie flagi w Chrome 117 (wrzesień 2023 r.)

W 2024 roku rozwiązaliśmy kilka problemów, które uniemożliwiały rozpoczęcie wdrażania, a w 2025 roku wycofaliśmy tę funkcję w przypadku 50 najpopularniejszych witryn.

Po zakończeniu wycofywania w przypadku 50 najpopularniejszych witryn uzyskaliśmy zgodę na wdrożenie tej zmiany we wszystkich źródłach w ramach 8 etapów (czyli w ciągu około 32 tygodni), jak pokazano w tabeli poniżej.

Pełne wdrożenie opiera się na liczbie wczytań strony (z zachowaniem spójności w czasie), a nie na poszczególnych użytkownikach lub witrynach, aby uniknąć większego wpływu na niektórych użytkowników lub witryny niż na innych, co szczegółowo opisano w informacji o zamiarze wycofania.

Pamiętaj, że oferujemy też menu opcji rezygnacji, jeśli ten harmonogram wycofywania nie zapewnia wystarczająco dużo czasu na przejście z unload. Naszym celem jest wykorzystanie tego łagodnego wycofania do określenia harmonogramu ostatniej fazy (ostatecznego wycofania funkcji unload), w której te rezygnacje zostaną usunięte lub ograniczone.

Tło

unload został zaprojektowany tak, aby uruchamiać się podczas zamykania dokumentu. Teoretycznie można go używać do uruchamiania kodu za każdym razem, gdy użytkownik opuszcza stronę, lub jako wywołania zwrotnego na koniec sesji.

Przykłady sytuacji, w których to zdarzenie jest najczęściej używane:

• Zapisywanie danych użytkowników: zapisz dane przed opuszczeniem strony.
• Wykonywanie zadań czyszczenia: zamykanie otwartych zasobów przed opuszczeniem strony.
• Wysyłanie danych analitycznych: wysyłanie danych związanych z interakcjami użytkownika na koniec sesji.

Jednak zdarzenie unload jest bardzo zawodne.

W przypadku Chrome i Firefoksa na komputerach unload jest dość niezawodny, ale negatywnie wpływa na wydajność witryny, ponieważ uniemożliwia korzystanie z pamięci podręcznej stanu strony internetowej.

W przeglądarkach mobilnych funkcja unload często nie działa, ponieważ karty są często przenoszone w tle, a następnie zamykane. Z tego powodu przeglądarki na urządzeniach mobilnych traktują pamięć podręczną wstecz i do przodu jako priorytetową w stosunku do unload, co sprawia, że jest ona jeszcze mniej niezawodna. Safari na komputerze też tak działa.

Zespół Chrome uważa, że użycie modelu mobilnego, w którym pamięć podręczna bfcache ma wyższy priorytet niż unload na komputerach, byłoby szkodliwe, ponieważ sprawiłoby, że ta funkcja stałaby się mniej niezawodna, mimo że wcześniej działała w Chrome (i Firefoxie) dość dobrze. Chrome chce całkowicie usunąć zdarzenie unload. Do tego czasu będzie ona nadal działać na komputerach użytkowników, którzy wyłączyli jej wycofywanie.

Dlaczego wycofujemy wydarzenie unload?

Wycofanie unload to kluczowy krok w uznaniu, że internet, w którym żyjemy, jest zupełnie inny niż kiedyś. Zdarzenie unload daje fałszywe poczucie kontroli nad cyklem życia aplikacji, co jest coraz mniej zgodne z tym, jak przeglądamy internet w nowoczesnym świecie komputerów.

Mobilne systemy operacyjne często zawieszają lub zwalniają strony internetowe, aby oszczędzać pamięć. Z tych samych powodów coraz częściej robią to też przeglądarki na komputery. Nawet bez interwencji systemu operacyjnego użytkownicy często przełączają karty i zamykają stare karty bez formalnego „opuszczania stron”.

Usunięcie zdarzenia unload jako przestarzałego jest wyrazem przekonania, że jako deweloperzy stron internetowych musimy zadbać o to, aby nasz paradygmat odpowiadał rzeczywistości, a nie opierał się na przestarzałych koncepcjach, które nie są już prawdziwe – jeśli kiedykolwiek były.

Alternatywy dla wydarzeń unload

Zamiast unload zalecamy używanie:

• visibilitychange: aby określić, kiedy zmienia się widoczność strony. To zdarzenie występuje, gdy użytkownik przełącza karty, minimalizuje okno przeglądarki lub otwiera nową stronę. Rozważ hiddenstan jako ostatni wiarygodny moment na zapisanie danych aplikacji i użytkownika.
• pagehide: aby określić, kiedy użytkownik opuścił stronę. To zdarzenie występuje, gdy użytkownik opuści stronę, ponownie ją załaduje lub zamknie okno przeglądarki. Zdarzenie pagehide nie jest wywoływane, gdy strona jest zminimalizowana lub przełączona na inną kartę. Pamiętaj, że zdarzenie pagehide nie powoduje, że strona nie kwalifikuje się do zapisania w pamięci podręcznej stanu strony internetowej, więc po jego wywołaniu strona może zostać przywrócona. Jeśli w tym zdarzeniu usuwasz jakieś zasoby, mogą one zostać przywrócone podczas przywracania strony.

Zdarzenie beforeunload ma nieco inny przypadek użycia niż unload, ponieważ można je anulować. Jest często używana do ostrzegania użytkowników o niezapisanych zmianach podczas przechodzenia do innej strony. To zdarzenie jest też niewiarygodne, ponieważ nie zostanie uruchomione, jeśli karta w tle zostanie zamknięta. Zalecamy ograniczenie użycia parametru beforeunload i dodawanie go tylko warunkowo. Zamiast tego używaj wspomnianych wcześniej zdarzeń w większości przypadków zastępowania unload.

Więcej informacji znajdziesz w tym artykule z poradami dotyczącymi nieużywania nigdy uchwytu unload.

Wykrywanie użycia unload

Istnieją różne narzędzia, które pomogą Ci znaleźć wystąpienia zdarzenia unload na stronach. Dzięki temu witryny mogą sprawdzić, czy używają tego zdarzenia – we własnym kodzie lub w bibliotekach – i czy może na nie wpłynąć nadchodzące wycofanie.

Narzędzia deweloperskie w Chrome

Narzędzia deweloperskie w Chrome zawierają back-forward-cachekontrolę, która pomaga wykrywać problemy, które mogą uniemożliwiać korzystanie z pamięci podręcznej stanu strony internetowej, w tym użycie modułu obsługi unload.

Aby przetestować pamięć podręczną stanu strony internetowej, wykonaj te czynności:

1. Na stronie otwórz Narzędzia deweloperskie, a następnie kliknij Aplikacja > Usługi w tle > Pamięć podręczna wstecz/dalej.

2. Kliknij Testuj pamięć podręczną stanu strony internetowej. Chrome automatycznie przekieruje Cię na stronę chrome://terms/ i z powrotem na Twoją stronę. Możesz też kliknąć przyciski Wstecz i Dalej w przeglądarce.

Jeśli Twoja strona nie kwalifikuje się do korzystania z pamięci podręcznej stanu strony internetowej, na karcie Pamięć podręczna stanu strony internetowej zobaczysz listę problemów. W sekcji Działania możesz sprawdzić, czy używasz unload:

Interfejs API do raportowania

Interfejs API do raportowania może być używany w połączeniu z zasadami uprawnień tylko do odczytu, aby wykrywać użycie unload przez użytkowników Twojej witryny.

Więcej informacji znajdziesz w artykule Korzystanie z interfejsu Reporting API do znajdowania wyładowań.

Interfejs API notRestoredReasons bfcache

Właściwość notRestoredReasons dodana do klasy PerformanceNavigationTiming przekazuje informacje o tym, czy dokumenty zostały zablokowane przed użyciem bfcache podczas nawigacji, oraz o przyczynach tego zablokowania. Oto przykład, jak wygląda obiekt odpowiedzi ostrzegający o istniejącym odbiorniku unload:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

Kontrolowanie dostępu do unload

Chrome będzie stopniowo wycofywać zdarzenie unload. W międzyczasie możesz używać innych narzędzi do kontrolowania tego działania i przygotowania się na wycofanie tej funkcji. Pamiętaj, że nie należy polegać na tych technikach w dłuższej perspektywie. Jak najszybciej zaplanuj przejście na alternatywne rozwiązania.

Poniższe opcje umożliwiają włączenie lub wyłączenie unload, aby sprawdzić, jak witryna będzie działać bez nich, i przygotować się na ich wycofanie. Istnieją różne rodzaje zasad:

• Zasady dotyczące uprawnień: to interfejs API platformy, który umożliwia właścicielom witryn kontrolowanie dostępu do funkcji na poziomie witryny lub poszczególnych stron za pomocą nagłówków HTTP.
• Zasady dla przedsiębiorstw: narzędzia dla administratorów IT do konfigurowania Chrome w organizacji lub firmie. Można je skonfigurować za pomocą panelu administratora, np. konsoli administracyjnej Google.
• Flagi Chrome: umożliwiają deweloperowi zmianę ustawienia unload wycofania, aby sprawdzić wpływ na różne witryny.

Zasady dotyczące uprawnień

Od Chrome 115 dodano zasadę uprawnień, która umożliwia witrynom rezygnację z używania modułów obsługi unload i natychmiastowe korzystanie z pamięci podręcznej typu „wstecz/do przodu”, co zwiększa wydajność witryny. Zobacz te przykłady, aby dowiedzieć się, jak skonfigurować to ustawienie w swojej witrynie. Dzięki temu witryny mogą wyprzedzić wycofanie unload.

W Chrome 117 zostanie to rozszerzone, aby umożliwić witrynom działanie odwrotne i zdecydować się na dalsze próby wywoływania modułów obsługi unload, ponieważ w przyszłości Chrome zmieni domyślne ustawienie tych modułów na niewywoływane. Zobacz te przykłady, aby dowiedzieć się, jak nadal zezwalać na uruchamianie procedur obsługi zwalniania w swojej witrynie. Ta opcja nie będzie dostępna na zawsze i powinna być używana, aby dać witrynom czas na migrację z unload.

Zasady firmowe

Przedsiębiorstwa, które mają oprogramowanie zależne od zdarzenia unload, mogą użyć ForcePermissionPolicyUnloadDefaultEnabled zasad, aby zapobiec stopniowemu wycofywaniu tych modułów na urządzeniach, nad którymi mają kontrolę. Jeśli włączysz tę zasadę, unload będzie nadal domyślnie włączona w przypadku wszystkich źródeł. Strona może jednak ustawić bardziej rygorystyczne zasady. Podobnie jak w przypadku rezygnacji z zasad dotyczących uprawnień jest to narzędzie do ograniczania potencjalnych zmian powodujących problemy, ale nie należy go używać w nieskończoność.

Flagi Chrome i przełączniki wiersza poleceń

Oprócz zasad dla przedsiębiorstw możesz wyłączyć wycofywanie dla poszczególnych użytkowników za pomocą flag Chrome i przełączników wiersza poleceń:

Ustawienie chrome://flags/#deprecate-unload na enabled spowoduje wycofanie domyślnego ustawienia i uniemożliwi uruchamianie procedur obsługi unload. Można je nadal zastępować na poszczególnych stronach za pomocą zasady uprawnień, ale domyślnie będą nadal wywoływane.

Tymi ustawieniami można też sterować za pomocą przełączników wiersza poleceń.

Porównanie opcji

W tabeli poniżej znajdziesz podsumowanie różnych zastosowań omówionych wcześniej opcji:

Podsumowanie

Moduły obsługi unload są wycofywane. Od dłuższego czasu są one zawodne i nie ma gwarancji, że zostaną wywołane we wszystkich przypadkach, w których dokument zostanie zniszczony. Dodatkowo elementy obsługi unload są niezgodne z bfcache.

Witryny korzystające z unload powinny przygotować się na to wycofanie, sprawdzając, czy istnieją w nich unload, usuwając je lub migrując albo, w ostateczności, opóźniając wycofanie, jeśli potrzebują więcej czasu.

Podziękowania

Dziękujemy Kenjiemu Baheux, Fergalowi Daly, Adrianie Jarze i Jeremy’emu Wagnerowi za pomoc w sprawdzeniu tego artykułu.

Baner powitalny autorstwa Anji Bauermann na Unsplash