Zakres możliwości urządzeń, które mogą łączyć się z internetem, jest obecnie szerszy niż kiedykolwiek wcześniej. Ta sama aplikacja internetowa, która jest dostarczana na komputerze z systemem operacyjnym wysokiej klasy, może być również dostarczana na telefon, zegarek lub tablet o małej mocy obliczeniowej. Tworzenie atrakcyjnych aplikacji, które działają płynnie na dowolnym urządzeniu, może być bardzo trudne.
Interfejs Device Memory API to nowa funkcja platformy internetowej, która ma pomóc programistom stron internetowych w radzenia sobie z obecną różnorodnością urządzeń. Dodaje do obiektu navigator właściwość tylko do odczytu navigator.deviceMemory, która zwraca ilość pamięci RAM urządzenia w gigabajtach zaokrągloną w dół do najbliższej potęgi dwójki. Interfejs API zawiera też nagłówek Client HintsDevice-Memory, który przekazuje tę samą wartość.
Interfejs Device Memory API umożliwia programistom 2 główne działania:
- podejmować decyzje dotyczące zasobów do wyświetlenia na podstawie zwróconej wartości pamięci urządzenia (np. wyświetlać użytkownikom na urządzeniach o małej ilości pamięci wersję „lite” aplikacji);
- Przekazuj tę wartość do usługi analitycznej, aby lepiej zrozumieć, jak pamięć urządzenia koreluje z zachowaniami użytkowników, konwersjami lub innymi danymi ważnymi dla Twojej firmy.
dostosowywanie treści dynamicznie na podstawie pamięci urządzenia;
Jeśli masz własny serwer WWW i możesz zmodyfikować logikę obsługi zasobów, możesz warunkowo odpowiadać na żądania zawierające nagłówek wskazówek dla klienta Device-Memory.
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
Dzięki tej metodzie możesz utworzyć co najmniej 1 wersję skryptów aplikacji i odpowiadać na żądania klienta warunkowo na podstawie wartości ustawionej w nagłówku Device-Memory. Nie muszą one zawierać całkowicie innego kodu (jest on trudniejszy w utrzymaniu). W większości przypadków wersja „lite” będzie po prostu wykluczać funkcje, które mogą być drogie i nie są kluczowe dla wrażeń użytkowników.
Korzystanie z nagłówka ze wskazówkami klienta
Aby włączyć nagłówek Device-Memory, dodaj tag podpowiedzi klienta <meta> do <head> dokumentu:
<meta http-equiv="Accept-CH" content="Device-Memory">
Możesz też umieścić w nagłówkach odpowiedzi serwera Accept-CH wartość „Device-Memory”:
HTTP/1.1 200 OK
Date: Thu Dec 07 2017 11:44:31 GMT
Content-Type: text/html
Accept-CH: Device-Memory, Downlink, Viewport-Width
To powoduje, że przeglądarka wysyła nagłówek Device-Memory ze wszystkimi żądaniami dotyczącymi zasobów podrzędnych na bieżącej stronie.
Inaczej mówiąc, gdy wdrożysz w swojej witrynie jedną z wymienionych powyżej opcji, a użytkownik wejdzie na nią z urządzenia z 0,5 GB pamięci RAM, wszystkie żądania dotyczące obrazów, plików CSS i skryptów JavaScript z tej strony będą zawierać nagłówek Device-Memory z wartością „0,5”, a Twój serwer może odpowiadać na takie żądania w dowolny sposób.
Na przykład ścieżka Express wyświetla wersję „lite” skryptu, jeśli nagłówek Device-Memory jest ustawiony, a jego wartość jest mniejsza niż 1, lub wyświetla wersję „pełną”, jeśli przeglądarka nie obsługuje nagłówka Device-Memory lub jeśli jego wartość wynosi 1 lub więcej:
app.get('/static/js/:scriptId', (req, res) => {
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `scriptVersion` to "lite" if (and only if)
// `Device-Memory` isn't undefined and returns a number less than 1.
const scriptVersion = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Respond with the file based on `scriptVersion` above.
res.sendFile(`./path/to/${req.params.scriptId}.${scriptVersion}.js`);
});
Korzystanie z interfejsu JavaScript API
W niektórych przypadkach (np. w przypadku serwera plików statycznych lub sieci CDN) nie będzie można warunkowo odpowiadać na żądania na podstawie nagłówka HTTP. W takich przypadkach możesz użyć interfejsu JavaScript API, aby wysyłać żądania warunkowe w kodzie JavaScript.
Ta logika jest podobna do opisanej powyżej metody ekspresowej, z tą różnicą, że w logice po stronie klienta dynamicznie określa adres URL skryptu:
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `componentVersion` to "lite" if (and only if)
// deviceMemory isn't undefined and returns a number less than 1.
const componentVersion = navigator.deviceMemory < 1 ? 'lite' : 'full';
const component = await import(`path/to/component.${componentVersion}.js`);
component.init();
Chociaż warunkowe wyświetlanie różnych wersji tego samego komponentu na podstawie możliwości urządzenia jest dobrą strategią, czasami lepiej jest w ogóle nie wyświetlać danego komponentu.
W wielu przypadkach komponenty są czysto funkcjonalne. Dodają one trochę ciepła, ale nie są wymagane do działania głównej funkcji aplikacji. W takich przypadkach lepiej nie wczytywać takich komponentów. Jeśli komponent mający poprawić wrażenia użytkownika powoduje, że aplikacja działa wolno lub nie odpowiada, nie spełnia swojego celu.
W przypadku każdej decyzji, która wpływa na wrażenia użytkownika, ważne jest, aby zmierzyć jej wpływ. Ważne jest też, aby mieć jasny obraz tego, jak obecnie działa Twoja aplikacja.
Zrozumienie korelacji między pamięcią urządzenia a zachowaniem użytkowników w przypadku bieżącej wersji aplikacji pozwoli Ci lepiej określić, jakie działania należy podjąć. Pozwoli Ci też wyznaczyć punkt odniesienia, na podstawie którego będziesz mógł mierzyć skuteczność przyszłych zmian.
Śledzenie pamięci urządzenia za pomocą funkcji analitycznych
Interfejs Device Memory API jest nowy i większość dostawców narzędzi analitycznych nie śledzi go domyślnie. Na szczęście większość dostawców usług analitycznych udostępnia sposób śledzenia danych niestandardowych (np. Google Analytics ma funkcję Wymiary niestandardowe), której możesz używać do śledzenia pamięci na urządzeniach użytkowników.
Korzystanie z niestandardowego wymiaru pamięci urządzenia
Używanie wymiarów niestandardowych w Google Analytics to proces dwuetapowy.
- Skonfiguruj wymiar niestandardowy w Google Analytics.
- Zaktualizuj kod śledzenia, aby
setbyła to wartość pamięci urządzenia dla utworzonego przez Ciebie wymiaru niestandardowego.
Podczas tworzenia wymiaru niestandardowego nadaj mu nazwę „Pamięć urządzenia” i wybierz zakres „sesja”, ponieważ jego wartość nie będzie się zmieniać w trakcie sesji przeglądania użytkownika:
Następnie zaktualizuj kod śledzenia. Oto przykład tego, jak może to wyglądać. Pamiętaj, że w przypadku przeglądarek, które nie obsługują interfejsu Device Memory API, wartość wymiaru będzie wynosić „(nie ustawiono)”.
// Create the tracker from your tracking ID.
// Replace "UA-XXXXX-Y" with your Google Analytics tracking ID.
ga('create', 'UA-XXXXX-Y', 'auto');
// Set the device memory value as a custom dimension on the tracker.
// This will ensure it gets sent with all future data to Google Analytics.
// Note: replace "XX" with the index of the custom dimension you created
// in the Google Analytics admin.
ga('set', 'dimensionXX', navigator.deviceMemory || '(not set)');
// Do any other other custom setup you want...
// Send the initial pageview.
ga('send', 'pageview');
Raportowanie danych o pamięci urządzenia
Gdy wymiar pamięci urządzenia będzie w obiekcie trackera set, wszystkie dane wysyłane do Google Analytics będą zawierały tę wartość.
Umożliwi Ci to podział dowolnych danych (np. czasu wczytywania strony, ukończenia celu itp.) według pamięci urządzenia, aby sprawdzić, czy występują jakieś korelacje.
Pamięć urządzenia jest wymiarem niestandardowym, a nie wbudowanym, więc nie zobaczysz go w żadnym z raportów standardowych. Aby uzyskać dostęp do tych danych, musisz utworzyć raport niestandardowy. Konfiguracja raportu niestandardowego, który porównuje czasy wczytywania według pamięci urządzenia, może wyglądać np. tak:
Wygenerowany raport może wyglądać tak:
Gdy zbierzesz dane o pamięci urządzenia i uzyskasz poziom odniesienia dla korzystania z aplikacji przez użytkowników we wszystkich zakresach pamięci, możesz poeksperymentować z udostępnianiem różnych zasobów różnym użytkownikom (za pomocą metod opisanych w sekcji powyżej). Następnie możesz sprawdzić wyniki i sprawdzić, czy się poprawiły.
Podsumowanie
W tym artykule opisujemy, jak za pomocą interfejsu Device Memory API dostosować aplikację do możliwości urządzeń użytkowników, a także jak mierzyć ich wrażenia z korzystania z aplikacji.
Chociaż ten artykuł dotyczy interfejsu Device Memory API, większość opisanych w nim technik można zastosować do dowolnego interfejsu API, który raportuje możliwości urządzenia lub warunki sieci.
W miarę jak rośnie liczba urządzeń, deweloperzy powinni jeszcze uważniej niż kiedykolwiek uwzględniać potrzeby wszystkich użytkowników przy podejmowaniu decyzji wpływających na ich wrażenia.