Wycofuję zdarzenie unload

Zdarzenie unload będzie stopniowo wycofywane przez stopniową zmianę wartości domyślnej, tak aby moduły obsługi unload przestały się uruchamiać na stronach, chyba że na danej stronie wyrażono zgodę 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ć tę kampanię, zaczęliśmy też testować efekty wycofania plików z Chrome 115:

  • Testowanie w warunkach rzeczywistych za pomocą interfejsu Permission-Policy API do wylogowywania w Chrome 115 (lipiec 2023 r.)
  • Testowanie lokalne polegające na włączeniu flagi w Chrome 117 (wrzesień 2023 r.)

Oto, jak planujemy wycofać funkcję częściowego wycofania po tych etapach kontaktu i okresu próbnego:

  • Faza ograniczona, w której funkcja unload będzie stopniowo przestawać działać w przypadku 50 najpopularniejszych witryn (dane na dzień pisania tego artykułu).
    • Najpierw 1% użytkowników Chrome 120 (koniec listopada 2023 r.).
    • 100% użytkowników do końca III kwartału 2024 r.
  • Ponadto w 3 kwartale 2024 r. zamierzamy rozpocząć ogólną fazę, w której funkcja unload będzie stopniowo przestawać działać w żadnych witrynach, zaczynając od 1% użytkowników, a zakończając na 100% użytkowników do końca 1 kwartału 2025 r.

Pamiętaj, że udostępniamy też menu z opcjami rezygnacji na wypadek, gdy ten harmonogram stopniowego wycofywania nie zapewnia wystarczającej ilości czasu na migrację. 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.

Harmonogram wycofywania wyładowywania.

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, zanim opuścisz stronę.
  • 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 bardzo niewiarygodne.

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

W przeglądarkach mobilnych unload często nie działa, ponieważ karty często działają w tle, a potem zamykają się. 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 przypadku urządzeń mobilnych, w którym priorytetem jest bufor bfcache nad unload, było by uciążliwe, ponieważ spowodowałoby to spadek niezawodności, podczas gdy wcześniej w Chrome (i w Firefoksie) było to dość niezawodne. 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 usługi unload to kluczowy krok w kierunku szerszego uznania 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, nie „opuszczając stron”.

Usunięcie zdarzenia unload jako przestarzałego to uznanie, że my, jako deweloperzy stron internetowych, musimy zadbać o to, aby nasza paradygmatyka odpowiadała realnemu światu i nie była zależna od przestarzałych koncepcji, które nie są już aktualne (jeśli w ogóle kiedykolwiek były).

Alternatywy dla wydarzenia 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 stan hidden za 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. Zdarzenie pagehide nie jest wywoływane, gdy strona jest tylko zminimalizowana lub przełączona na inną kartę. Pamiętaj, że zdarzenie pagehide nie 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, może być konieczne 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 także zawodne, ponieważ nie uruchomi się po wyłączeniu karty w tle. Zalecamy ograniczenie używania pola beforeunload i dodanie go tylko warunkowo. Zamiast tego użyj powyższych zdarzeń w przypadku większości zastępowań unload.

Więcej informacji znajdziesz w tej poradzie dotyczącej nigdy nieużywania elementu unload.

Wykrywanie użycia unload

Dostępne są różne narzędzia, które ułatwiają znajdowanie na stronach zdarzeń unload. Dzięki temu witryny mogą sprawdzić, czy korzystają z tego zdarzenia – w swoim kodzie czy za pomocą bibliotek – i to może mieć wpływ na to, czy zbliża się wycofanie tego zdarzenia.

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 obsługi unload.

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

  1. Na stronie otwórz DevTools, a potem przejdź do Aplikacja > Usługi w tle > Pamięć podręczna wstecz/wprzód.

  2. 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 pojawi się lista problemów. W sekcji Działania możesz sprawdzić, czy używasz unload:

Narzędzia deweloperskie w Chrome – narzędzie do testowania pamięci podręcznej wstecz/dalej, które pokazuje, że użyto uchwytu dla zdarzenia 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 dokumentom zablokowano korzystanie z bfcache do nawigacji i dlaczego. Instrukcje dotyczące korzystania z tej funkcji znajdziesz tutaj. Oto przykład ostrzeżenia w obiekcie odpowiedzi dotyczącego istniejącego słuchacza unload:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-handler"}
   ],
   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 na dłuższą metę. Zamiast tego należy jak najszybciej zaplanować migrację na alternatywne rozwiązania.

Podane niżej opcje umożliwiają włączanie i wyłączanie modułów obsługi unload w celu przetestowania, jak witryna działa bez nich. Dzięki temu 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 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żesz je skonfigurować w panelu administracyjnym, takim jak konsola administracyjna Google.
  • Flagi Chrome: umożliwiają deweloperowi zmianę ustawienia wycofywania unload w 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ą przygotować się na wycofanie unload.

Zostanie on rozszerzony w Chrome 117, aby umożliwić witrynom odwrotne działanie i wyrazić zgodę na dalsze uruchamianie modułów obsługi unload, ponieważ Chrome zmienia ustawienie domyślne, tak aby w przyszłości nie były uruchamiane. Przykłady pozwalające na dalsze uruchamianie w witrynie obsługiwanych przez nią metod unload Ta zgoda nie będzie obowiązywać na zawsze i powinna dać witrynom czas na migrację z modułów obsługi unload.

Zasady Enterprise

Firmy, których oprogramowanie wymaga do prawidłowego działania zdarzenia unload, mogą używać zasady ForcePermissionPolicyUnloadDefaultEnabled, aby zapobiec stopniowemu wycofywaniu urządzeń kontrolowanych przez nie. Po włączeniu tej zasady unload będzie nadal domyślnie włączone dla wszystkich źródeł. Jeśli chce, może ustawić surowsze zasady. Podobnie jak wyłączenie zasad dotyczących uprawnień jest to narzędzie do minimalizowania potencjalnych zmian, które mogą spowodować przerwanie działania aplikacji. Nie należy jednak używać tej opcji przez nieograniczony czas.

Flagi Chrome i przełączniki wiersza poleceń

Oprócz zasad korporacyjnych możesz wyłączyć wycofanie dla poszczególnych użytkowników za pomocą 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ć w przypadku 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 funkcji 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
Przełączniki 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 pamięcią podręczną stanu strony internetowej.

Witryny, które obecnie korzystają z obsług unload, powinny przygotować się na ich wycofanie. Należy przetestować, czy istnieją jakieś obsługi unload, usunąć je lub przenieść. W ostatecznej desperacji można opóźnić wycofanie, jeśli potrzebujesz więcej czasu.

Podziękowania

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

Baner powitalny: Anja Bauermann i film Unsplash