Zdarzenie unload będzie stopniowo wycofywane przez stopniową zmianę ustawień domyślnych, tak aby moduły obsługi unload przestały się uruchamiać na stronach, chyba że strona jednoznacznie wyrazi zgodę na ich ponowne włączenie.
Harmonogram wycofywania
Zauważyliśmy, że sposób wyładowywania pamięci może jeszcze ulec zmianie już w styczniu 2019 roku, gdy ogłosiliśmy zamiar wdrożenia pamięci podręcznej stanu strony internetowej. Równolegle z pracami wdrożeniowymi przeprowadziliśmy dużą komunikację, która spowodowała znaczny spadek wykorzystania możliwości nieużywanych aplikacji. W ramach tych działań zaczęliśmy też udostępniać sposoby przetestowania wpływu wycofania ich z Chrome 115:
- W testach otwartych za pomocą interfejsu Permission-Policy API for unload w Chrome 115 (lipiec 2023 r.)
- Testy lokalne przez włączenie flagi w Chrome 117 (wrzesień 2023 r.)
Po tych fazach kontaktu i testów przewidujemy wdrożenie niewielkiego wycofania w ten sposób:
- Etap, w którym wyładowywanie z 50 najpopularniejszych witryn stopniowo przestaje działać (odniesienie w momencie pisania tekstu).
- Od 1% użytkowników korzystających z Chrome 120 (koniec listopada 2023 r.).
- Zakończenie, obejmujące 100% użytkowników do końca III kwartału 2024 r.
- Dodatkowo od III kwartału 2024 r. zamierzamy rozpocząć fazę ogólną, w ramach której w każdej witrynie będzie stopniowo wyłączona opcja wyładowywania z aplikacji – na początku będzie to 1% użytkowników, a do końca I kwartału 2025 r. będzie obejmować 100% użytkowników.
Przypominamy, że dostępne jest też menu z opcjami rezygnacji na wypadek, gdyby ten harmonogram niezapewniał wystarczającej ilości czasu na migrację od wyładowywania z urządzenia. Zamierzamy skorzystać z niewielkiego wycofywania, aby określić harmonogram ostatniej fazy (całkowite wycofanie wyładowywania), w której te rezygnacje zostaną usunięte lub ograniczone.
Wprowadzenie
unload został zaprojektowany tak, aby uruchamiał się podczas wyładowywania dokumentu. Teoretycznie może być używany do uruchamiania kodu za każdym razem, gdy użytkownik opuszcza stronę, lub jako wywołanie zwrotne w trakcie sesji.
Najczęściej używane jest to zdarzenie:
- Zapisywanie danych użytkownika: zapisz dane, zanim opuścisz stronę.
- Wykonywanie zadań związanych z czyszczeniem: zamykanie otwartych zasobów przed porzuceniem strony.
- Wysyłanie statystyk: wysyłanie danych związanych z interakcjami użytkowników na koniec sesji.
Jednak zdarzenie unload jest bardzo zawodne.
W przeglądarkach Chrome i Firefoks na komputerach usługa 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 i następnie zamykają się. Z tego powodu przeglądarki na urządzeniach mobilnych traktują priorytetowo pamięć podręczną strony (bfcache) niż unload, co sprawia, że są one jeszcze bardziej zawodne. Safari również tak działa na komputerach.
Zespół Chrome uważa, że korzystanie z mobilnego modelu określania priorytetu pamięci podręcznej (bfcache) zamiast unload na komputerze byłoby krzywdzące ze względu na zmniejszenie jego niezawodności w przeglądarkach Chrome (i Firefox). Celem Chrome jest całkowite usunięcie zdarzenia unload. Do tego czasu będzie ona niezawodna na komputerach dla użytkowników, którzy zrezygnowali z jej wycofania.
Dlaczego warto wycofać zdarzenie unload?
Wycofanie usługi unload to kluczowy krok w kierunku większej rozpoznawalności internetu, w którym obecnie żyjemy. Zdarzenie unload daje fałszywe poczucie kontroli nad cyklem życia aplikacji, które coraz bardziej nie pasuje do tego, jak przeglądamy internet we współczesnym świecie obliczeniowym.
Mobilne systemy operacyjne często blokują lub wyładowują strony internetowe, aby oszczędzać pamięć. Przeglądarki na komputerach coraz częściej robią to z tych samych powodów. Nawet bez interwencji w systemie operacyjnym użytkownicy często zmieniają karty i zamykają stare karty bez formalnego „opuszczania strony”.
Usunięcie zdarzenia unload jako przestarzałego to znak, że jako deweloperzy stron internetowych mamy obowiązek zadbać o to, aby nasz model był zgodny z modelem stosowanym w świecie rzeczywistym, i nie polegał na przestarzałych koncepcjach, które już nie są aktualne (o ile kiedykolwiek tak były).
Alternatywy dla wydarzeń unload
Zamiast unload zalecamy użycie:
visibilitychange: określa, kiedy zmienia się widoczność strony. To zdarzenie ma miejsce, gdy użytkownik przełącza karty, minimalizuje okno przeglądarki lub otwiera nową stronę. Wybierz stanhidden, czyli ostatni niezawodny czas zapisywania danych aplikacji i użytkowników.pagehide: aby sprawdzić, kiedy użytkownik opuścił stronę. Zdarzenie to ma miejsce, gdy użytkownik opuści stronę, odświeży ją lub zamknie okno przeglądarki. Zdarzeniepagehidenie jest wywoływane, gdy strona została po prostu zminimalizowana lub przełączona na inną kartę. Pamiętaj, żepagehidenie sprawia, że strona nie kwalifikuje się do korzystania z pamięci podręcznej stanu strony internetowej, więc po uruchomieniu tego zdarzenia stronę można przywrócić. Jeśli usuwasz zasoby w ramach tego zdarzenia, być może trzeba będzie je przywrócić podczas przywracania strony.
Zdarzenie beforeunload ma nieco inny przypadek użycia niż unload, ponieważ jest zdarzeniem, które można anulować. Często używa się ich, aby ostrzegać użytkowników o niezapisanych zmianach, gdy opuszczają stronę. To zdarzenie jest też nierealistyczne, ponieważ nie zostanie uruchomione w przypadku zamknięcia karty w tle. Zalecamy ograniczenie użycia atrybutu beforeunload i dodanie go tylko warunkowo. W przypadku większości zamienników w tabeli unload używaj zdarzeń opisanych powyżej.
Więcej informacji znajdziesz w tych poradach, aby nigdy nie używać modułu obsługi unload.
Wykryj użycie zasobu unload
Dostępne są różne narzędzia, które pomogą Ci sprawdzić wygląd wydarzenia unload na stronach. Dzięki temu witryny będą mogły sprawdzić, czy używają tego zdarzenia – w swoim kodzie czy w bibliotekach – i nadchodzące wycofanie tej funkcji może mieć wpływ na to zdarzenie.
Latarnia morska
Lighthouse udostępnia kontrolę no-unload-listeners, która ostrzega deweloperów, jeśli kod JavaScript na ich stronach (w tym pochodzący z bibliotek zewnętrznych) doda detektor zdarzeń unload.
Narzędzia deweloperskie w Chrome
Narzędzia deweloperskie w Chrome zawierają kontrolę back-foward-cache, która ułatwia wykrywanie problemów, które mogą uniemożliwiać stronom korzystanie z pamięci podręcznej stanu strony internetowej. Obejmuje to między innymi korzystanie z modułu obsługi unload.
Aby przetestować pamięć podręczną stanu strony internetowej, wykonaj te czynności:
Na stronie otwórz Narzędzia dla deweloperów i kliknij Aplikacja > Usługi w tle > Pamięć podręczna stanu strony internetowej.
Kliknij Testuj pamięć podręczną stanu strony internetowej. Chrome automatycznie przekieruje Cię do strony
chrome://terms/i z powrotem na stronę. Możesz również kliknąć w przeglądarce przyciski Wstecz i Dalej.
Jeśli Twoja strona nie kwalifikuje się do zapisywania w pamięci podręcznej stanu strony internetowej, na karcie Pamięć podręczna stanu strony internetowej znajdziesz listę problemów. W sekcji Przydatne możesz sprawdzić, czy używasz unload:
Reporting API
Interfejs Reporting API może być używany w połączeniu z zasadami uprawnień tylko do odczytu w celu wykrywania korzystania z unload przez użytkowników witryny.
Więcej informacji znajdziesz w artykule Korzystanie z interfejsu Reporting API do znajdowania wyładunków.
Interfejs API Bfcache notRestoredReasons
Właściwość notRestoredReasons – dodana do klasy PerformanceNavigationTiming – zawiera informacje o tym, czy użycie pamięci podręcznej bfcache podczas nawigacji zostało zablokowane, a także o przyczynach zablokowania dokumentu. Instrukcje użytkowania znajdziesz tutaj. Oto przykład ostrzeżenia o obiekcie odpowiedzi w obecnym detektorze unload:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
Kontroluj dostęp do funkcji unload
Chrome będzie stopniowo wycofywać zdarzenie unload. W międzyczasie możesz skorzystać z różnych narzędzi, aby kontrolować to zachowanie i przygotować się na nadchodzące zmiany. Pamiętaj, że nie należy korzystać z tych metod w dłuższej perspektywie i zaplanuj jak najszybsze przejście na alternatywne rozwiązania.
Poniższe opcje umożliwiają włączenie lub wyłączenie modułów obsługi unload, aby przetestować, jak będzie działać bez nich, i przygotować się na nadchodzący okres ich wycofania. Istnieją różne typy zasad:
- Zasady dotyczące uprawnień: 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 przedsiębiorstwa: narzędzia dla administratorów IT pozwalające konfigurować Chrome w organizacji lub firmie. Można je skonfigurować w panelu administracyjnym, na przykład w konsoli administracyjnej Google.
- Flagi Chrome: umożliwia pojedynczemu deweloperowi zmianę ustawienia wycofywania
unload, aby przetestować wpływ na różne witryny.
Zasady dotyczące uprawnień
W Chrome 115 dodaliśmy zasadę uprawnień, aby umożliwić witrynom rezygnację z modułów obsługi unload i natychmiastowe korzystanie z pamięci podręcznej stanu strony internetowej w celu zwiększenia wydajności witryny. Zapoznaj się z tymi przykładami konfiguracji tej funkcji w witrynie. Dzięki temu witryny będą mogły przygotować się na czas wycofania interfejsu unload.
Ta opcja zostanie rozszerzony w Chrome 117, aby umożliwić witrynom odwrotną pracę i zgodzić się na dalsze uruchamianie modułów obsługi unload, ponieważ Chrome zmienia ustawienia domyślne, tak aby w przyszłości nie uruchamiały się one. Zapoznaj się z tymi przykładami, aby nadal zezwalać na uruchamianie modułów obsługi unload. Ta zgoda nie zostanie zastosowana na stałe. Należy ją wykorzystać, aby dać witrynom czas na migrację z modułów obsługi unload.
Zasada przedsiębiorstwa
Firmy, które używają oprogramowania, które do prawidłowego działania wymaga zdarzenia unload, mogą skorzystać z zasady ForcePermissionPolicyUnloadDefaultEnabled, aby zapobiec stopniowemu wycofywaniu urządzeń znajdujących się pod ich kontrolą. Jeśli włączysz tę zasadę, unload będzie nadal domyślnie włączona w przypadku wszystkich źródeł. Strona może nadal mieć bardziej rygorystyczne zasady. Podobnie jak w przypadku rezygnacji z zasad dotyczących uprawnień, to narzędzie pozwala łagodzić potencjalne zmiany powodujące niezgodność, ale nie należy go używać w nieskończoność.
Flagi Chrome i przełączniki wiersza poleceń
Oprócz zasady przedsiębiorstwa możesz wyłączyć wycofanie tej funkcji dla poszczególnych użytkowników za pomocą flag Chrome i opcji wiersza poleceń:
Ustawienie dla parametru chrome://flags/#deprecate-unload wartości enabled spowoduje, że domyślne wycofywanie zostanie zastąpione, a moduły obsługi unload nie będą się uruchamiać. Można je zastępować w poszczególnych witrynach za pomocą zasad dotyczących uprawnień, ale nadal będą się uruchamiać domyślnie.
Tymi ustawieniami można też sterować za pomocą przełączników wiersza poleceń.
Porównanie opcji
W tabeli poniżej zebraliśmy różne zastosowania omówionych wcześniej opcji:
| Przyspiesz wycofywanie | Przyspiesz proces wycofywania (z wyjątkami) | Zapobieganie wycofywaniu w celu zapewnienia czasu na migrację | |
|---|---|---|---|
| Zasady dotyczące uprawnień (dotyczy stron/witryn) |
Tak | Tak | Tak |
| Zasady przedsiębiorstwa (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. Przez długi czas były one zawodne i nie ma gwarancji, że zostaną uruchomione w każdym przypadku zniszczenia dokumentu. Dodatkowo moduły obsługi unload są niezgodne z elementem bfcache.
Witryny, które obecnie korzystają z modułów obsługi unload, powinny się przygotować na nadchodzący okres ich wycofania. W tym celu należy przetestować istniejące moduły obsługi unload, usunąć je lub przenieść albo w ostateczności opóźnić ich wycofanie, jeśli potrzeba więcej czasu.
Podziękowania
Dziękujemy Kenji Baheux, Fergal Daly, Adriana Jara i Jeremy Wagner za pomoc w przejrzeniu tego artykułu.
Baner powitalny autorstwa Anji Bauermann w filmie Unsplash