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.