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 będzie działać szybciej, jeśli będzie ładować się stopniowo, zamiast czekać, aż wszystko będzie w porządku.
- Strona może się szybko ładować, ale z powodu wolniejszego reakcji lub wcale jej nie reaguje.
Mówiąc o wynikach, należy zachować precyzję i odnosić się do metrics, czyli obiektywnych kryteriów, które można mierzyć ilościowo. Trzeba jednak pamiętać, że wskaźniki, które mierzysz, są przydatne.
Wskaźniki
W przeszłości skuteczność w internecie 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 zaproponować minimalną stronę, która „ładuje się” od razu, a potem opóźnia pobieranie treści lub wyświetlanie jakichkolwiek treści na stronie do kilku sekund po uruchomieniu zdarzenia load. W praktyce taka strona ma krótki czas wczytywania, ale ten czas nie odpowiada temu, jak strona wczytuje się u użytkownika.
W ciągu ostatnich kilku lat członkowie zespołu Chrome, we współpracy z W3C Web Performance Reporting Group, pracowali nad ustandaryzacją 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. Aby zapewnić dobrą skuteczność, warto używać ich obu.
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 są rozsądnym wskaźnikiem wydajności, ale niekoniecznie odzwierciedlają wrażenia wszystkich użytkowników witryny.
Wydajność witryny może się znacznie różnić w zależności od możliwości urządzenia użytkownika i warunków sieciowych. Może się też zmieniać w zależności od tego, czy (lub jak) użytkownik wchodzi w interakcję z daną stroną.
Wczytywanie strony nie zawsze ma charakter deterministyczny. 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 uwzględni tych różnic.
Jedynym sposobem na określenie rzeczywistej wydajności witryny w przypadku użytkowników jest rzeczywiste zmierzenie jej wydajności podczas ładowania strony i interakcji z nią. Ten rodzaj pomiarów nosi nazwę Real User Monitoring (RUM).
Rodzaje danych
Istnieje kilka innych rodzajów danych wpływających na to, 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ć kod JavaScript niezbędny do szybkiego reagowania przez komponenty na interakcję użytkownika.
- Reagowanie w czasie działania: jak szybko po załadowaniu strony strona może reagować na interakcję użytkownika.
- Stabilność wizualna: czy elementy na stronie przesuwają się w sposób, którego nie spodziewają się użytkownicy, co może 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 te rodzaje danych o wydajności, można by się spodziewać, że żaden 1 wskaźnik nie wystarcza do uchwycenia wszystkich parametrów wydajności strony.
Ważne dane do pomiaru
- Pierwsze wyrenderowanie treści (FCP)
- Czas od rozpoczęcia wczytywania strony do wyrenderowania dowolnej części zawartości strony na ekranie. (moduł, pole)
- Największe wyrenderowanie treści (LCP)
- Czas od rozpoczęcia wczytywania strony do wyrenderowania na ekranie największego bloku tekstu lub elementu graficznego. (moduł, pole)
- Interakcja do kolejnego wyrenderowania (INP)
- Opóźnienie każdego kliknięcia, kliknięcia lub interakcji na klawiaturze ze stroną. Na podstawie liczby interakcji ten wskaźnik wybiera najdłuższy (lub prawie do najgorszy) czas oczekiwania na interakcję ze stroną jako pojedynczą, reprezentatywną wartość, aby opisać ogólną responsywność strony. (moduł, pole)
- Całkowity czas blokowania (TBT)
- Łączny czas upływający między FCP a czasem do pełnej interaktywności (TTI), w którym wątek główny był zablokowany na tyle długo, aby uniemożliwiać odpowiadanie na dane wejściowe. (moduł)
- Skumulowane przesunięcie układu (CLS)
- Łączny wynik wszystkich nieoczekiwanych przesunięć układu, które nastąpiły od momentu rozpoczęcia wczytywania strony do momentu, gdy jej stan cyklu życia zmieni się na ukryty. (moduł, pole)
- Czas do pierwszego bajtu (TTFB)
- Czas potrzebny sieci na zareagowanie na żądanie użytkownika z pierwszym bajtem zasobu. (lab, pole)
Ta lista zawiera dane do pomiaru wielu różnych aspektów skuteczności, które są istotne dla użytkowników, ale nie zawiera wszystkich danych. Nie są brane pod uwagę np. responsywność i płynność działania środowiska wykonawczego.
W niektórych przypadkach wprowadzamy nowe dane, aby uwzględnić brakujące obszary, ale w innych najlepsze są dane dostosowane specjalnie do Twojej witryny.
Dane niestandardowe
Wymienione tutaj dane dotyczące skuteczności pozwalają ogólnie zrozumieć charakter skuteczności większości witryn w internecie. Są też przydatne, gdy dysponują wspólnym zestawem danych służących do porównywania skuteczności witryn z konkurencją.
Czasami jednak 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. Czasami jednak największy element nie jest częścią głównej treści strony, przez co LCP nie ma znaczenia.
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
Informacje o tym, jak za pomocą tych interfejsów API mierzyć parametry wydajności charakterystyczne dla Twojej witryny, znajdziesz w przewodniku Wskaźniki niestandardowe.