W Chrome w wersji 108 wprowadziliśmy 2 nowe tryby: Oszczędzanie pamięci i Oszczędzanie energii, które pozwalają użytkownikom lepiej kontrolować wykorzystanie zasobów systemowych przez Chrome.
Chociaż te nowe tryby są przeznaczone głównie dla użytkowników, mają one pewne konsekwencje dla programistów stron internetowych, o których powinni pamiętać, ponieważ mogą one potencjalnie wpływać na wrażenia użytkowników Twojej witryny.
W tym poście omówimy potencjalne skutki tych nowych trybów i omówimy, co deweloperzy mogą zrobić, aby zapewnić sobie najwyższą możliwą jakość usług.
Tryb oszczędzania pamięci
Gdy tryb Oszczędzanie pamięci jest włączony, Chrome proaktywnie odrzuca karty, które nie były używane w tle od jakiegoś czasu. W ten sposób zwolnisz pamięć na aktywne karty i inne uruchomione aplikacje. Użytkownicy mogą poinstruować Chrome, aby nie odrzucał kart w określonych witrynach. jest to jednak preferencja użytkownika, a deweloper nie ma nad nią kontroli.
Po zamknięciu karty jej tytuł i favikona nadal będą widoczne na pasku kart, ale sama strona zniknie – tak jakby została zamknięta w zwykły sposób. Jeśli użytkownik ponownie otworzy tę kartę, strona zostanie automatycznie załadowana.
W przypadku stron, które zawierają czystą treść, odrzucenie i ponowne załadowanie karty prawdopodobnie nie wpłynie na komfort korzystania z witryny. W przypadku interaktywnych, interaktywnych witryn o złożonym sposobie działania użytkownika ponowne załadowanie w trakcie procesu konfiguracji może być bardzo frustrujące, jeśli nie można przywrócić strony dokładnie w tym miejscu, w którym użytkownik ją przerwał.
Odrzucanie kart w celu oszczędzania pamięci od lat robi Chrome, ale stało się tak tylko w sytuacjach, gdy system miał zbyt mało pamięci. Jest to dość rzadkie przypadki, więc programiści stron internetowych mogą nie zdawać sobie z tego sprawy.
Począwszy od wersji Chrome 108 odrzucanie kart będzie coraz bardziej powszechne, dlatego tak ważne jest, by witryny właściwie radziły sobie z takimi problemami.
Sprawdzone metody postępowania z odrzucaniem kart
Odrzucanie kart nie jest nowym wyzwaniem dla programistów stron internetowych. Może się zdarzyć, że użytkownik załaduje stronę ponownie – celowo lub przypadkowo – przed wykonaniem zadania. Dlatego bardzo ważne było, aby witryny zapisywały stan użytkownika, aby mogły go przywrócić, gdy użytkownik opuści witrynę i wróci.
Najważniejszym aspektem nie jest to, czy zapisać stan użytkownika, ale kiedy go zapisać. Jest to kluczowe, ponieważ nie ma żadnego zdarzenia wywoływanego po odrzuceniu karty, więc deweloperzy nie mają żadnego sposobu, aby na nie zareagować. Zamiast tego deweloperzy muszą przewidzieć taką możliwość i odpowiednio się do nich przygotować.
Najlepsze pory do przechowywania stanu użytkownika to:
- Co jakiś czas, gdy zmienia się stan.
- Zawsze, gdy karta działa w tle (zdarzenie
visibilitychange).
Najgorsze momenty, w których należy zapisywać stan:
- W wywołaniu zwrotnym zdarzenia
beforeunload. - W wywołaniu zwrotnym zdarzenia
unload.
To najgorszy moment, w którym należy zapisać stan, ponieważ zdarzenia te są całkowicie zawodne i w wielu sytuacjach nie uruchamiają się, m.in. przy odrzucaniu karty.
Na diagramie zdarzeń cyklu życia strony możesz sprawdzić, jakie zdarzenia mają się uruchamiać w przypadku odrzucenia strony. Jak widać na tym schemacie, karta może zostać „ukryta”. stan na „odrzucono” bez uruchamiania zdarzeń.
Za każdym razem, gdy strona jest „ukryta” nie ma gwarancji, że jakiekolwiek inne zdarzenia zostaną uruchomione przed odrzuceniem strony przez przeglądarkę lub zakończeniem przez użytkownika. Dlatego tak ważne jest, aby zawsze zapisywać w zdarzeniu visibilitychange każdy niezapisany stan użytkownika, ponieważ wtedy nie będzie kolejnej szansy.
W tym kodzie podano przykładową procedurę zachowywania bieżącego stanu użytkownika w kolejce za każdym razem, gdy się on zmieni albo natychmiast, gdy użytkownik otworzy kartę w tle lub ją opuści:
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();
}
});
Wykrywam odrzucenie karty
Jak wspomnieliśmy wcześniej, nie można wykryć, że karta zostanie odrzucona, ale można wykryć, że została ona odrzucona po powrocie na nią przez użytkownika i odświeżeniu strony. W takich sytuacjach właściwość document.wasDiscarded ma wartość prawda.
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 tak, aby zbierało te informacje.
Na przykład w Google Analytics możesz skonfigurować niestandardowy parametr zdarzenia, który pozwoli Ci określić, jaki odsetek odsłon pochodzi z odrzuceń karty:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
Jeśli jesteś dostawcą usług analitycznych, możesz rozważyć dodanie tego wymiaru do swojego produktu jako domyślnego.
Testowanie witryny w trybie Oszczędzanie pamięci
Aby sprawdzić, jak strona obsługuje odrzucanie, otwórz ją i otwórz chrome://discards w osobnej karcie lub osobnym oknie.
W interfejsie chrome://discards znajdź na liście kartę, którą chcesz odrzucić, a następnie kliknij Pilne odrzucenie w kolumnie Działania.
Spowoduje to odrzucenie karty. Możesz wtedy wrócić na nią i sprawdzić, czy strona została ponownie załadowana do stanu sprzed zamknięcia.
Pamiętaj, że obecnie nie można zautomatyzować odrzucania kart za pomocą narzędzi testujących, takich jak Webdriver czy Puppeteer. Ponieważ jednak odrzucanie i przywracanie kart przebiega prawie tak samo jak ponowne załadowanie strony, jeśli przetestujesz, że stan użytkownika zostanie przywrócony po ponownym załadowaniu w trakcie procesu użytkownika, prawdopodobnie będzie to też działać w przypadku odrzucenia/przywrócenia. Podstawową różnicą między nimi jest zdarzenia beforeunload, pagehide i unload, które nie są uruchamiane, gdy karta jest odrzucana. Jeśli nie polegasz na tych zdarzeniach do zachowania stanu użytkownika, możesz za pomocą ponownego załadowania możesz przetestować działanie odrzucania i przywracania danych.
Tryb oszczędzania energii
Gdy włączony jest tryb Oszczędzanie energii, Chrome oszczędza baterię, zmniejszając częstotliwość odświeżania wyświetlacza, co ma wpływ na przewijanie, jakość animacji i liczbę klatek w filmie.
Zazwyczaj deweloperzy nie muszą nic robić, aby włączyć tryb oszczędzania energii. Po włączeniu tego trybu interfejsy API CSS i JavaScript do animacji, przejścia i requestAnimationFrame() automatycznie dostosowują się do każdej zmiany częstotliwości odświeżania wyświetlacza.
Głównym powodem, dla którego ten tryb może stanowić problem, jest sytuacja, w której Twoja witryna używa animacji opartych na języku JavaScript, które zakładają określoną częstotliwość odświeżania wszystkich użytkowników.
Jeśli np.witryna używa pętli requestAnimationFrame() i zakłada, że między wywołaniami zwrotnymi upłynęło dokładnie 16,67 milisekundy, po włączeniu trybu oszczędzania energii animacje będą wyświetlane dwukrotnie wolniej.
Pamiętaj, że deweloperzy zawsze mieli problem z założeniem domyślnej częstotliwości odświeżania na poziomie 60 Hz dla wszystkich użytkowników, ponieważ w przypadku wielu współczesnych urządzeń ta liczba może być inna.
Pomiar częstotliwości 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, próba sprawdzenia tego za pomocą obecnych interfejsów API nie jest zalecana.
W przypadku istniejących interfejsów API najlepiej jest wykorzystać 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 odświeżania. W tym celu trzeba stale przeprowadzać ankietę w usłudze requestAnimationFrame(), co nie jest zgodne z celem oszczędzania energii lub czasu pracy na baterii.
Testowanie witryny w trybie oszczędzania energii
Jednym ze sposobów sprawdzenia witryny w trybie Oszczędzanie energii jest włączenie tego trybu w ustawieniach Chrome i skonfigurowanie go tak, aby uruchamiał się po odłączeniu urządzenia od zasilania.
Jeśli nie masz urządzenia, które można odłączyć, możesz włączyć ten tryb ręcznie, wykonując te czynności:
- Włącz flagę
chrome://flags/#battery-saver-mode-available. - Wejdź na
chrome://discardsi kliknij link Przełącz tryb oszczędzania baterii (ważne: aby link zadziałał, flaga#battery-saver-mode-availablemusi być włączona).
Po włączeniu możesz korzystać z witryny i sprawdzać, czy wszystko wygląda tak, jak powinno – np. czy animacje i przejścia uruchamiają się z odpowiednią szybkością.
Podsumowanie
Chociaż tryby Oszczędzanie pamięci i Oszczędzanie energii w Chrome są funkcjami przede wszystkim dla użytkowników, mają one niekorzystny wpływ na programistów, bo nieprawidłowe korzystanie z nich może negatywnie wpływać na komfort korzystania z witryny.
Zasadniczo nowe tryby zostały zaprojektowane z myślą o istniejących sprawdzonych metodach dla programistów. Jeśli deweloperzy od dawna stosują sprawdzone metody dotyczące witryn, ich witryny powinny dobrze działać w tych nowych trybach.
Jeśli jednak Twoja witryna stosuje praktykę opisaną w tym poście, najprawdopodobniej użytkownicy napotykają problemy, które tylko nasilają się po włączeniu tych 2 trybów.
Jak zawsze, najlepszym sposobem na potwierdzenie komfortu jest przetestowanie witryny pod kątem warunków, które odpowiadają potrzebom użytkowników.