RAIL to ukierunkowany na użytkownika model wydajności, który zapewnia strukturę do myślenia o wydajności. Model dzieli wrażenia użytkownika na kluczowe działania (np. kliknięcie, przewijanie, wczytywanie) i pomaga zdefiniować cele związane z wydajnością dla każdej z nich.
RAIL oznacza 4 różne aspekty cyklu życia aplikacji internetowej: odpowiedź, animacja, bezczynność i ładowanie. Użytkownicy mają różne oczekiwania w zakresie skuteczności w każdym z tych kontekstów, dlatego cele związane ze skutecznością są definiowane na podstawie kontekstu i badań nad wrażeniami użytkowników dotyczącymi postrzegania opóźnień przez użytkowników.
Liczą się użytkownicy
Zadbaj o to, aby użytkownicy skupiali się na Twoich działaniach związanych ze skutecznością. W tabeli poniżej znajdziesz kluczowe dane o tym, jak użytkownicy postrzegają opóźnienia skuteczności:
Postrzeganie przez użytkowników opóźnień skuteczności| od 0 do 16 ms | Użytkownicy wyjątkowo dobrze radzą sobie ze śledzeniem ruchu i nielubią niepłynnych animacji. Animacje są postrzegane jako płynne, jeśli co sekundę renderowanych jest 60 nowych klatek. Jest to 16 ms na klatkę, w tym czas potrzebny przeglądarce na wyrenderowanie nowej klatki na ekranie, co pozostawia aplikacji na utworzenie takiej klatki po około 10 ms. |
| od 0 do 100 ms | Reaguj na działania użytkowników w tym czasie, a użytkownicy mają wrażenie, że efekt jest natychmiastowy. Już dłużej, a relacja między akcją i reakcją zostanie zerwana. |
| od 100 do 1000 ms | W tym oknie rzeczy są jakby naturalnym, ciągłym postępem zadań. W przypadku większości użytkowników internetu wczytywanie stron i zmienianie widoków to zadanie. |
| 1000 ms lub więcej | Po upływie 1000 milisekund (1 sekunda) użytkownicy tracą koncentrację na wykonywanym zadaniu. |
| 10 000 ms lub więcej | Jeśli czas przekracza 10 000 milisekund (10 sekund), użytkownicy są sfrustrowani i prawdopodobnie porzucą zadania. Może nie wrócić do niego później. |
Cele i wytyczne
W kontekście systemu RAIL terminy cele i wytyczne mają konkretne znaczenie:
Cele. Kluczowe dane o skuteczności związane z wrażeniami użytkowników. Na przykład kliknij, aby malować w czasie krótszym niż 100 milisekund. Ponieważ postrzeganie przez człowieka jest względnie stałą, te cele raczej nie zmienią się w najbliższym czasie.
Wytyczne. Zalecenia, które pomagają osiągnąć cele. Mogą być związane z bieżącymi warunkami sprzętowymi i połączeniem sieciowymi oraz z czasem mogą się zmieniać.
Odpowiedź: przetwarzanie zdarzeń w czasie krótszym niż 50 ms
Cel: wprowadzanie zmian zainicjowanych przez użytkownika w ciągu 100 ms, aby użytkownicy mieli wrażenie, że interakcje są natychmiastowe.
Wskazówki:
Aby zapewnić widoczność odpowiedzi w ciągu 100 ms, przetwarzaj zdarzenia wejściowe użytkownika w ciągu 50 ms. Dotyczy to większości danych wejściowych, takich jak klikanie przycisków, przełączanie elementów sterujących formularza czy uruchamianie animacji. Nie dotyczy to przeciągania dotykowego ani przewijania.
Choć może się to wydawać sprzeczne z intuicją, nie zawsze jest to właściwe wezwanie do natychmiastowego reagowania na opinie użytkowników. Możesz użyć tego okna 100 ms do innych, bardziej kosztownych czynności, ale pamiętaj, aby nie zablokować użytkownika. Jeśli to możliwe, pracuj w tle.
W przypadku działań, które trwają dłużej niż 50 ms, zawsze przesyłaj opinię.
50 czy 100 ms?
Celem jest reagowanie w czasie krótszym niż 100 ms, dlaczego więc nasz budżet wynosi tylko 50 ms? Dzieje się tak, ponieważ zwykle oprócz obsługi danych wejściowych wykonywana jest inna praca, która zajmuje część czasu dostępnego dla akceptowanej odpowiedzi. Jeśli w czasie bezczynności aplikacja wykonuje zadania z wykorzystaniem zalecanych 50 ms fragmentów, dane wejściowe mogą być umieszczane w kolejce przez maksymalnie 50 ms, jeśli wystąpią podczas jednego z tych fragmentów. W związku z tym można przyjąć, że do rzeczywistej obsługi danych wejściowych dostępnych jest tylko pozostałe 50 ms. Efekt ten można zwizualizować na poniższym diagramie, który przedstawia, jak dane wejściowe odebrane podczas nieaktywnego zadania są umieszczane w kolejce, co skraca dostępny czas przetwarzania:
Animacja: utwórz klatkę w ciągu 10 ms.
Cele:
Tworzenie każdej klatki w animacji w ciągu maksymalnie 10 ms. Maksymalny budżet każdej klatki to 16 ms (1000 ms / 60 klatek na sekundę ≈ 16 ms), ale renderowanie każdej klatki przez przeglądarki zajmuje około 6 ms, dlatego zalecane jest 10 ms na klatkę.
Zadbaj o płynność obrazu. Użytkownicy zwracają uwagę na różnice w liczbie klatek.
Wskazówki:
W punktach wysokiego tętna, takich jak animacje, najistotniejsze jest to, by nie robić nic tam, gdzie się da, a najmniej niczego nie robić. W miarę możliwości korzystaj z odpowiedzi 100 ms na wstępne obliczenia. Dzięki temu zwiększysz swoje szanse na uzyskanie 60 kl./s.
W sekcji Wydajność renderowania znajdziesz różne strategie optymalizacji animacji.
- Animacje wizualne, np. wejścia i wyjścia, przeszkody i wskaźniki wczytywania.
- Przewijane. Obejmuje to przesuwanie, które polega na tym, że użytkownik zaczyna przewijać stronę, a potem ją cofa, a strona nadal przewija się.
- Przeciąganie. Animacje często są reprezentowane przez interakcje użytkownika, takie jak przesuwanie mapy lub ściąganie i rozciąganie palcami w celu powiększenia.
Bezczynność: maksymalizuj czas bezczynności
Cel: maksymalizuj czas bezczynności, aby zwiększyć prawdopodobieństwo, że strona zareaguje na dane wejściowe użytkownika w ciągu 50 ms.
Wskazówki:
Aby dokończyć odroczoną pracę, użyj czasu bezczynności. Na przykład przy wstępnym wczytywaniu strony wczytaj jak najmniej danych, a potem użyj czasu bezczynności, by wczytać resztę.
Możesz pracować w czasie bezczynności w ciągu maksymalnie 50 ms. a tym samym spowodować, że aplikacja przestanie odpowiadać na polecenia użytkownika w ciągu 50 ms.
Jeśli użytkownik wchodzi w interakcję ze stroną w czasie bezczynności, interakcja z nią powinna zawsze mieć najwyższy priorytet i przerywać ten czas bezczynności.
Wczytywanie: dostarczaj treści i zyskaj interaktywność w mniej niż 5 sekund
Gdy strony wczytują się powoli, użytkownicy rozpraszają się, a użytkownicy postrzegają zadanie jako nieprawidłowe. Witryny, które szybko się ładują, mają dłuższą średnią sesję, niższy współczynnik odrzuceń i większą widoczność reklam.
Cele:
Optymalizuj pod kątem wydajności szybkiego wczytywania w zależności od możliwości urządzenia i sieci użytkowników. Obecnie dobrym celem przy pierwszym wczytywaniu jest wczytanie strony i podjęcie interaktywnych działań w ciągu maksymalnie 5 sekund na urządzeniach mobilnych średniej klasy z wolnym połączeniem 3G.
Przy kolejnych wczytywaniu strona najlepiej wczyta się w mniej niż 2 sekundy.
Wskazówki:
Sprawdź wydajność wczytywania na urządzeniach mobilnych i połączeniach sieciowych, z których korzystają użytkownicy. Za pomocą Raportu na temat użytkowania Chrome możesz sprawdzić dystrybucję połączeń użytkowników. Jeśli dane nie są dostępne w przypadku Twojej witryny, możesz skorzystać z danych The Mobile Economy 2019 (Ekonomia mobilna z 2019 r.) za dobrym punktem międzynarodowym jest telefon z Androidem ze średniej półki cenowej, np. Moto G4, i wolna sieć 3G (400 ms RTT i 400 kb/s). Ta kombinacja jest dostępna na stronie WebPageTest.
Pamiętaj, że chociaż użytkownicy urządzeń mobilnych mogą twierdzić, że korzystają z połączeń 2G, 3G lub 4G, w rzeczywistości efektywna szybkość połączenia jest często znacznie wolniejsza ze względu na utratę pakietów i różnice w sieci.
Nie trzeba ładować wszystkiego w czasie krótszym niż 5 sekund, aby stworzyć wrażenie, że jest ono w pełni załadowane. Rozważ leniwe ładowanie obrazów, dzielenie kodu pakietów JavaScript i inne optymalizacje sugerowane na web.dev.
Narzędzia do pomiarów RAIL
Istnieje kilka narzędzi, które pomogą Ci zautomatyzować pomiary RAIL. Ich wybór zależy od tego, jakich informacji potrzebujesz i jakiego przepływu pracy wybierzesz.
Narzędzia deweloperskie w Chrome
Narzędzia deweloperskie w Chrome zapewniają szczegółową analizę wszystkiego, co dzieje się podczas wczytywania i uruchamiania strony. Aby zapoznać się z interfejsem panelu Wydajność, przeczytaj artykuł Pierwsze kroki z analizą wydajności środowiska wykonawczego.
Szczególnie istotne są te funkcje Narzędzi deweloperskich:
Przyspieszaj procesor, aby symulować mniej wydajne urządzenie.
Ogranicz działanie sieci, aby symulować wolniejsze połączenia.
Wyświetl aktywność w wątku głównym, aby wyświetlić wszystkie zdarzenia, które wystąpiły w wątku głównym podczas nagrywania.
Wyświetl w tabeli działania w wątkach głównych, aby posortować działania na podstawie tych, które zajęły najwięcej czasu.
Analizuj klatki na sekundę, aby sprawdzić, czy animacje działają płynnie.
Monitoruj wykorzystanie procesora, rozmiar sterty JS, węzły DOM, układy na sekundę i inne dane w czasie rzeczywistym za pomocą Monitora wydajności.
W sekcji Sieć możesz zwizualizować żądania sieciowe, które wystąpiły podczas nagrywania.
Zrób zrzuty ekranu podczas nagrywania, aby zobaczyć, jak dokładnie wyglądała strona po jej wczytaniu lub gdy uruchomiono animację itd.
Wyświetlanie interakcji, które pozwala szybko sprawdzić, co się stało na stronie po interakcji użytkownika z nią.
Wykrywaj problemy z wydajnością przewijania w czasie rzeczywistym, wyróżniając stronę za każdym razem, gdy uruchamia się potencjalnie problematyczny detektor.
Wyświetlaj zdarzenia renderowania w czasie rzeczywistym, aby wykrywać kosztowne zdarzenia malowania, które mogą negatywnie wpływać na działanie Twoich animacji.
Latarnia morska
Lighthouse jest dostępny w Chrome DevTools, na stronie PageSpeed Insights, jako rozszerzenie do Chrome, jako moduł Node.js oraz w ramach WebPageTest. Podajesz mu adres URL, symuluje on urządzenie ze średniej półki cenowej z powolnym połączeniem 3G, przeprowadza serię kontroli na stronie i wyświetla raport na temat wydajności wczytywania oraz sugestie, co można poprawić.
Szczególnie istotne są takie audyty:
Odpowiedź
Maksymalne potencjalne opóźnienie przy pierwszym działaniu. Szacuje, jak długo aplikacja zajmie odpowiedź na dane wejściowe użytkownika na podstawie czasu bezczynności wątku głównego.
Nie używa pasywnych detektorów do poprawy działania przewijania.
Total Block Time (Całkowity czas blokowania). Mierzy łączny czas, przez który strona nie odpowiada na działania użytkownika takie jak kliknięcie myszą, kliknięcie ekranu czy naciśnięcie klawiatury.
Czas na interaktywność. Mierzy, kiedy użytkownik może w spójny sposób wchodzić w interakcje ze wszystkimi elementami strony.
Wczytywanie
Nie rejestruje skryptu service worker, który steruje działaniem strony i start_url. Skrypt service worker może buforować wspólne zasoby na urządzeniu użytkownika, co skraca czas potrzebny na pobieranie zasobów przez sieć.
W sieciach komórkowych strona nie wczytuje się z wystarczającą szybkością.
Odkładanie wyświetlania obrazów poza ekranem Odłóż ładowanie obrazów poza ekranem, aż będą potrzebne.
Prawidłowo dopasowuj rozmiary obrazów. Nie wyświetlaj obrazów, które są znacznie większe od rozmiaru renderowanego w widocznym obszarze na urządzenia mobilne.
Unikaj nadmiernego rozmiaru DOM. Ogranicz bajty sieciowe, wysyłając tylko te węzły DOM, które są potrzebne do renderowania strony.
WebPageTest
WebPageTest to narzędzie do mierzenia wydajności w sieci, które za pomocą prawdziwych przeglądarek uzyskuje dostęp do stron internetowych i zbiera dane dotyczące czasu. Wpisz adres URL na stronie webpagetest.org/easy, aby uzyskać szczegółowy raport na temat wydajności wczytywania strony na prawdziwym urządzeniu Moto G4 z wolnym połączeniem 3G. Możesz też skonfigurować ją tak, aby obejmowała audyt Lighthouse.
Podsumowanie
RAIL to usługa z perspektywy, która pozwala spojrzeć na wrażenia użytkownika witryny jako na drogę złożoną z różnych interakcji. Dowiedz się, jak użytkownicy postrzegają Twoją witrynę, aby wyznaczyć cele skuteczności mające największy wpływ na ich wrażenia.
Liczą się użytkownicy
Reagować na działania użytkownika w czasie krótszym niż 100 ms.
Podczas animowania i przewijania klatki wyrenderuj ją w czasie krótszym niż 10 ms.
Maksymalizuj czas bezczynności wątku głównego.
Ładowanie treści interaktywnych w czasie krótszym niż 5000 ms.