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ć 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.)
Po zakończeniu tych faz dotarcia do użytkowników i testowania przedstawiamy oczekiwany sposób łagodnego wycofania:
- 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 oferujemy też menu opcji rezygnacji, jeśli ten harmonogram wycofywania nie zapewnia wystarczająco dużo czasu na migrację z unload. 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 statystyk: wysyłanie danych związanych z interakcjami użytkowników na koniec sesji.
Jednak zdarzenie unload jest bardzo 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 przenoszone do tła, a następnie zabijane. 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 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, 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 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 po prostu zminimalizowana lub przełączana 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, 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 też niepewne, ponieważ nie zostanie uruchomione, jeśli karta w tle zostanie zamknięta. Zalecamy ograniczenie używania pola beforeunload i dodanie go tylko warunkowo. W przypadku większości zamienników unload używaj tych zdarzeń.
Więcej informacji znajdziesz w tych poradach na temat rezygnacji z korzystania z modułu 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 używają tego zdarzenia (w swoim kodzie lub w bibliotekach) i czy mogą zostać dotknięte przez jego 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 obsługi 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 Przetestuj pamięć podręczną stanu strony internetowej. Chrome automatycznie przeniesie Cię do strony
chrome://terms/i powrót na swoją stronę. Możesz również 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:
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 Znajdowanie wyładowań za pomocą interfejsu API do raportowania.
Interfejs API Bfcache notRestoredReasons
Właściwość notRestoredReasons, dodana do klasy PerformanceNavigationTiming, zawiera informacje o tym, czy dokumenty zostały zablokowane przed korzystaniem z pamięci podręcznej stanu strony internetowej w nawigacji, oraz o przyczynach takiej decyzji. Instrukcje, jak to zrobić, 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 będzie stopniowo wycofywać zdarzenie unload. Tymczasem możesz korzystać z różnych narzędzi, aby kontrolować to działanie i przygotować się na nadchodzące wycofanie. Pamiętaj, że nie należy stosować tych technik w dłuższej perspektywie i zaplanuj jak najszybsze przejście 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ć w panelu administracyjnym, np. w 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ą 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 opcja nie będzie dostępna na zawsze. Należy z niej korzystać, aby dać witrynom czas na migrację z użytkowników unload.
Zasady Enterprise
Przedsiębiorstwa, których oprogramowanie wymaga unload, aby działać prawidłowo, mogą użyć zasady ForcePermissionPolicyUnloadDefaultEnabled, aby zapobiec stopniowemu wycofywaniu się tej zasady 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 ustawić surowsze zasady. Podobnie jak w przypadku rezygnacji z zasad dotyczących uprawnień, jest to narzędzie służące do łagodzenia potencjalnych zmian powodujących niezgodność, ale nie należy go używać na stałe.
Flagi i przełączniki wiersza poleceń w Chrome
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
W poniższej tabeli podano podsumowanie różnych zastosowań omówionych wcześniej 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 autorstwa Anja Bauermann na Unsplash