W Chrome 108 wprowadziliśmy 2 nowe tryby: Oszczędzanie pamięci i Oszczędzanie energii, które umożliwiają użytkownikom większą kontrolę nad tym, jak Chrome wykorzystuje zasoby systemowe.
Te nowe tryby są przeznaczone przede wszystkim dla użytkowników, mają jednak pewne konsekwencje, o których deweloperzy stron internetowych powinni wiedzieć, ponieważ mogą wpływać na wygodę użytkowników witryny.
W tym poście omówimy potencjalne skutki nowych trybów i omówimy sposoby, w jakie deweloperzy stron internetowych mogą zadbać o jak najlepsze wrażenia użytkowników.
Tryb oszczędzania pamięci
Gdy tryb Oszczędzanie pamięci jest włączony, Chrome aktywnie usuwa karty, które od jakiegoś czasu nie są używane w tle. W ten sposób zwolnisz pamięć dla aktywnych kart i innych uruchomionych aplikacji. Użytkownicy mogą poinstruować Chrome, aby nie odrzucał kart z konkretnych stron. Jest to jednak ustawienie użytkownika, którego nie możesz kontrolować jako deweloper.
Po odrzuceniu karty jej tytuł i favikona są nadal widoczne na pasku kart, ale sama strona zniknie, dokładnie tak jakby została normalnie zamknięta. Jeśli użytkownik ponownie otworzy tę kartę, strona zostanie automatycznie ponownie załadowana.
W przypadku stron zawierających tylko treść odrzucenie i ponowne wczytywanie karty prawdopodobnie nie wpłynie na wygodę użytkowników, ale w przypadku bogatych, interaktywnych witryn ze złożonym procesem użytkownika ponowne załadowanie strony w trakcie procesu może być bardzo frustrujące, jeśli nie uda się przywrócić strony do miejsca, w którym użytkownik ją przerwał.
Usuwanie kart w celu zaoszczędzenia pamięci w Chrome od lat działa, ale to rozwiązanie można wykonać tylko w sytuacjach, gdy system był zbyt intensywny z wykorzystaniem pamięci. Takie sytuacje zdarzają się dość rzadko, dlatego programiści stron internetowych mogą nie zdawać sobie sprawy z tego, że się tak dzieje.
Począwszy od wersji Chrome 108 odrzucanie kart stanie się coraz bardziej powszechne, dlatego tak ważne jest, aby witryny prawidłowo radziły sobie z takimi sytuacjami.
Sprawdzone metody postępowania z odrzuconymi kartami
Odrzucenie kart nie jest nowym wyzwaniem dla programistów stron internetowych. Użytkownik zawsze może ponownie załadować stronę – celowo lub przypadkowo – przed ukończeniem zadania. Dlatego bardzo ważne jest, aby witryny zapisywały informacje o stanie użytkownika, aby móc je przywrócić, gdy użytkownik opuści stronę i wróci do niej.
Najważniejszym aspektem nie jest to, czy ma być zapisany stan użytkownika, ale kiedy. To ważne, bo po odrzuceniu karty żadne zdarzenie nie jest wywoływane, więc deweloperzy nie mają możliwości zareagowania na taki komunikat. Zamiast tego deweloperzy muszą przewidzieć taką możliwość i przygotować się z wyprzedzeniem.
Oto najlepsze czasy zapisywania stanu użytkownika:
- Okresowo, gdy zmienia się stan.
- Gdy karta działa w tle (zdarzenie
visibilitychange).
Najgorsze momenty przechowywania danych to:
- W wywołaniu zwrotnym zdarzenia
beforeunload. - W wywołaniu zwrotnym zdarzenia
unload.
Są to najgorsze momenty przechowywania informacji, ponieważ takie zdarzenia są całkowicie zawodne i nie są uruchamiane w wielu sytuacjach, m.in. po odrzuceniu karty.
Aby sprawdzić, które zdarzenia powinny być uruchamiane po odrzuceniu strony, otwórz schemat zdarzeń cyklu życia strony. Jak widać na tym diagramie, karta może przejść ze stanu „ukryta” do „odrzucone” bez uruchamiania zdarzeń.
W rzeczywistości za każdym razem, gdy strona jest ukryta, nie ma gwarancji, że inne zdarzenia się uruchomią, zanim strona zostanie odrzucona przez przeglądarkę lub zamknięta przez użytkownika. Dlatego ważne jest, aby zapisywać w zdarzeniu visibilitychange niezapisany stan użytkownika, ponieważ w przeciwnym razie nie będzie można go przywrócić.
W tym kodzie pokazano przykładową logikę utrzymywania bieżącego stanu użytkownika w kolejce po każdej zmianie lub od razu, gdy użytkownik przejdzie w tle lub opuści kartę:
let state = {};
let hasUnstoredState = false;
function storeState() {
if (hasUnstoredState) {
// Store `state` to localStorage or IndexedDB...
}
hasUnstoredState = false;
}
export function updateState(newState) {
state = newState;
hasUnstoredState = true;
requestIdleCallback(storeState);
}
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
storeState();
}
});
Wykrywanie, że karta została odrzucona
Jak już wspomnieliśmy, nie jest możliwe wykrycie, że karta zostanie odrzucona. Możliwe jednak, że została ona odrzucona po powrocie użytkownika do niej i ponownym wczytaniu strony. W takich sytuacjach ma zastosowanie właściwość document.wasDiscarded.
if (document.wasDiscarded) {
// The page was reloaded after a discard.
} else {
// The page was not reloaded after a discard.
}
Jeśli chcesz się dowiedzieć, jak często użytkownicy napotykają takie sytuacje, możesz skonfigurować narzędzie analityczne pod kątem rejestrowania tych informacji.
W Google Analytics możesz np. skonfigurować niestandardowy parametr zdarzenia, który pozwoli Ci określić, jaki odsetek odsłon strony pochodzi z odrzucenia karty:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
Jeśli jesteś dostawcą usług analitycznych, możesz dodać ten wymiar domyślnie do produktu.
Testowanie witryny w trybie Oszczędzanie pamięci
Aby sprawdzić, jak strona radzi sobie z odrzucaniem, wczytaj ją, a następnie otwórz chrome://discards w osobnej karcie lub nowym oknie.
W interfejsie chrome://discards znajdź na liście kartę, którą chcesz odrzucić, a następnie kliknij Pilne odrzucenie w kolumnie Działania.
Karta zostanie odrzucona, a później możesz wrócić do niej i sprawdzić, czy została załadowana ponownie w takim samym stanie, w jakim się znajdowała w momencie jej zamknięcia.
Zwróć uwagę, że obecnie nie ma sposobu na automatyzację odrzucania kart za pomocą narzędzi do testowania, takich jak webdriver lub puppeteer. Jednak odrzucanie i przywracanie kart jest prawie takie samo jak w przypadku ponownego wczytywania stron, więc jeśli testujesz, że stan użytkownika jest przywracany po ponownym załadowaniu użytkownika, prawdopodobnie sprawdzi się również w przypadku odrzucania/przywracania. Główna różnica między nimi polega na tym, że zdarzenia beforeunload, pagehide i unload nie uruchamiają się po odrzuceniu karty. Jeśli więc nie zakładasz, że te zdarzenia utrwalają stan użytkownika, możesz użyć ponownego załadowania, aby przetestować odrzucenie karty.
Tryb oszczędzania energii
Po włączeniu trybu oszczędzania energii Chrome oszczędza baterię, zmniejszając częstotliwość odświeżania wyświetlacza, co wpływa na dokładność przewijania i animacji oraz liczbę klatek w filmie.
W związku z tym deweloperzy nie muszą nic robić, aby włączyć tryb oszczędzania energii. Po włączeniu tego trybu interfejsy API CSS i JavaScript na potrzeby animacji, przejścia i requestAnimationFrame() będą automatycznie dostosowywać się do każdej zmiany częstotliwości odświeżania wyświetlacza.
Główny scenariusz, w którym ten tryb może sprawiać problemy, to korzystanie w witrynie z animacji opartych na języku JavaScript, które zakładają określoną częstotliwość odświeżania dla wszystkich użytkowników.
Jeśli np.Twoja witryna korzysta z pętli requestAnimationFrame() i założy, że między wywołaniami zwrotnymi upłynie dokładnie 16,67 milisekundy, po włączeniu trybu oszczędzania energii animacje będą działać 2 razy wolniej.
Pamiętaj, że założenie domyślnej częstotliwości odświeżania 60 Hz dla wszystkich użytkowników zawsze stanowiło problem, ponieważ nie dotyczy to wielu obecnych urządzeń.
Mierzę częstotliwość odświeżania wyświetlacza
Nie ma specjalnego interfejsu API do pomiaru częstotliwości odświeżania wyświetlacza. Ogólnie rzecz biorąc, użycie obecnych interfejsów API nie jest zalecane.
W przypadku istniejących interfejsów API najlepiej jest porównać sygnatury czasowe między kolejnymi wywołaniami zwrotnymi requestAnimationFrame(). W większości przypadków pozwala to oszacować częstotliwość odświeżania w danym momencie, ale nie informuje o zmianie częstotliwości. W tym celu trzeba było stale przeprowadzać ankietę w aplikacji requestAnimationFrame(). Nie oznacza to, że użytkownicy chcą oszczędzać energię i wydłużyć czas pracy baterii.
Testowanie witryny w trybie Oszczędzanie energii
Jednym ze sposobów przetestowania strony w trybie Oszczędzanie energii jest włączenie tego trybu w ustawieniach Chrome i skonfigurowanie go, by działał, gdy urządzenie jest odłączone od zasilania.
Jeśli nie masz urządzenia, które można odłączyć, możesz też włączyć ten tryb ręcznie, wykonując te czynności:
- Włącz flagę
chrome://flags/#battery-saver-mode-available. - Wejdź na stronę
chrome://discardsi kliknij link Przełącz tryb oszczędzania baterii (ważne: aby link działał, flaga#battery-saver-mode-availablemusi być włączona).
Po włączeniu tej funkcji możesz wejść w interakcję z witryną i sprawdzić, czy wszystko wygląda tak, jak powinno – na przykład czy animacje i przejścia działają z żądaną szybkością.
Podsumowanie
Chociaż tryby Oszczędzanie pamięci i Oszczędzanie energii w Chrome to głównie funkcje dla użytkowników, mają one problem z deweloperami, ponieważ nieprawidłowe korzystanie z witryny może negatywnie wpłynąć na wygodę korzystania z witryny.
Ogólnie rzecz biorąc, nowe tryby są opracowywane z myślą o dotychczasowych sprawdzonych metodach dla deweloperów. Jeśli programiści przestrzegają od dawna sprawdzonych metod internetowych, ich witryny powinny nadal działać w nowych trybach.
Jeśli jednak Twoja witryna zawiera praktyki opisane w tym poście, problemy, które mogą wystąpić u użytkowników, będą się nasilać dopiero po włączeniu tych 2 trybów.
Jak zawsze najlepszym sposobem, aby się upewnić, że zapewniasz wysoką jakość usługi, jest przetestowanie witryny pod kątem warunków spełniających warunki użytkowników.