W Chrome 108 wprowadziliśmy 2 nowe tryby: Oszczędzanie pamięci i Oszczędzanie energii, które dają użytkownikom większą kontrolę nad tym, jak Chrome wykorzystuje zasoby systemowe.
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ą potencjalnie wpływać na wrażenia użytkowników Twojej witryny.
W tym poście omówimy potencjalne skutki tych nowych trybów i to, co mogą zrobić deweloperzy stron internetowych, aby zapewnić jak najlepsze wrażenia.
Tryb oszczędzania pamięci
Gdy tryb Oszczędzanie pamięci jest włączony, Chrome będzie aktywnie usuwać karty, które od jakiegoś czasu nie były używane w tle. W ten sposób zwolnisz pamięć na aktywne karty i inne uruchomione aplikacje. Użytkownicy mogą zlecić Chrome, aby nie usuwał kart w przypadku określonych witryn. Jest to jednak ustawienie użytkownika, którym nie możesz zarządzać jako deweloper.
Gdy karta zostanie odrzucona, jej tytuł i ikona nadal będą widoczne na pasku kart, ale sama strona zniknie, tak jakby została zamknięta w normalny sposób. Jeśli użytkownik wróci do tej karty, strona zostanie automatycznie wczytana ponownie.
W przypadku stron zawierających tylko treści odrzucenie i ponowne załadowanie karty prawdopodobnie nie wpłynie na komfort korzystania z witryny. Jednak w przypadku bogatych, interaktywnych witryn o kompleksych ścieżkach użytkownika ponowne załadowanie w połowie ścieżki może być bardzo uciążliwe, jeśli witryna nie będzie w stanie przywrócić strony dokładnie do miejsca, w którym użytkownik ją opuścił.
Od lat Chrome odrzuca karty, aby oszczędzać pamięć, ale działo się tak tylko w sytuacjach, gdy system był pod presją pamięci. Ponieważ jest to stosunkowo rzadkie zjawisko, deweloperzy stron internetowych mogli nie zdawać sobie sprawy, że do niego dochodzi.
Od wersji 108 Chrome odrzucanie kart stanie się częstsze, dlatego ważne jest, aby witryny mogły odpowiednio sobie z tym radzić.
Sprawdzone metody obsługi zamykania kart
Zamknięcie karty nie jest nowym wyzwaniem dla programistów. 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żniejsze nie jest czy przechowywać stan użytkownika, ale kiedy to robić. To jest kluczowe, ponieważ nie ma zdarzenia, które jest wywoływane, gdy karta jest odrzucana, więc deweloperzy nie mają możliwości zareagowania na to zdarzenie. Zamiast tego deweloperzy muszą przewidzieć taką możliwość i odpowiednio się do niej przygotować.
Najlepszy czas na przechowywanie stanu użytkownika to:
- okresowo, gdy zmienia się stan;
- Zawsze, gdy karta działa w tle (zdarzenie
visibilitychange).
Najgorsze czasy przechowywania to:
- W wywołaniu zwrotnym zdarzenia
beforeunload. - W wywołaniu zwrotnym zdarzenia
unload.
To najgorszy moment na przechowywanie stanu, ponieważ te zdarzenia są całkowicie niewiarygodne i nie są wywoływane w wielu sytuacjach, m.in. gdy karta jest usuwana.
Na diagramie zdarzeń cyklu życia strony możesz sprawdzić, jakie zdarzenia mają być uruchamiane w przypadku odrzucania strony. Jak widać na diagramie, karta może przejść ze stanu „ukryta” do stanu „odrzucona” bez wywoływania żadnych zdarzeń.
W rzeczywistości, gdy strona jest w stanie „ukryty”, nie ma gwarancji, że jakiekolwiek inne zdarzenia zostaną wywołane, zanim strona zostanie odrzucona przez przeglądarkę lub zamknięta przez użytkownika. Dlatego ważne jest, aby zawsze zapisywać niezapisane stany użytkownika w zdarzeniu visibilitychange, ponieważ możesz nie mieć innej okazji.
Poniższy kod zawiera przykładową logikę, która pozwala ustawić w kole kolejk zapisywanie bieżącego stanu użytkownika za każdym razem, gdy się zmieni, lub natychmiast, jeśli użytkownik przełączy się na inną kartę lub zamknie 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 można wykryć, że karta ma zostać zamknięta, ale można wykryć, że została zamknięta, gdy użytkownik do niej wróci i odświeży stronę. W takich sytuacjach właściwość document.wasDiscarded będzie miała wartość true.
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 doświadczają tego typu sytuacji, możesz skonfigurować narzędzie analityczne, aby rejestrowało te informacje.
W Google Analytics możesz np. skonfigurować niestandardowy parametr zdarzenia, który pozwoli Ci określić, jaki odsetek odsłon pochodzi z odrzuconych kart:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
Jeśli jesteś dostawcą usług analitycznych, rozważ dodanie tego wymiaru do swoich usług domyślnie.
Testowanie witryny w trybie oszczędzania pamięci
Aby sprawdzić, jak strona reaguje na odrzucenie, wczytaj ją, a potem otwórz chrome://discards w osobnej karcie lub oknie.
W interfejsie chrome://discards możesz znaleźć kartę, którą chcesz odrzucić z listy, a potem w kolumnie Działania kliknąć Natychmiastowe odrzucenie.
Spowoduje to odrzucenie karty, dzięki czemu będzie można ją ponownie otworzyć i sprawdzić, czy po ponownym załadowaniu strona jest w tym samym stanie, w jakim była, gdy ją zamknięto.
Pamiętaj, że obecnie nie ma możliwości zautomatyzowania odrzucania kart za pomocą narzędzi do testowania, takich jak webdriver czy puppeteer. Jednak odrzucanie i przywracanie kart jest prawie identyczne z ponownym wczytywaniem stron, więc jeśli sprawdzisz, czy stan użytkownika jest przywracany po ponownym wczytaniu w środku przepływu użytkownika, prawdopodobnie będzie to działać również w przypadku odrzucania/przywracania. Główna różnica między tymi dwoma metodami polega na tym, że zdarzenia beforeunload, pagehide i unload nie są wywoływane, gdy karta jest odrzucana, więc dopóki nie polegasz na tych zdarzeniach, aby zachować stan użytkownika, możesz używać funkcji odświeżania, aby przetestować zachowanie podczas odrzucania i przywracania.
Tryb oszczędzania energii
Gdy tryb Oszczędzanie energii jest włączony, Chrome oszczędza baterię, zmniejszając częstotliwość odświeżania ekranu, co wpływa na jakość animacji i przewijania oraz liczbę klatek w filmie.
Zazwyczaj deweloperzy nie muszą nic robić, aby włączyć tryb oszczędzania energii. Interfejsy API CSS i JavaScriptu służące do animacji, przejść i requestAnimationFrame() będą się automatycznie dostosowywać do każdej zmiany częstotliwości odświeżania wyświetlacza po włączeniu tego trybu.
Głównym scenariuszem, w którym ten tryb może być problematyczny, jest sytuacja, gdy Twoja witryna używa animacji opartych na JavaScript, które zakładają określoną częstotliwość odświeżania dla wszystkich użytkowników.
Jeśli np. Twoja witryna używa pętli requestAnimationFrame() i zakłada, że między wywołaniami zwrotnymi upłynie dokładnie 16,67 milisekundy, animacje będą działać dwa razy wolniej, gdy włączony jest tryb oszczędzania energii.
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 ekranu
Nie ma dedykowanego interfejsu API do pomiaru częstotliwości odświeżania wyświetlacza. Ogólnie rzecz biorąc, nie zalecamy próbowania pomiaru częstotliwości odświeżania za pomocą obecnych interfejsów API.
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 jej zmianie. Aby to zrobić, musisz stale prowadzić ankietę requestAnimationFrame(), co uniemożliwia oszczędzanie energii lub wydłużanie czasu pracy na baterii.
Testowanie witryny w trybie oszczędzania energii
Jedną z metod testowania witryny w trybie oszczędzania energii jest włączenie tego trybu w ustawieniach Chrome i skonfigurowanie go tak, aby działał, gdy urządzenie nie jest podłączone do zasilania.
Jeśli nie masz urządzenia, które można odłączyć od zasilania, możesz też włączyć tryb ręcznie, wykonując te czynności:
- Włącz flagę
chrome://flags/#battery-saver-mode-available. - Otwórz stronę
chrome://discardsi kliknij link Przełącz tryb oszczędzania baterii (ważne: aby link działał, musi być włączona flaga#battery-saver-mode-available).
Po włączeniu tej funkcji możesz wchodzić w interakcję ze swoją witryną i sprawdzać, czy wszystko wygląda tak, jak powinno – np. czy animacje i przejścia są uruchamiane z żądaną szybkością.
Podsumowanie
Chociaż tryby Oszczędzanie pamięci i Oszczędzanie energii w Chrome są głównie funkcjami dla użytkowników, mają one też znaczenie dla deweloperów, ponieważ mogą negatywnie wpływać na wrażenia użytkowników odwiedzających Twoją witrynę, jeśli nie zostaną odpowiednio obsłużone.
Te nowe tryby zostały zaprojektowane z uwzględnieniem sprawdzonych metod dla deweloperów. Jeśli deweloperzy stosują sprawdzone metody tworzenia stron internetowych, ich witryny powinny działać w trybach obsługiwanych przez nowe systemy operacyjne.
Jeśli jednak Twoja witryna zawiera jakiekolwiek praktyki opisane w tym poście, prawdopodobnie Twoi użytkownicy mają problemy, które tylko się nasilą, gdy te 2 tryby będą włączone.
Jak zawsze najlepszym sposobem na sprawdzenie, czy użytkownicy mają przyjemność korzystania z Twojej witryny, jest przetestowanie jej w warunkach odpowiadających tym, w jakich znajdują się Twoi użytkownicy.