RAIL to skoncentrowany na użytkowniku model wydajności, który zapewnia strukturę do myślenia o wydajności. Model dzieli doświadczenia użytkownika na kluczowe działania (np. kliknięcie, przewinięcie, wczytanie) i pomaga określić cele skuteczności dla każdego z nich.
RAIL to skrót od 4 różnych aspektów cyklu życia aplikacji internetowej: reakcji, animacji, bezczynności i wczytywania. Użytkownicy mają różne oczekiwania dotyczące wydajności w każdym z tych kontekstów, dlatego cele skuteczności są definiowane na podstawie kontekstu i badań UX nad tym, jak użytkownicy postrzegają opóźnienia.
Liczą się użytkownicy
Skoncentruj się na użytkownikach, aby poprawić skuteczność. W tabeli poniżej opisano kluczowe dane dotyczące tego, jak użytkownicy postrzegają opóźnienia w działaniu:
Postrzeganie przez użytkowników opóźnień w działaniu| 0–16 ms | Użytkownicy są wyjątkowo dobrzy w śledzeniu ruchu i nie lubią, gdy animacje nie są płynne. Animacje są postrzegane jako płynne, jeśli co sekundę renderowanych jest 60 nowych klatek. To 16 ms na klatkę, w tym czas potrzebny przeglądarce na narysowanie nowej klatki na ekranie, co daje aplikacji około 10 ms na wygenerowanie klatki. |
| 0–100 ms | Jeśli odpowiesz na działania użytkowników w tym przedziale czasowym, będą oni mieli wrażenie, że wynik jest natychmiastowy. Jeśli trwa to dłużej, związek między działaniem a reakcją zostaje przerwany. |
| 100–1000 ms | W tym oknie wszystko wydaje się częścią naturalnego i ciągłego postępu zadań. Dla większości użytkowników internetu zadaniem jest wczytywanie stron lub zmiana widoków. |
| 1000 ms lub więcej | Jeśli czas ten przekracza 1000 milisekund (1 sekundę), użytkownicy tracą koncentrację na wykonywanym zadaniu. |
| 10 000 ms lub więcej | Jeśli czas oczekiwania przekracza 10 000 milisekund (10 sekund), użytkownicy są sfrustrowani i prawdopodobnie porzucą zadania. Może wrócić później, ale nie musi. |
Cele i wytyczne
W kontekście modelu RAIL terminy cele i wytyczne mają określone znaczenie:
Cele. Kluczowe wskaźniki skuteczności związane z wrażeniami użytkownika. Na przykład kliknięcie, aby wyrenderować, w mniej niż 100 milisekund. Ponieważ ludzka percepcja jest względnie stała, te cele raczej nie zmienią się w najbliższym czasie.
Wytyczne. Rekomendacje, które pomogą Ci osiągnąć cele. Mogą one zależeć od aktualnego sprzętu i warunków połączenia sieciowego, dlatego mogą się zmieniać.
Odpowiedź: przetwarzanie zdarzeń w czasie krótszym niż 50 ms.
Cel: przejście zainicjowane przez użytkownika powinno zakończyć się w ciągu 100 ms, aby użytkownik miał wrażenie, że interakcja następuje natychmiast.
Wskazówki:
Aby zapewnić widoczną odpowiedź 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 ani przewijania dotykowego.
Może to brzmieć sprzecznie z intuicją, ale nie zawsze warto natychmiast reagować na dane wejściowe użytkownika. Możesz wykorzystać to 100-milisekundowe okno na wykonanie innych kosztownych zadań, ale uważaj, aby nie zablokować użytkownika. Jeśli to możliwe, wykonuj zadania w tle.
W przypadku działań, których wykonanie zajmuje więcej niż 50 ms, zawsze podawaj informacje zwrotne.
50 ms czy 100 ms?
Celem jest reagowanie 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 zwykle wykonywane są inne zadania, które zajmują część czasu dostępnego na akceptowalną odpowiedź na dane wejściowe. Jeśli aplikacja wykonuje pracę w zalecanych 50-milisekundowych fragmentach w czasie bezczynności, oznacza to, że dane wejściowe mogą być umieszczane w kolejce na maksymalnie 50 ms, jeśli pojawią się podczas jednego z tych fragmentów pracy. Biorąc to pod uwagę, można bezpiecznie założyć, że na obsługę rzeczywistych danych wejściowych pozostaje tylko 50 ms. Ten efekt jest przedstawiony na poniższym diagramie, który pokazuje, jak dane wejściowe otrzymane podczas zadania bezczynności są umieszczane w kolejce, co skraca dostępny czas przetwarzania:
Animacja: wygeneruj klatkę w 10 ms
Cele:
Wygeneruj każdą klatkę animacji w czasie nie dłuższym niż 10 ms. Technicznie maksymalny budżet każdej klatki wynosi 16 ms (1000 ms / 60 klatek na sekundę ≈ 16 ms), ale przeglądarki potrzebują około 6 ms na wyrenderowanie każdej klatki, stąd wytyczna 10 ms na klatkę.
Zadbaj o płynność wizualną. Użytkownicy zauważają zmiany liczby klatek.
Wskazówki:
W przypadku dużego obciążenia, np. podczas animacji, kluczem jest nie robienie niczego, jeśli to możliwe, lub robienie absolutnego minimum, jeśli nie jest to możliwe. W miarę możliwości wykorzystaj czas odpowiedzi wynoszący 100 ms na wstępne obliczenie kosztownych operacji, aby zmaksymalizować szanse na osiągnięcie 60 kl./s.
Różne strategie optymalizacji animacji znajdziesz w artykule o wydajności renderowania.
- animacje wizualne, takie jak wejścia i wyjścia, klatki pośrednie i wskaźniki wczytywania;
- Przewijanie. Obejmuje to szybkie przewijanie, czyli sytuację, gdy użytkownik zaczyna przewijać, a potem puszcza, a strona nadal się przewija.
- Przeciąganie. Animacje często następują po interakcjach użytkownika, takich jak przesuwanie mapy lub powiększanie przez rozciąganie.
Bezczynność: maksymalizacja czasu bezczynności
Cel: maksymalizacja czasu bezczynności, aby zwiększyć prawdopodobieństwo, że strona zareaguje na działania użytkownika w ciągu 50 ms.
Wskazówki:
Wykorzystaj czas bezczynności, aby dokończyć odłożone zadania. Na przykład podczas początkowego wczytywania strony wczytaj jak najmniej danych, a następnie wykorzystaj czas bezczynności, aby wczytać resztę.
wykonywać pracę w czasie bezczynności w ciągu maksymalnie 50 ms; Jeśli będzie to trwało dłużej, może to zakłócić zdolność aplikacji do reagowania na dane wejściowe użytkownika w ciągu 50 ms.
Jeśli użytkownik wejdzie w interakcję ze stroną podczas wykonywania zadania w czasie bezczynności, interakcja użytkownika powinna zawsze mieć najwyższy priorytet i przerwać zadanie wykonywane w czasie bezczynności.
Wczytywanie: dostarczanie treści i interaktywność w ciągu 5 sekund.
Gdy strony wczytują się powoli, użytkownicy tracą uwagę i uważają, że zadanie nie działa. Witryny, które szybko się wczytują, mają dłuższe średnie sesje, niższe współczynniki odrzuceń i wyższą widoczność reklam.
Cele:
Zoptymalizuj szybkość wczytywania pod kątem możliwości urządzeń i sieci użytkowników. Obecnie dobrym celem w przypadku pierwszego wczytania jest wczytanie strony i osiągnięcie interaktywności w czasie nie dłuższym niż 5 sekund na urządzeniach mobilnych średniej klasy z wolnym połączeniem 3G.
W przypadku kolejnych wczytań dobrym celem jest wczytanie strony w czasie krótszym niż 2 sekundy.
Wskazówki:
Przetestuj wydajność wczytywania na urządzeniach mobilnych i połączeniach sieciowych, które są popularne wśród Twoich użytkowników. Możesz użyć Raportu na temat użytkowania Chrome, aby sprawdzić rozkład połączeń użytkowników. Jeśli dane dotyczące Twojej witryny są niedostępne, raport The Mobile Economy 2019 sugeruje, że dobrym globalnym punktem odniesienia jest telefon z Androidem ze średniej półki, np. Moto G4, i wolna sieć 3G (definiowana jako 400 ms RTT i szybkość transferu 400 kb/s). Ta kombinacja jest dostępna na stronie WebPageTest.
Pamiętaj, że chociaż urządzenie typowego użytkownika mobilnego może twierdzić, że jest połączone z siecią 2G, 3G lub 4G, w rzeczywistości efektywna szybkość połączenia jest często znacznie mniejsza z powodu utraty pakietów i różnic w sieci.
Nie musisz wczytywać wszystkiego w ciągu 5 sekund, aby wywołać wrażenie pełnego wczytania. Rozważ leniwe ładowanie obrazów, dzielenie kodu 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 strony lub jej działania. Aby zapoznać się z interfejsem panelu Wydajność, przeczytaj artykuł Analizowanie wydajności środowiska wykonawczego.
Szczególnie przydatne są te funkcje Narzędzi deweloperskich:
Ogranicz wydajność procesora, aby zasymulować mniej wydajne urządzenie.
Ogranicz wykorzystanie sieci, aby symulować wolniejsze połączenia.
Wyświetl aktywność w głównym wątku, aby zobaczyć wszystkie zdarzenia, które wystąpiły w głównym wątku podczas nagrywania.
Wyświetl aktywności w głównym wątku w tabeli, aby posortować je według czasu, jaki zajęły.
Analizuj liczbę klatek na sekundę (FPS), aby sprawdzić, czy animacje działają płynnie.
Monitoruj wykorzystanie procesora, rozmiar stosu JS, węzły DOM, układy na sekundę i inne parametry w czasie rzeczywistym za pomocą Monitora wydajności.
Wizualizuj żądania sieciowe, które wystąpiły podczas nagrywania, za pomocą sekcji Sieć.
Rób zrzuty ekranu podczas nagrywania, aby dokładnie odtworzyć wygląd strony podczas jej wczytywania, uruchamiania animacji itp.
Wyświetlaj interakcje, aby szybko sprawdzić, co się stało na stronie po interakcji użytkownika.
Znajduj problemy z wydajnością przewijania w czasie rzeczywistym, podświetlając stronę za każdym razem, gdy uruchamia się potencjalnie problematyczny detektor.
Wyświetlaj zdarzenia renderowania w czasie rzeczywistym, aby identyfikować kosztowne zdarzenia renderowania, które mogą negatywnie wpływać na wydajność animacji.
Latarnia morska
Lighthouse jest dostępny 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 ze średniej półki z wolnym połączeniem 3G, przeprowadza serię kontroli strony, a następnie generuje raport o wydajności ładowania oraz sugestie dotyczące ulepszeń.
Szczególnie istotne są te audyty:
Odpowiedź
Maksymalne potencjalne opóźnienie przy pierwszym działaniu. Szacuje, ile czasu zajmie aplikacji odpowiedź na dane wejściowe użytkownika, na podstawie czasu bezczynności głównego wątku.
Nie używa pasywnych detektorów do poprawy wydajności przewijania.
Łączny czas blokowania. Mierzy łączny czas, przez który strona nie reaguje na działania użytkownika, takie jak kliknięcia myszą, dotknięcia ekranu czy naciśnięcia klawiszy.
Czas do pełnej interaktywności. Mierzy, kiedy użytkownik może stale wchodzić w interakcje ze wszystkimi elementami strony.
Wczytywanie
Nie rejestruje skryptu service worker, który kontroluje stronę i start_url. Skrypt service worker może zapisywać w pamięci podręcznej typowe zasoby na urządzeniu użytkownika, co skraca czas pobierania zasobów przez sieć.
Wczytanie strony nie jest wystarczająco szybkie w sieciach komórkowych.
Opóźnij wyświetlanie obrazów poza ekranem. Odłóż ł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 ilość danych przesyłanych w sieci, dostarczają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 używa prawdziwych przeglądarek do uzyskiwania dostępu do stron internetowych i zbierania danych o czasie. Wpisz adres URL na stronie webpagetest.org/easy, aby uzyskać szczegółowy raport o wydajności ładowania strony na rzeczywistym urządzeniu Moto G4 z wolnym połączeniem 3G. Możesz też skonfigurować go tak, aby uwzględniał kontrolę Lighthouse.
Podsumowanie
RAIL to sposób patrzenia na wrażenia użytkownika witryny jako na podróż składającą się z różnych interakcji. Dowiedz się, jak użytkownicy postrzegają Twoją witrynę, aby wyznaczyć cele skuteczności, które będą miały największy wpływ na wrażenia użytkowników.
Liczą się użytkownicy
Odpowiadaj na dane wejściowe użytkownika w czasie krótszym niż 100 ms.
Podczas animowania lub przewijania wygeneruj klatkę w czasie krótszym niż 10 ms.
Maksymalizuj czas bezczynności wątku głównego.
Wczytywanie treści interaktywnych w czasie krótszym niż 5000 ms.