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 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 przejście na inną metodę. Naszym celem jest wykorzystanie tego wycofania z opcją, aby poinformować o harmonogramie ostatniej fazy (trwałego 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 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 urządzeniach mobilnych, w którym priorytetem jest bfcache nad unload, byłoby uciążliwe, ponieważ spowodowałoby to zmniejszenie niezawodności, która w Chrome (i Firefoksie) była do tej pory zadowalająca. 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 wyładowują 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 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ę. Uwzględnij stanhiddenjako 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 tylko zminimalizowana lub przełączona 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 stosowania tagu beforeunload i dodawanie 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 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ą sprawdzenieback-forward-cache, które 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:
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 pojawi się lista 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 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 pamięci podręcznej stanu strony internetowej w nawigacji, oraz o przyczynach takiej decyzji. 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.
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ą mogły przygotować się na wycofanie unload.
W Chrome 117 ta funkcja zostanie rozszerzona, aby umożliwić witrynom odwrócenie tej sytuacji i włączenie opcji dalszego wywoływania obsługi unload, ponieważ Chrome zmieni domyślne zachowanie i nie będzie już wywoływać tych metod. 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 dotyczące firm
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 w przypadku 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, które mogą spowodować przerwanie działania aplikacji. Nie należy jednak używać tej opcji przez nieograniczony czas.
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 wyłączenia 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ę | |
|---|---|---|---|
| Zasady dotyczące uprawnień (dotyczy stron/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 pamięcią podręczną stanu strony internetowej.
Witryny, które obecnie korzystają z obsług unload, powinny przygotować się do ich wycofania. Należy przetestować i usunąć lub przenieść istniejące obsługi unload albo, w ostatecznej desperacji, opóźnić ich wycofanie, jeśli potrzeba 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