Wszyscy słyszeliśmy, jak ważna jest wydajność. Co jednak mamy na myśli, gdy mówimy o wydajności i przyspieszaniu działania witryn?
Prawda jest taka, że skuteczność jest względna:
- Strona może być szybka dla jednego użytkownika (w szybkiej sieci z wydajnym urządzeniem), ale wolna w przypadku innego użytkownika (w wolnej sieci na słabszym urządzeniu).
- Dwie witryny mogą wczytywać się w dokładnie tym samym czasie, ale jedna z nich może się szybciej ładować (jeśli treść będzie ładować się stopniowo, a nie do końca, aby coś wyświetlić).
- Strona może się wydawać szybko ładująca, a następnie powoli reagować (lub w ogóle) na interakcję użytkownika.
Dlatego gdy mówimy o wynikach, należy zachować precyzję i odnosić się do jej w oparciu o obiektywne kryteria, które można mierzyć ilościowo. Kryteria te są nazywane metrics.
Fakt, że dane opierają się na obiektywnych kryteriach i można je mierzyć ilościowo, nie musi oznaczać, że pomiary są przydatne.
Definiowanie wskaźników
Dawniej wydajność witryny była mierzona za pomocą zdarzenia load
. Mimo że load
jest dobrze zdefiniowanym momentem w cyklu życia strony, ten moment nie musi być zgodny z czymś, na czym zależy użytkownikowi.
Na przykład serwer może w odpowiedzi wyjaśnić minimalną stronę, która „ładuje się” natychmiast, a potem opóźnia pobieranie i wyświetlanie jakichkolwiek treści na stronie do kilku sekund po uruchomieniu zdarzenia load
. Mimo że taka strona może charakteryzują się krótkim czasem wczytywania, czas ten nie odpowiada temu, jak będzie przebiegać wczytywanie strony.
W ciągu ostatnich kilku lat członkowie zespołu Chrome – we współpracy z W3C Web Performance Activity Group – pracowali nad ustandaryzowaniem zestawu nowych interfejsów API i danych, które dokładniej mierzą wrażenia użytkowników związane z wydajnością strony internetowej.
Aby dane były przydatne dla użytkowników, opieramy je na kilku kluczowych pytaniach:
Czy tak się dzieje? | Czy udało się rozpocząć nawigację? Czy serwer odpowiedział? |
Czy jest przydatna? | Czy wystarczająco dużo wyrenderowanych treści, aby użytkownicy mogli z nich korzystać? |
Czy jest przydatna? | Czy użytkownicy mogą korzystać ze strony czy jest ona zajęta? |
Czy sprawia Ci przyjemność? | Czy interakcje są płynne i naturalne, bez opóźnień i zacięć? |
Mierzenie danych
Dane o skuteczności są zwykle mierzone na jeden z dwóch sposobów:
- W module: korzystanie z narzędzi do symulowania wczytywania strony w spójnym, kontrolowanym środowisku
- W terenie: na rzeczywistych użytkownikach, którzy faktycznie wczytają stronę i wchodzą z nią w interakcję
Żadna z tych opcji nie musi być lepsza ani gorsza od drugiej – zwykle warto używać obu, aby zapewnić dobrą skuteczność.
W laboratorium
Testowanie wydajności w module ma kluczowe znaczenie przy opracowywaniu nowych funkcji. Przed udostępnieniem funkcji w wersji produkcyjnej nie da się zmierzyć ich wydajności na rzeczywistych użytkownikach, dlatego przetestowanie ich w laboratorium przed udostępnieniem funkcji to najlepszy sposób na zapobieganie spadkom wydajności.
W terenie
Z drugiej strony testy w laboratorium to rozsądny wskaźnik wydajności, ale niekoniecznie odzwierciedla to, jak wszyscy użytkownicy korzystają z Twojej witryny w terenie.
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 się też zmieniać w zależności od tego, czy (lub jak) użytkownik wchodzi w interakcję ze stroną.
Ponadto liczba załadowań stron może nie być deterministyczna. Na przykład witryny wczytujące spersonalizowane treści lub reklamy mogą mieć zupełnie inne cechy skuteczności u poszczególnych użytkowników. Test laboratoryjny nie wykryje tych różnic.
Aby poznać prawdziwą wydajność witryny w przypadku użytkowników, należy zmierzyć jej wydajność podczas ładowania strony i wchodzenia z nią w interakcję. Ten typ pomiaru jest często nazywany monitorowaniem użytkowników (w skrócie RUM).
Rodzaje danych
Istnieje kilka innych typów wskaźników istotnych dla tego, jak użytkownicy postrzegają skuteczność.
- Prędkość ładowania: jak szybko strona może wczytać się i wyrenderować na ekranie wszystkie swoje elementy wizualne.
- Ładuj responsywność: jak szybko strona może wczytywać i wykonywać wymagany kod JavaScript, by komponenty mogły szybko reagować na interakcję użytkownika
- Reagowanie w czasie działania: jak szybko po wczytaniu strony może ona reagować na interakcje użytkownika.
- Stabilność wizualna: czy elementy na stronie przesuwają się w sposób, którego użytkownicy nie spodziewają się, lub mogą zakłócać ich interakcje?
- Płynność: czy przejścia i animacje renderują się ze stałą liczbą klatek i płynnie przechodzą z jednego stanu do drugiego?
Biorąc pod uwagę wszystkie powyższe rodzaje danych o wydajności, można by się spodziewać, że żaden 1 wskaźnik nie wystarczy do uchwycenia wszystkich parametrów wydajności strony.
Ważne dane do pomiaru
- Pierwsze wyrenderowanie treści (FCP): mierzy czas od rozpoczęcia ładowania strony do wyrenderowania dowolnej części treści strony na ekranie. (moduł, pole)
- Największe wyrenderowanie treści (LCP): mierzy czas od rozpoczęcia ładowania strony do wyrenderowania największego bloku tekstu lub największego elementu graficznego na ekranie. (moduł, pole)
- Opóźnienie przy pierwszym działaniu (FID): mierzy czas od pierwszej interakcji użytkownika z witryną (kiedy klika link, przycisk czy użycie niestandardowego elementu sterującego opartego na JavaScript) do czasu, w którym przeglądarka jest w stanie zareagować na tę interakcję. (pole)
- Interakcja z kolejnym wyrenderowaniem (INP): mierzy czas oczekiwania na każde kliknięcie, kliknięcie lub interakcję z klawiaturą względem strony i – w zależności od liczby interakcji – wybiera najdłuższy czas oczekiwania na interakcję na stronie (lub bliski najwyższej wartości) jako pojedynczą wartość reprezentatywną, która opisuje ogólną responsywność strony. (moduł, pole)
- Całkowity czas blokowania (TBT): mierzy łączny czas między FCP a TI, w którym wątek główny był zablokowany na tyle długo, aby uniemożliwić reagowanie na dane wejściowe. (moduł)
- Skumulowane przesunięcie układu (CLS): mierzy skumulowany wynik wszystkich nieoczekiwanych przesunięć układu, które nastąpiły między rozpoczęciem wczytywania strony a zmianą jej stanu cyklu życia na ukrytą. (moduł, pole)
- Czas do pierwszego bajtu (TTFB): mierzy czas potrzebny na odpowiedź sieci na żądanie użytkownika z pierwszym bajtem zasobu. (moduł, pole)
Ta lista zawiera dane służące do pomiaru wielu różnych aspektów skuteczności istotnych dla użytkowników, ale nie obejmuje wszystkich informacji. Obecnie nie obejmują one m.in. responsywności i płynności działania w czasie działania.
W niektórych przypadkach wprowadzamy nowe dane, aby uwzględnić brakujące obszary, ale w innych najlepiej są to dane dostosowane specjalnie do Twojej witryny.
Dane niestandardowe
Wymienione powyżej dane dotyczące skuteczności pomagają w ogólnym zrozumieniu właściwości działania większości witryn w internecie. Są też przydatne, gdy dysponują wspólnym zestawem danych, które pozwalają porównywać witryny o skuteczności z konkurencją.
Może się jednak zdarzyć, że konkretna witryna jest niepowtarzalna i wymaga dodatkowych danych, aby uzyskać pełny obraz jej skuteczności. Na przykład wskaźnik LCP służy do pomiaru zakończenia wczytywania głównej treści strony. Jednak w niektórych przypadkach największy element nie jest częścią głównej treści strony, więc wartość LCP może być nieistotna.
Aby stawić czoła takim przypadkom, grupa robocza ds. wydajności w internecie opracowała też ustandaryzowane interfejsy API niższego poziomu, które mogą być przydatne przy implementowaniu własnych danych niestandardowych:
- Interfejs User Timing API
- Long Tasks API
- Interfejs Element Timing API
- Nawigacja Timing API
- Interfejs Resource Timing API
- Czas serwera
W przewodniku po niestandardowych danych znajdziesz informacje o tym, jak używać tych interfejsów API do pomiaru charakterystyki skuteczności w Twojej witrynie.