Data publikacji: 10 sierpnia 2023 r., ostatnia aktualizacja: 11 marca 2025 r.
Zdarzenie unload zostanie stopniowo wycofane przez stopniowe zmienianie domyślnych ustawień, tak aby moduły obsługi zdarzeń unload przestały działać na stronach, chyba że strona wyraźnie zdecyduje się na ich ponowne włączenie.
Harmonogram wycofywania
Wspomnieliśmy, że zachowanie podczas wylogowywania prawdopodobnie ulegnie zmianie już w styczniu 2019 r., gdy ogłosiliśmy nasze plany wdrożenia pamięci podręcznej stanu strony internetowej. Równolegle z wdrożeniem przeprowadziliśmy dużą kampanię, która doprowadziła do znacznego spadku wykorzystywania funkcji Unload. Aby uzupełnić te informacje, zaczęliśmy też oferować sposoby testowania efektów wycofania funkcji unload z Chrome 115:
- Testowanie w warunkach rzeczywistych interfejsu Permission-Policy API na potrzeby funkcji unload w Chrome 115 (lipiec 2023 r.)
- Testowanie lokalne polegające na włączeniu flagi w Chrome 117 (wrzesień 2023 r.)
W 2024 r. rozwiązaliśmy kilka problemów, które blokowały rozpoczęcie wdrażania.
Oto harmonogram wycofywania zdarzenia unload:
| Milestone | Data kamienia milowego | 50 najpopularniejszych witryn | % innych źródeł |
|---|---|---|---|
| 135 | 26 marca 2025 r. | 1 (www.google.com) |
0 |
| 136 | 23 kwietnia 2025 r. | 5 | 0 |
| 137 | 21 maja 2025 r. | 25 | 0 |
| 138 | 18 czerwca 2025 r. | 50 | 0 |
Po wdrożeniu zmian w 50 najpopularniejszych witrynach wstrzymamy je na czas trwania co najmniej 1 lub 2 okresów pomiarowych, a potem uzyskamy dalsze zatwierdzenia, aby wdrożyć je we wszystkich źródłach w ciągu kolejnych 8 okresów pomiarowych (czyli w ciągu około 32 tygodni). Wstępnie wyglądałoby to tak:
| Milestone | Data kamienia milowego | 50 najpopularniejszych witryn | % innych źródeł |
|---|---|---|---|
| 140 | 27 sierpnia 2025 r. | 50 | 1 |
| 141 | 24 września 2025 r. | 50 | 5 |
| 142 | 22 października 2025 r. | 50 | 10 |
| 143 | 19 listopada 2025 r. | 50 | 20 |
| 144 | 17 stycznia 2026 r. | 50 | 40 |
| 145 | 4 lutego 2026 r. | 50 | 60 |
| 146 | 4 marca 2026 r. | 50 | 80 |
| 147 | 1 kwietnia 2026 r. | 50 | 100 |
Pamiętaj, że oferujemy też menu opcji rezygnacji, jeśli ten harmonogram wycofywania nie zapewnia wystarczająco dużo czasu na przejście na inne rozwiązanie. Chcemy wykorzystać tę miękką wycofanie, aby poinformować Cię o harmonogramie ostatniej fazy (twardego wycofania funkcji unload), w której te wyłączenia zostaną usunięte lub ograniczone.
Tło
Funkcja unload została zaprojektowana tak, aby była wywoływana podczas wylogowywania dokumentu. Teoretycznie można go użyć do uruchomienia kodu za każdym razem, gdy użytkownik opuszcza stronę, lub jako wywołania zwrotnego na koniec sesji.
Oto przykłady scenariuszy, w których to zdarzenie było najczęściej używane:
- Zapisywanie danych użytkowników: zapisz dane przed opuszczeniem strony.
- Wykonywanie zadań porządkujących: zamykanie otwartych zasobów przed opuszczeniem strony.
- Wysyłanie danych analitycznych: wysyłanie danych związanych z interakcjami użytkownika na końcu sesji.
Jednak zdarzenie unload jest wyjątkowo niewiarygodne.
W Chrome i Firefoksie na komputery unload jest dość niezawodna, ale ma negatywny wpływ na wydajność witryny, ponieważ uniemożliwia korzystanie z bfcache (pamięci podręcznej stanu strony internetowej).
W przeglądarkach mobilnych funkcja unload często nie działa, ponieważ karty są często zamykane i uruchamiane w tle. Z tego powodu przeglądarki stawiają na urządzeniach mobilnych na pierwszym miejscu bfcache, a nie unload, co jeszcze bardziej zmniejsza niezawodność tych ostatnich. Safari stosuje to zachowanie również na komputerach.
Zespół Chrome uważa, że stosowanie na komputerach modelu używanego w urządzeniach mobilnych, w którym priorytetem jest bufor bfcache nad unload, byłoby uciążliwe, ponieważ spowodowałoby to zmniejszenie niezawodności, która w Chrome (i w Firefox) jest obecnie na przyzwoitym poziomie. Zamiast tego Chrome ma na celu całkowite usunięcie zdarzenia unload. Do tego czasu będzie ona nadal dostępna na komputerach dla osób, które wyraźnie zrezygnowały z obsługi tej funkcji.
Dlaczego wycofujemy zdarzenie unload?
Wycofanie unload to kluczowy krok w kierunku znacznie większego rozpoznawania internetu, w którym obecnie żyjemy. Zdarzenie unload daje fałszywe poczucie kontroli nad cyklem życia aplikacji, które coraz bardziej odbiega od tego, jak przeglądamy internet w nowoczesnym świecie komputerów.
Systemy operacyjne urządzeń mobilnych często zawieszają lub wyrzucają strony internetowe, aby oszczędzać pamięć. Z tych samych powodów coraz częściej robią to też przeglądarki komputerowe. Nawet bez interwencji systemu operacyjnego 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 wyrazem uznania dla faktu, że my, jako deweloperzy stron internetowych, musimy zadbać o to, aby nasza paradygmatyka była zgodna z rzeczywistością i nie zależała od przestarzałych koncepcji, które nie są już aktualne (jeśli w ogóle kiedykolwiek były).
Alternatywy dla zdarzeń unload
Zamiast unload zalecamy użycie:
visibilitychange: określa, kiedy zmienia się widoczność strony. To zdarzenie występuje, gdy użytkownik przełączy karty, zminimalizuje okno przeglądarki lub otworzy nową stronę. Uważaj stanhiddenza ostatni możliwy moment zapisania danych aplikacji i użytkowników.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 zamyka okno przeglądarki. Zdarzeniepagehidenie jest wywoływane, gdy strona jest zminimalizowana lub gdy użytkownik przełączy się na inną kartę. Pamiętaj, że zdarzeniepagehidenie powoduje, że strona nie kwalifikuje się do umieszczenia w pamięci podręcznej stanu strony internetowej, więc może zostać przywrócona po wywołaniu tego zdarzenia. Jeśli w tym przypadku usuwasz jakieś zasoby, konieczne może być ich przywrócenie podczas przywracania strony.
Zdarzenie beforeunload ma nieco inne zastosowanie niż zdarzenie unload, ponieważ można je anulować. Jest on często używany do ostrzegania użytkowników o niezapisanych zmianach podczas przełączania się między kartami. To zdarzenie jest też niepewne, ponieważ nie zostanie uruchomione, jeśli karta w tle zostanie zamknięta. Zalecamy ograniczenie stosowania tagu beforeunload i dodawanie go tylko warunkowo. Zamiast tego w przypadku większości zastępowań unload używaj wymienionych wcześniej zdarzeń.
Więcej informacji znajdziesz w tej poradzie dotyczącej nigdy nieużywania elementu unload.
Wykrywanie korzystania z unload
Istnieją różne narzędzia, które ułatwiają znajdowanie na stronach zdarzeń unload. Dzięki temu witryny mogą sprawdzić, czy używają tego zdarzenia (w swoim kodzie lub w bibliotekach) i czy mogą zostać dotknięte przez nadchodzące wycofanie.
Narzędzia deweloperskie w Chrome
Narzędzia deweloperskie w Chrome zawierają back-forward-cache kontrolę, która pomaga zidentyfikować problemy, które mogą uniemożliwić stronie kwalifikowanie się do korzystania z pamięci podręcznej stanu strony internetowej, w tym użycie modułu unload.
Aby przetestować pamięć podręczną stanu strony internetowej, wykonaj te czynności:
Na stronie otwórz DevTools, a potem przejdź do Aplikacja > Usługi w tle > Pamięć podręczna wstecz/wprzód.
Kliknij Testuj pamięć podręczną stanu strony internetowej wstecz/dalej. 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 korzystania z pamięci podręcznej stanu strony internetowej, na karcie Pamięć podręczna stanu strony internetowej znajdziesz listę problemów. W sekcji Możliwe działania możesz sprawdzić, czy używasz unload:
Interfejs API do raportowania
Interfejsu Reporting API można używać w połączeniu z zasadami dotyczącymi uprawnień tylko do odczytu, aby wykrywać użycie funkcji unload przez użytkowników witryny.
Więcej informacji znajdziesz w artykule Wyszukiwanie zwolnień za pomocą interfejsu Reporting API.
Interfejs API Bfcache notRestoredReasons
Właściwość notRestoredReasons, dodana do klasy PerformanceNavigationTiming, zawiera informacje o tym, czy dokumenty zostały zablokowane przed korzystaniem z bfcache w nawigacji, oraz o przyczynach takiej decyzji. Oto przykład ostrzeżenia w obiekcie odpowiedzi istniejącego słuchacza 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 wycofa zdarzenie unload. W międzyczasie możesz używać różnych narzędzi do kontrolowania tego zachowania i przygotowania się do nadchodzącego wycofania. Pamiętaj, że nie należy polegać na tych technikach w długoterminowej perspektywie. Zamiast tego należy jak najszybciej zaplanować migrację na alternatywne rozwiązania.
Opcje te umożliwiają włączenie lub wyłączenie obsługi unload, aby przetestować, jak Twoja witryna będzie działać bez tych elementów. Dzięki temu możesz się przygotować do ich wycofania. 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 pojedynczej strony za pomocą nagłówków HTTP.
- Zasady dla firm: narzędzia dla administratorów IT do konfigurowania Chrome w organizacji lub firmie. Można je konfigurować za pomocą panelu administratora, np. konsoli administracyjnej Google.
- Flagi Chrome: umożliwiają deweloperowi zmianę ustawienia wycofywania
unloadw celu przetestowania wpływu na różne witryny.
Zasady dotyczące uprawnień
W Chrome 115 dodano zasady dotyczące uprawnień, aby umożliwić witrynom rezygnację z użycia modułów obsługi unload i natychmiastowe korzystanie z pamięci podręcznej bfcache w celu poprawy wydajności witryny. Zapoznaj się z tymi przykładami konfiguracji w witrynie. Dzięki temu witryny będą mogły przygotować się na wycofanie unload.
W Chrome 117 zostanie to rozszerzone, aby umożliwić witrynom odwrócenie tej sytuacji i włączenie opcji dalszego wywoływania obsługi unload, ponieważ Chrome zmieni domyślne zachowanie na niewywoływanie tych metod w przyszłości. Przykłady pozwalające na dalsze uruchamianie w witrynie obsługiwanych przez nią metod unload Ta opcja nie będzie dostępna na zawsze i powinna być używana tylko do czasu, gdy witryny przestaną używać obsługi unload.
Zasady dotyczące organizacji
Przedsiębiorstwa, których oprogramowanie wymaga unload do prawidłowego działania, mogą użyć zasady ForcePermissionPolicyUnloadDefaultEnabled, aby zapobiec stopniowemu wycofywaniu się tej funkcji na urządzeniach znajdujących się pod ich kontrolą. Po włączeniu tej zasady unload będzie nadal domyślnie włączone dla wszystkich źródeł. Jeśli chce, może wprowadzić surowsze zasady. Podobnie jak wyłączenie zasad dotyczących uprawnień, jest to narzędzie do minimalizowania potencjalnych zmian, ale nie powinno być używane przez nieograniczony czas.
Flagi i przełączniki wiersza poleceń w Chrome
Oprócz wyłączenia w ramach zasad korporacyjnych możesz też wyłączyć wycofanie w przypadku poszczególnych użytkowników, korzystając z flag i przełączników wiersza poleceń Chrome:
Ustawienie chrome://flags/#deprecate-unload na enabled spowoduje zastosowanie domyślnego wycofania i uniemożliwi wywołanie obsługi unload. Nadal można je zastąpić na poziomie poszczególnych witryn za pomocą zasad dotyczących uprawnień, ale będą one nadal uruchamiane domyślnie.
Tymi ustawieniami można też sterować za pomocą przełączników wiersza poleceń.
Porównanie opcji
Tabela poniżej zawiera podsumowanie różnych zastosowań wcześniej omówionych opcji:
| Wycofanie | Wycofanie z wyjątkami | Zapobieganie wycofaniu, aby zapewnić czas na migrację | |
|---|---|---|---|
| Polityka uprawnień (dotyczy stron i witryn) |
Tak | Tak | Tak |
| Zasady dla firm (dotyczy urządzeń) |
Nie | Nie | Tak |
| Flagi Chrome (dotyczy poszczególnych użytkowników) |
Tak | Nie | Nie |
| Opcje wiersza poleceń Chrome (dotyczy poszczególnych użytkowników) |
Tak | Nie | Tak |
Podsumowanie
Moduły obsługi unload są wycofywane. Od dawna są niewiarygodne i nie ma gwarancji, że zostaną uruchomione w każdym przypadku zniszczenia dokumentu. Ponadto moduły obsługi unload są niezgodne z bfcache.
Witryny, które korzystają z obsług unload, powinny się przygotować na ich wycofanie. Należy sprawdzić, czy istnieją jakieś obsługi unload, usunąć je lub przenieść. W ostatecznej instancji można odłożyć wycofanie, jeśli zajdzie taka potrzeba.
Podziękowania
Dziękujemy Kenji Baheux, Fergalowi Daly’emu, Adriana Jarze i Jeremy’emu Wagnerowi za pomoc w sprawdzeniu tego artykułu.
Baner powitalny autorstwa Anja Bauermann na Unsplash