Wycofuję zdarzenie unload

Demián Renzulli

Barry Pollard

Opublikowano: 10 sierpnia 2023 r., ostatnia aktualizacja: 29 czerwca 2026 r.

Zdarzenie unload będzie stopniowo wycofywane przez stopniowe zmienianie ustawień domyślnych, tak aby unload moduły obsługi przestały się uruchamiać na stronach, chyba że strona wyraźnie wyrazi zgodę na ich ponowne włączenie.

Harmonogram wycofywania

Zauważyliśmy, że działanie funkcji wyładowania prawdopodobnie ulegnie zmianie już w styczniu 2019 r., kiedy ogłosiliśmy nasz zamiar wdrożenia pamięci podręcznej stanu strony internetowej. Równolegle z pracami wdrożeniowymi przeprowadziliśmy szeroko zakrojone działania informacyjne, które spowodowały znaczny spadek użycia funkcji wyładowania. Aby uzupełnić te działania, zaczęliśmy też oferować sposoby testowania wpływu wycofania funkcji wyładowania w Chrome 115:

• Testowanie w rzeczywistych warunkach za pomocą interfejsu Permission-Policy API dla funkcji wyładowania w Chrome 115 (lipiec 2023 r.)
• Testowanie lokalne przez włączenie flagi w Chrome 117 (wrzesień 2023 r.)

W 2024 r. rozwiązaliśmy kilka problemów, które uniemożliwiały rozpoczęcie wdrażania, a w 2025 r. wdrożyliśmy wycofanie w 50 najpopularniejszych witrynach:

W 2026 r. rozpoczęliśmy wdrażanie tej funkcji we wszystkich miejscach początkowych w ramach 8 kamieni milowych (czyli ok. 32 tygodni), jak pokazano w tabeli poniżej.

Pełne wdrożenie jest oparte na wczytaniach stron (z zachowaniem spójności w czasie), a nie na poszczególnych użytkownikach ani witrynach, aby uniknąć większego wpływu na użytkowników lub witryny niż na inne, jak opisano w zamiarze wycofania.

Pamiętaj, że oferujemy też menu opcji rezygnacji, jeśli ten harmonogram wycofywania nie zapewnia wystarczająco dużo czasu na migrację z funkcji wyładowania.

Tło

Funkcja unload została zaprojektowana tak, aby uruchamiać się, gdy dokument jest wyładowywany. Teoretycznie można jej używać do uruchamiania kodu za każdym razem, gdy użytkownik opuszcza stronę, lub jako wywołania zwrotnego na koniec sesji.

Scenariusze, w których to zdarzenie było najczęściej używane:

• Zapisywanie danych użytkowników: zapisywanie danych 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żytkowników na koniec sesji.

Zdarzenie unload jest jednak bardzo zawodne .

W Chrome i Firefoksie na komputerach unload jest dość niezawodne, ale ma negatywny wpływ na wydajność witryny, ponieważ uniemożliwia korzystanie z pamięci podręcznej stanu strony internetowej.

W przeglądarkach mobilnych unload często nie działa, ponieważ karty są często przenoszone w tle, a następnie zamykane. Z tego powodu przeglądarki wolą priorytetowo traktować pamięć podręczną stanu strony internetowej na urządzeniach mobilnych niż unload, co sprawia, że są one jeszcze bardziej zawodne. Safari też używa tego zachowania na komputerach.

Zespół Chrome uważa, że używanie modelu mobilnego, w którym pamięć podręczna stanu strony internetowej ma priorytet nad unload na komputerach byłoby uciążliwe, ponieważ sprawiłoby, że funkcja ta byłaby tam również bardziej zawodna, podczas gdy wcześniej była dość niezawodna w Chrome (i Firefoksie). Zamiast tego Chrome chce całkowicie usunąć zdarzenie unload. Do tego czasu będzie ono nadal niezawodne na komputerach w Chrome dla osób, które wyraźnie zrezygnowały z wycofywania.

Dlaczego wycofujemy zdarzenie unload?

Wycofanie unload to kluczowy krok w znacznie większym uznaniu sieci, w której obecnie żyjemy. Zdarzenie unload daje fałszywe poczucie kontroli nad cyklem życia aplikacji, co jest coraz mniej prawdziwe w przypadku przeglądania internetu w nowoczesnym świecie komputerowym.

Mobilne systemy operacyjne często zamrażają lub wyładowują strony internetowe, aby oszczędzać pamięć, a przeglądarki na komputery robią to coraz częściej z tych samych powodów. Nawet bez interwencji systemu operacyjnego sami użytkownicy często przełączają się między kartami i zamykają stare karty bez formalnego „opuszczania stron”.

Usunięcie zdarzenia unload jako przestarzałego jest uznaniem, ż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 już nie są prawdziwe – jeśli kiedykolwiek były.

Alternatywy dla zdarzeń 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ę. Stan hidden state uznaj za ostatni niezawodny moment na zapisanie danych aplikacji i danych użytkownika.
• pagehide: aby określić, kiedy użytkownik opuścił stronę. To zdarzenie występuje, gdy użytkownik opuści stronę, ponownie ją wczyta lub zamknie okno przeglądarki. Zdarzenie pagehide nie jest wywoływane, gdy strona jest zminimalizowana lub przełączona na inną kartę. Pamiętaj, że ponieważ pagehide nie powoduje, że strona nie kwalifikuje się do pamięci podręcznej stanu strony internetowej, po wywołaniu tego zdarzenia można przywrócić stronę. Jeśli w tym zdarzeniu czyścisz jakieś zasoby, mogą one zostać przywrócone po przywróceniu strony.

