Słyszeliśmy, jak ważna jest skuteczność. Co jednak w tym przypadku mamy na myśli, gdy mówimy o skuteczności i tworzeniu „szybkich” stron internetowych?
Prawda jest taka, że skuteczność jest względna:
- Strona może być szybka dla jednego użytkownika (w szybkiej sieci z mocnym urządzeniem), ale wolna u innego (w powolnej sieci na słabszych urządzeniach).
- Dwie witryny mogą ładować się w tym samym czasie, ale jedna może wyglądać na szybsze ładowanie (jeśli treści wczytują się stopniowo, zamiast czekać, aż coś się wyświetli).
- Strona może się wydawać, że wczytuje się szybko, ale potem reaguje wolniej (lub wcale) nie reaguje na interakcje użytkowników.
Gdy mówimy o skuteczności, należy być precyzyjna i kontynuować ją w kontekście metrics. Obiektywne kryteria, które można zmierzyć ilościowo, ale ważne jest też, aby mierzone dane były przydatne.
Definiowanie danych
Do tej pory skuteczność w witrynie była mierzona za pomocą zdarzenia load. Mimo że load jest dobrze zdefiniowanym momentem w cyklu życia strony, niekoniecznie musi on odpowiadać nic, co jest dla użytkownika istotne.
Na przykład w odpowiedzi serwer może wyświetlić stronę z minimalną ilością danych, która „wczytuje się” natychmiast, a potem opóźni pobranie lub wyświetlenie treści na stronie do kilku sekund po wywołaniu zdarzenia load. Z technicznego punktu widzenia taka strona wczytuje się szybko, ale nie ma to związku z wrażeniami użytkownika.
W ciągu ostatnich kilku lat członkowie zespołu Chrome – we współpracy z grupą roboczą W3C Web Performance Groups – pracowali nad ustandaryzowaniem zestawu nowych interfejsów API i danych, które dokładniej mierzą wydajność strony internetowej przez użytkowników.
Aby zapewnić, że dane są odpowiednie dla użytkowników, zadajemy im kilka kluczowych pytań:
| Czy tak jest? | Czy nawigacja rozpoczęła się pomyślnie? Czy serwer odpowiedział? |
| Czy jest przydatna? | Czy masz wystarczającą liczbę wyrenderowanych treści, aby użytkownicy mogli z nich korzystać? |
| Czy program jest przydatny? | Czy użytkownicy mogą korzystać ze strony czy jest ona zajęta? |
| Czy podoba Ci się to? | Czy interakcje są płynne, naturalne i wolne od opóźnień? |
Jak mierzone są dane
Dane o skuteczności są zwykle mierzone na 2 sposoby:
- W module: korzystanie z narzędzi do symulacji wczytywania strony w spójnym, kontrolowanym środowisku.
- W polach: rzeczywisty użytkownik, który wczytuje stronę i z niej korzysta.
Żadna z tych opcji nie musi być lepsza czy gorsza od drugiej – tak naprawdę warto korzystać z obu, by uzyskać wysoką skuteczność.
W laboratorium
Testowanie wydajności w laboratorium jest kluczowe przy tworzeniu nowych funkcji. Przed udostępnieniem funkcji w wersji produkcyjnej nie da się zmierzyć ich charakterystyki wydajności na rzeczywistych użytkownikach, dlatego najlepszym sposobem zapobiegania spadkom wydajności jest przetestowanie ich w laboratorium przed udostępnieniem tej funkcji.
W terenie
Z drugiej strony, choć testowanie w laboratorium stanowi rozsądny wskaźnik wydajności, niekoniecznie musi odzwierciedlać faktyczne wrażenia użytkowników.
Wydajność witryny może się znacznie różnić w zależności od możliwości urządzenia użytkownika i stanu sieci. Może też się różnić w zależności od tego, czy (lub w jaki sposób) użytkownik wchodzi w interakcję ze stroną.
Wczytania stron nie zawsze też są deterministyczne. Na przykład witryny, które wczytują spersonalizowane treści lub reklamy, mogą mieć bardzo różne parametry wydajności w zależności od użytkownika. Testy laboratoryjne nie pokażą tych różnic.
Jedynym sposobem na poznanie rzeczywistej skuteczności witryny dla użytkowników jest mierzenie jej skuteczności w miarę wczytywania i korzystania z niej przez użytkowników. Ten typ pomiaru jest zwykle nazywany monitorowaniem rzeczywistych użytkowników (RUM).
Typy danych
Istnieje kilka innych rodzajów danych, które mają wpływ na postrzeganie skuteczności przez użytkowników.
- Orientacyjna szybkość wczytywania: jak szybko strona może wczytać się i wyrenderować na ekranie wszystkie jej elementy wizualne.
- Responsywność ładowania: jak szybko strona może wczytać i wykonać dowolny wymagany kod JavaScript, by komponenty szybko reagowały na interakcję użytkownika
- Reagowanie w czasie działania: jak szybko po wczytaniu strony może ona reagować na interakcję użytkownika.
- Stabilność wizualna: czy elementy na stronie przesuwają się w nieoczekiwany sposób i mogą zakłócać ich działanie?
- Płynność: czy przejścia i animacje są renderowane ze stałą liczbą klatek i płynnie przechodzą od jednego stanu do drugiego?
Biorąc pod uwagę wszystkie rodzaje danych o skuteczności, jest jasne, że żaden z nich nie jest wystarczający do uchwycenia wszystkich cech wydajności strony.
Ważne dane do pomiaru
- Pierwsze wyrenderowanie treści (FCP):mierzy czas od momentu rozpoczęcia wczytywania strony do wyrenderowania dowolnej części treści strony na ekranie. (lab, pole)
- Największe wyrenderowanie treści (LCP): mierzy czas od momentu rozpoczęcia wczytywania strony do wyrenderowania największego bloku tekstowego lub elementu graficznego na ekranie. (lab, pole)
- Interakcja do następnego wyrenderowania (INP): mierzy czas oczekiwania na każde kliknięcie, kliknięcie lub interakcję ze stroną za pomocą klawiatury i na podstawie liczby interakcji wybiera najdłuższy czas oczekiwania na interakcję ze stroną (lub bliski najwyższego) jako pojedynczą, reprezentatywną wartość określającą ogólną responsywność strony. (lab, pole)
- Całkowity czas blokowania (TBT): mierzy łączny czas między FCP a TTI, w którym wątek główny był zablokowany na wystarczająco długo, aby uniemożliwić reagowanie na dane wejściowe. (laboratorium)
- Skumulowane przesunięcie układu (CLS): pokazuje łączny wynik wszystkich nieoczekiwanych przesunięć układu, które występują między rozpoczęciem wczytywania strony a jej stanem cyklu życia zmienionym na „ukryta”. (lab, pole)
- Czas do pierwszego bajtu (TTFB): mierzy czas potrzebny sieci na odpowiedź na żądanie użytkownika z pierwszym bajtem zasobu. (lab, pole)
W niektórych przypadkach wprowadzimy nowe dane, aby uwzględnić brakujące obszary. W innych przypadkach najlepsze dane to te dostosowane do Twojej witryny.
Dane niestandardowe
Omówione wcześniej dane o skuteczności pozwalają poznać ogólne cechy skuteczności większości stron internetowych. Takie rozwiązanie jest też przydatne, gdy ma wspólny zestaw danych, dzięki którym witryny mogą porównywać swoją skuteczność z konkurencją.
Czasem jednak konkretna witryna jest wyjątkowa i wymaga dodatkowych danych, aby w pełni poznać jej skuteczność. Na przykład wskaźnik LCP służy do pomiaru, kiedy główna treść strony dobiega końca. Zdarzają się jednak sytuacje, w których największy element nie jest częścią głównej treści strony, w związku z czym LCP może być nieistotny.
Z myślą o takich przypadkach zespół ds. wydajności witryn ujednoliciliśmy także interfejsy API niższego poziomu, które mogą być przydatne przy implementowaniu własnych danych niestandardowych:
- User Timing API
- Interfejs Long Tasks API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- Czas serwera
Aby dowiedzieć się, jak używać tych interfejsów API do pomiaru charakterystyki wydajności w Twojej witrynie, zapoznaj się z przewodnikiem po danych niestandardowych.