RAIL to skupiony na użytkowniku model wydajności, który zapewnia strukturę myślenia o wydajności. Model dzieli doświadczenie użytkownika na kluczowe działania (np. kliknięcie, przewijanie, wczytywanie) i pomaga określać cele wydajności dla każdego z nich.
RAIL to akronim oznaczający 4 różne aspekty cyklu życia aplikacji internetowej: response (odpowiedź), animation (animacja), idle (bezczynność) i load (wczytywanie). Użytkownicy mają różne oczekiwania dotyczące wydajności w każdym z tych kontekstów, dlatego cele wydajności są określane na podstawie kontekstu i badań UX dotyczących tego, jak użytkownicy postrzegają opóźnienia.
Liczą się użytkownicy
Skup się na użytkownikach. W tabeli poniżej znajdziesz opis kluczowych danych dotyczących tego, jak użytkownicy postrzegają opóźnienia w działaniu:
Postrzeganie opóźnień przez użytkowników| 0–16 ms | Użytkownicy doskonale śledzą ruch i nie lubią, gdy animacje nie są płynne. Animacje są dla nich płynne, o ile co sekundę renderowanych jest 60 nowych klatek. To 16 ms na klatkę, w tym czas potrzebny przeglądarce na narysowanie nowej klatki na ekranie. Aplikacja ma więc około 10 ms na wygenerowanie klatki. |
| 0–100 ms | Reaguj na działania użytkowników w tym przedziale czasu, aby mieli wrażenie, że wynik jest natychmiastowy. Jeśli będzie dłuższy, związek między działaniem a reakcją zostanie zerwany. |
| 100–1000 ms | W tym oknie wszystko wydaje się naturalną i ciągłą sekwencją zadań. Dla większości użytkowników internetu wczytywanie stron lub zmienianie widoków to zadanie. |
| 1000 ms lub więcej | Po upływie 1000 milisekund (1 sekundy) użytkownicy tracą koncentrację na wykonywanym zadaniu. |
| 10 000 ms lub więcej | Po upływie 10 sekund (10 000 milisekund) użytkownicy są sfrustrowani i prawdopodobnie porzucą zadania. Mogą wrócić później, ale nie muszą. |
Cele i wytyczne
W kontekście modelu RAIL terminy cele i wytyczne mają określone znaczenie:
Cele: kluczowe dane o skuteczności związane z wrażeniami użytkownika. Na przykład kliknij, aby malować w czasie krótszym niż 100 milisekund. Ponieważ ludzka percepcja jest stosunkowo stała, te cele prawdopodobnie nie ulegną zmianie w najbliższym czasie.
Wytyczne Rekomendacje, które pomogą Ci osiągnąć cele. Mogą one być dostosowane do aktualnych warunków sprzętowych i połączenia sieciowego, dlatego mogą się z czasem zmieniać.
Odpowiedź: przetwarzanie zdarzeń w czasie krótszym niż 50 ms
Cel: dokończenie przejścia zainicjowanego przez dane wejściowe użytkownika w ciągu 100 ms, aby użytkownicy mieli wrażenie, że interakcje są natychmiastowe.
Wytyczne:
Aby zapewnić widoczną reakcję w ciągu 100 ms, przetwarzaj zdarzenia związane z działaniami użytkownika w ciągu 50 ms. Dotyczy to większości działań, takich jak klikanie przycisków, przełączanie elementów sterujących formularza czy uruchamianie animacji. Nie dotyczy to przeciągania ani przewijania za pomocą dotyku.
Chociaż może się to wydawać sprzeczne z intuicją, nie zawsze warto od razu reagować na dane wejściowe użytkownika. W tym 100-milisekundowym przedziale czasu możesz wykonywać inne wymagające zadania, ale uważaj, aby nie blokować użytkownika. Jeśli to możliwe, wykonuj pracę w tle.
W przypadku działań, których wykonanie trwa dłużej niż 50 ms, zawsze przekazuj informacje zwrotne.
50 ms czy 100 ms?
Celem jest odpowiadanie na dane wejściowe w czasie krótszym niż 100 ms, więc dlaczego nasz budżet wynosi tylko 50 ms? Dzieje się tak, ponieważ oprócz obsługi danych wejściowych wykonywane są inne zadania, które zajmują część czasu dostępnego na akceptowalną reakcję na dane wejściowe. Jeśli aplikacja wykonuje pracę w zalecanych 50-milisekundowych blokach w czasie bezczynności, oznacza to, że dane wejściowe mogą być kolejkowane przez maksymalnie 50 ms, jeśli wystąpią w jednym z tych bloków pracy. Biorąc to pod uwagę, można bezpiecznie założyć, że na rzeczywistą obsługę danych wejściowych pozostaje tylko 50 ms. Ten efekt jest widoczny na poniższym diagramie, który pokazuje, jak dane wejściowe otrzymane podczas zadania bezczynnego są umieszczane w kolejce, co skraca dostępny czas przetwarzania:
Animacja: wygenerowanie klatki w 10 ms
Cele:
Każda klatka animacji musi być generowana w czasie nie dłuższym niż 10 ms. Technicznie maksymalny budżet dla każdej klatki wynosi 16 ms (1000 ms / 60 klatek na sekundę ≈ 16 ms), ale przeglądarki potrzebują około 6 ms na renderowanie każdej klatki, stąd wytyczna 10 ms na klatkę.
Zadbaj o płynność obrazu. Użytkownicy zauważają, gdy liczba klatek na sekundę się zmienia.
Wytyczne:
W przypadku elementów wymagających dużej mocy obliczeniowej, takich jak animacje, kluczowe jest, aby w miarę możliwości nie wykonywać żadnych działań, a w innych przypadkach ograniczać je do minimum. W miarę możliwości wykorzystuj 100-milisekundową odpowiedź do wstępnego obliczania kosztownych operacji, aby zwiększyć szanse na osiągnięcie 60 klatek na sekundę.
Więcej informacji o różnych strategiach optymalizacji animacji znajdziesz w sekcji Wydajność renderowania.
- animacje wizualne, takie jak wejścia i wyjścia, przejścia i wskaźniki ładowania;
- Przewijanie. Obejmuje to przewijanie z rozpędu, czyli sytuację, w której użytkownik zaczyna przewijać, a potem puszcza ekran i strona nadal się przewija.
- Przeciąganie. Animacje często są wywoływane przez interakcje użytkownika, takie jak przesuwanie mapy czy powiększanie jej za pomocą gestu uszczypnięcia.
Bezczynność: maksymalizuj czas bezczynności
Cel: maksymalizacja czasu bezczynności, aby zwiększyć prawdopodobieństwo, że strona zareaguje na działanie użytkownika w ciągu 50 ms.
Wytyczne:
Wykorzystuj czas bezczynności na dokończenie odłożonych zadań. Na przykład w przypadku początkowego ładowania strony załaduj jak najmniej danych, a potem użyj czasu bezczynności, aby załadować resztę.
Wykonywanie pracy w czasie bezczynności w ciągu 50 ms lub krótszym. W przeciwnym razie możesz zakłócić zdolność aplikacji do reagowania na działania użytkownika w ciągu 50 ms.
Jeśli użytkownik wejdzie w interakcję ze stroną podczas pracy w czasie bezczynności, interakcja użytkownika powinna zawsze mieć najwyższy priorytet i przerwać pracę w czasie bezczynności.
Wczytywanie: dostarczanie treści i umożliwianie interakcji w mniej niż 5 sekund.
Gdy strony wczytują się powoli, uwaga użytkowników się rozprasza i uważają oni, że zadanie nie działa prawidłowo. Witryny, które szybko się wczytują, mają dłuższe średnie sesje, niższe współczynniki odrzuceń i wyższą widoczność reklam.
Cele:
Optymalizuj pod kątem szybkiego wczytywania w zależności od urządzenia i możliwości sieci użytkowników. Obecnie dobrym celem w przypadku pierwszych wczytań jest wczytanie strony i umożliwienie interakcji w ciągu 5 sekund lub krócej na urządzeniach mobilnych średniej klasy z wolnym połączeniem 3G.
W przypadku kolejnych wczytań dobrym celem jest wczytanie strony w mniej niż 2 sekundy.
Wytyczne:
Sprawdź wydajność ładowania na urządzeniach mobilnych i połączeniach sieciowych, które są powszechne wśród Twoich użytkowników. Aby poznać rozkład połączeń użytkowników, możesz skorzystać z Raportu na temat użytkowania Chrome. Jeśli dane nie są dostępne w przypadku Twojej witryny, w raporcie The Mobile Economy 2019 sugeruje się, że dobrym globalnym punktem odniesienia jest telefon z Androidem ze średniej półki, np. Moto G4, i wolna sieć 3G (zdefiniowana jako czas RTT wynoszący 400 ms i prędkość przesyłania danych 400 kbps). Ta kombinacja jest dostępna w narzędziu WebPageTest.
Pamiętaj, że chociaż urządzenie typowego użytkownika mobilnego może twierdzić, że ma połączenie 2G, 3G lub 4G, w rzeczywistości efektywna szybkość połączenia jest często znacznie mniejsza ze względu na utratę pakietów i różnice w sieci.
Aby wywołać wrażenie pełnego wczytania, nie musisz wczytywać wszystkiego w ciągu 5 sekund. Rozważ leniwe wczytywanie obrazów, dzielenie pakietów JavaScriptu i inne optymalizacje sugerowane na web.dev.
Narzędzia do pomiaru RAIL
Istnieje kilka narzędzi, które pomogą Ci zautomatyzować pomiary RAIL. To, którego z nich użyjesz, zależy od rodzaju potrzebnych informacji i preferowanego sposobu pracy.
Narzędzia deweloperskie w Chrome
Narzędzia deweloperskie w Chrome zapewniają szczegółową analizę wszystkiego, co dzieje się podczas wczytywania lub działania strony. Aby zapoznać się z interfejsem panelu Wydajność, przeczytaj artykuł Pierwsze kroki w analizowaniu wydajności w czasie działania.
Szczególnie przydatne są te funkcje Narzędzi deweloperskich:
Ogranicz wydajność procesora, aby symulować mniej wydajne urządzenie.
Ogranicz przepustowość sieci, aby symulować wolniejsze połączenia.
Wyświetl aktywność wątku głównego, aby zobaczyć wszystkie zdarzenia, które wystąpiły w wątku głównym podczas nagrywania.
Wyświetl aktywności głównego wątku w tabeli, aby posortować aktywności według czasu, jaki zajęły.
Analizuj liczbę klatek na sekundę (FPS), aby sprawdzić, czy animacje działają płynnie.
Monitoruj w czasie rzeczywistym wykorzystanie procesora, rozmiar sterty JS, węzły DOM, układy na sekundę i inne parametry za pomocą monitora wydajności.
Wizualizuj żądania sieciowe, które wystąpiły podczas nagrywania w sekcji Sieć.
Rób zrzuty ekranu podczas nagrywania, aby odtworzyć dokładnie to, jak wyglądała strona podczas ładowania lub uruchamiania animacji itp.
Wyświetlaj interakcje, aby szybko określić, co się stało na stronie po interakcji użytkownika.
Wykrywaj problemy z przewijaniem w czasie rzeczywistym, podświetlając stronę za każdym razem, gdy uruchomi się potencjalnie problematyczny odbiornik.
Wyświetlaj zdarzenia malowania w czasie rzeczywistym, aby identyfikować kosztowne zdarzenia malowania, które mogą pogarszać wydajność animacji.
Latarnia morska
Lighthouse jest dostępne w narzędziach deweloperskich w Chrome, w PageSpeed Insights, jako rozszerzenie do Chrome, jako moduł Node.js i w WebPageTest. Podajesz adres URL, a narzędzie symuluje urządzenie średniej klasy z wolnym połączeniem 3G, przeprowadza serię audytów strony, a następnie generuje raport o szybkości ładowania i sugestiach dotyczących ulepszeń.
Szczególnie istotne są te audyty:
Odpowiedź
Maks. potencjalne opóźnienie przy 1. działaniu Szacuje, ile czasu zajmie aplikacji odpowiedź na działanie użytkownika na podstawie czasu bezczynności głównego wątku.
Nie używa pasywnych detektorów do poprawy działania przewijania.
Łączny czas blokowania Mierzy łączny czas, w którym strona nie może odpowiadać na działania użytkownika, takie jak kliknięcia myszą, dotknięcia ekranu czy naciśnięcia klawiszy.
Czas do interaktywności Mierzy, kiedy użytkownik może w sposób ciągły wchodzić w interakcję ze wszystkimi elementami strony.
Wczytywanie
Nie rejestruje skryptu service worker, który steruje stroną i adresem URL startowym. Service worker może buforować typowe zasoby na urządzeniu użytkownika, co skraca czas pobierania zasobów z sieci.
Wczytywanie strony przez sieć komórkową nie jest dostatecznie szybkie.
Opóźnij wyświetlanie obrazów poza ekranem. Opóźnij ładowanie obrazów niewyświetlanych na ekranie do momentu, aż będą potrzebne.
Odpowiednio dostosowuj rozmiar obrazów. Nie wyświetlaj obrazów, które są znacznie większe niż rozmiar renderowany w widocznym obszarze na urządzeniu mobilnym.
Unikaj nadmiernego rozmiaru DOM Zmniejsz liczbę bajtów przesyłanych w sieci, wysyłając tylko te węzły DOM, które są potrzebne do renderowania strony.
WebPageTest
WebPageTest to narzędzie do testowania wydajności stron internetowych, które korzysta z prawdziwych przeglądarek, aby uzyskiwać dostęp do stron i zbierać dane o czasie. Wpisz adres URL na stronie webpagetest.org/easy, aby uzyskać szczegółowy raport o szybkości ładowania strony na prawdziwym urządzeniu Moto G4 z wolnym połączeniem 3G. Możesz też skonfigurować go tak, aby obejmował audyt Lighthouse.
Podsumowanie
RAIL to sposób patrzenia na wrażenia użytkowników witryny jako na podróż składającą się z różnych interakcji. Poznaj opinie użytkowników o Twojej witrynie, aby wyznaczać cele dotyczące skuteczności, które mają największy wpływ na wygodę użytkowników.
Liczą się użytkownicy
reagować na działania użytkownika w czasie krótszym niż 100 ms;
Generowanie klatki w mniej niż 10 ms podczas animacji lub przewijania.
Maksymalizuj czas nieaktywności wątku głównego.
Wczytuj treści interaktywne w czasie krótszym niż 5000 ms.