Zdarzenie beforeunload ma nieco inny przypadek użycia niż unload, ponieważ jest to zdarzenie, które można anulować. Jest ono często używane do ostrzegania użytkowników o niezapisanych zmianach podczas opuszczania strony. To zdarzenie jest też zawodne, ponieważ nie zostanie wywołane, jeśli karta w tle zostanie zamknięta. Zalecamy ograniczenie użycia beforeunload i dodawanie go tylko warunkowo. Zamiast tego w większości przypadków zastąpienia unload używaj wspomnianych wcześniej zdarzeń.

Więcej informacji znajdziesz w tej poradzie dotyczącej nieużywania modułu obsługi unload.

Wykrywanie użycia unload

Istnieją różne narzędzia, które pomagają 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 mogą mieć wpływ na nadchodzące wycofanie.

Narzędzia deweloperskie w Chrome

Narzędzia deweloperskie w Chrome zawierają back-forward-cache audyt, który pomaga identyfikować problemy, które mogą uniemożliwiać kwalifikowanie się strony do 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 działające w tle > Pamięć podręczna stanu strony internetowej.

2. Kliknij Testuj pamięć podręczną stanu strony internetowej Chrome automatycznie przeniesie 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 buforowania 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 Reporting API można używać w połączeniu z zasadami dotyczącymi 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 pamięci podręcznej stanu strony internetowej

Właściwość notRestoredReasons dodana do klasy PerformanceNavigationTiming zawiera informacje o tym, czy dokumenty zostały zablokowane przed użyciem pamięci podręcznej stanu strony internetowej bfcache podczas nawigacji, i dlaczego. Oto przykład ostrzeżenia w obiekcie odpowiedzi 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 stopniowo wycofuje zdarzenie unload. W międzyczasie możesz używać różnych narzędzi do kontrolowania tego zachowania i przygotowania się na nadchodzące wycofanie. Pamiętaj, że nie powinnaś polegać na tych technikach w dłuższej perspektywie i jak najszybciej zaplanować migrację do alternatywnych rozwiązań.

Poniższe opcje umożliwiają włączanie i wyłączanie modułów obsługi unload, aby sprawdzić, jak Twoja witryna będzie działać bez nich, dzięki czemu możesz przygotować się na nadchodzące wycofanie. Istnieją różne typy 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 firmowe: 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 wycofywania unload, aby przetestować wpływ na różne witryny.

Zasady dotyczące uprawnień

W Chrome 115 dodano zasady dotyczące uprawnień, które umożliwiają witrynom rezygnację z używania modułów obsługi unload i natychmiastowe korzystanie z pamięci podręcznej stanu strony internetowej, aby zwiększyć wydajność witryny. Zobacz te przykłady, jak skonfigurować tę opcję w swojej witrynie. Dzięki temu witryny mogą wyprzedzić wycofanie unload.

W Chrome 117 rozszerzono tę funkcję, aby umożliwić witrynom wykonanie odwrotnej czynności i wyrażenie zgody na dalsze próby uruchamiania modułów obsługi unload tak jak dotychczas, ponieważ Chrome zmienia domyślne ustawienie, aby w przyszłości nie uruchamiać tych modułów. Zobacz te przykłady, jak nadal zezwalać na uruchamianie modułów obsługi wyładowania w swojej witrynie. Zachęcamy właścicieli witryn do zaprzestania używania modułów obsługi unload ze względu na ich zawodność, ale planujemy obsługiwać tę rezygnację w najbliższej przyszłości w przypadku witryn, które muszą z niej korzystać. Pamiętaj, że ponowne wyrażenie zgody nie zwiększa niezawodności modułów obsługi unload na urządzeniach mobilnych – przywraca tylko obecny stan.

Zasady firmowe

Firmy, które mają oprogramowanie zależne od zdarzenia unload, mogą używać zasady ForcePermissionPolicyUnloadDefaultEnabled, aby zapobiec stopniowemu wycofywaniu na urządzeniach pod ich kontrolą. Włączenie tej zasady spowoduje, że unload będzie domyślnie włączone we wszystkich miejscach początkowych. Strona może nadal ustawić bardziej rygorystyczne zasady, jeśli chce. Podobnie jak rezygnacja z zasad dotyczących uprawnień, jest to narzędzie do łagodzenia potencjalnych zmian powodujących niezgodność. Ponownie zachęcamy właścicieli witryn do zaprzestania polegania na modułach obsługi unload, ale Chrome planuje obsługiwać tę rezygnację w najbliższej przyszłości w przypadku witryn, które muszą z niej korzystać.

Flagi Chrome i przełączniki wiersza poleceń

Oprócz zasad firmowych 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 przyspieszenie domyślnego wycofywania i uniemożliwi uruchamianie modułów obsługi unload. Można je nadal zastępować w poszczególnych witrynach za pomocą zasad dotyczących uprawnień, ale domyślnie będą się nadal uruchamiać.

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 dawna są zawodne i nie gwarantują uruchomienia we wszystkich przypadkach, w których dokument jest niszczony. Ponadto moduły obsługi unload są niezgodne z bfcache.

Witryny, które korzystają z modułów obsługi unload, powinny przygotować się na nadchodzące wycofanie, testując istniejące moduły obsługi 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 pomocne opinie.

Baner powitalny autorstwa Anji Bauermann w Unsplash