Dwa pomiary, dwa różne pytania

Czas do pierwszego bajtu jest pomiarem sieciowo-serwerowym. Kończy się w momencie, w którym przeglądarka dostaje początek odpowiedzi z dokumentem. Nie mówi nic o tym, co dalej: czy dokument jest duży, czy wymaga dodatkowych plików, czy przeglądarka zdoła coś wyświetlić.

Największe wyrenderowanie treści to pomiar percepcyjny. Przeglądarka obserwuje, jak strona się rysuje, i wskazuje moment, w którym pojawił się największy element widoczny w oknie — najczęściej obrazek główny, blok tekstu albo nagłówek z tłem. Interesuje ją wyłącznie to, co widzi użytkownik nad linią zgięcia, i to w największym rozmiarze.

Konsekwencja arytmetyczna jest oczywista, ale rzadko wypowiadana wprost: LCP nigdy nie będzie lepsze od TTFB. Jeśli serwer zaczyna odpowiadać po sekundzie i ośmiu dziesiątych, żaden zabieg po stronie obrazków nie zejdzie z LCP poniżej tej wartości. To jest podstawa całej strategii napraw.

Dochodzi do tego różnica statusu. LCP jest jednym z podstawowych wskaźników internetowych, branym pod uwagę w ocenie doświadczenia na stronie. TTFB nie jest wskaźnikiem podstawowym — pełni funkcję pomocniczą, diagnostyczną, i służy do wyjaśniania wyniku LCP, a nie do samodzielnej oceny.

Z czego składa się LCP

Najbardziej praktyczny sposób pracy z tym wskaźnikiem polega na rozłożeniu go na cztery kolejne odcinki czasu. Kiedy raz się je zobaczy, przestaje się zgadywać.

• Czas do pierwszego bajtu — wszystko, co dzieje się zanim przeglądarka zobaczy dokument: przekierowania, połączenie, praca serwera.

• Opóźnienie wczytania zasobu — odcinek między odebraniem dokumentu a momentem, w którym przeglądarka zaczyna pobierać element odpowiadający za LCP. Tutaj mieszczą się pliki blokujące renderowanie, odkrywanie obrazka dopiero po wykonaniu skryptu i leniwe wczytywanie zastosowane w złym miejscu.

• Czas wczytania zasobu — samo pobieranie obrazka lub czcionki. Zależy od wagi pliku, formatu i sposobu jego dostarczenia.

• Opóźnienie renderowania — czas między pobraniem elementu a jego pojawieniem się na ekranie. Rośnie, gdy główny wątek przeglądarki jest zajęty wykonywaniem skryptów albo gdy treść czeka na dane pobierane po wczytaniu strony.

Ten podział rozstrzyga spór o odpowiedzialność szybciej niż jakakolwiek dyskusja. Jeżeli pierwszy odcinek to trzysta milisekund, a całość dwie sekundy i osiemset, serwer nie jest problemem, nawet jeśli tak brzmi pierwsza hipoteza wszystkich zainteresowanych.

Progi oceny i to, co one naprawdę znaczą

Dla LCP przyjęte granice to dwie i pół sekundy dla wyniku dobrego oraz cztery sekundy jako początek wyniku złego. Między tymi wartościami mieści się przedział „wymaga poprawy”. Dla czasu odpowiedzi serwera powszechnie stosowanym punktem odniesienia jest osiemset milisekund dla dobrego rezultatu.

Trzy uwagi, bez których te liczby wprowadzają w błąd.

Po pierwsze, wynik ocenia się na siedemdziesiątym piątym centylu odsłon, czyli patrzymy na doświadczenie trzech czwartych wizyt, a nie na średnią. Średnia potrafi ukryć dużą grupę użytkowników z bardzo słabym wynikiem, bo równoważą ją odsłony z bufora.

Po drugie, urządzenia mobilne i komputery ocenia się osobno i różnica między nimi bywa dwukrotna. Raport, w którym nie wiadomo, którego segmentu dotyczy liczba, nie nadaje się do podejmowania decyzji.

Po trzecie, ocena dotyczy adresów zgrupowanych w zbiory podobnych stron, a nie każdej podstrony osobno. Dlatego karta produktu może być technicznie w porządku, a raport pokazywać problem, bo do tej samej grupy trafiają wyniki wyszukiwania w sklepie.

Dobry TTFB, złe LCP — i odwrotnie

Najczęstszy układ, z jakim się spotykam, to solidny czas odpowiedzi serwera i słabe LCP. Przyczyny są niemal zawsze te same.

Obrazek główny w rozmiarze przeznaczonym do druku, skalowany przez przeglądarkę. Karuzela na starcie strony, która zaczyna wczytywać pierwszy slajd po zainicjowaniu skryptu. Leniwe wczytywanie założone hurtowo na wszystkie obrazki, w tym na ten najważniejszy, widoczny od razu. Czcionka pobierana z zewnętrznego serwera, przez którą tekst czeka na wyświetlenie. Baner zgód, który zasłania i opóźnia treść. Wreszcie treść budowana w przeglądarce po pobraniu danych z interfejsu programowego — wtedy serwer odpowiada natychmiast, tylko odpowiada niemal pustym dokumentem.

Układ odwrotny, czyli złe TTFB i dobre LCP, jest z definicji niemożliwy w sensie bezwzględnym, bo pierwszy pomiar zawiera się w drugim. Zdarza się natomiast jego pozorna wersja: pomiar laboratoryjny robiony na rozgrzanym buforze pokazuje szybki serwer, a dane od użytkowników mówią co innego, bo w rzeczywistości spora część odsłon trafia na generowanie strony od zera. To najczęstsze źródło rozmowy, w której dwie osoby mają rację, patrząc na dwa różne pomiary.

Dane laboratoryjne a dane z pola

Rozdział, którego pominięcie kosztuje najwięcej czasu w audytach.

Pomiar laboratoryjny to symulacja: jedno urządzenie, jedno łącze, jedno wczytanie w kontrolowanych warunkach. Nadaje się do szukania przyczyn i sprawdzania, czy poprawka zadziałała, bo jest powtarzalny. Nie nadaje się do stwierdzenia, czy Twoi użytkownicy mają problem, bo nie zna ich urządzeń, sieci ani zachowania.

Pomiar z pola pochodzi od realnych odwiedzających. Ma odwrotne właściwości: mówi, jak jest naprawdę, ale nie mówi dlaczego, i reaguje z opóźnieniem, bo agreguje dane z okresu liczonego w tygodniach. Dlatego po wdrożeniu poprawki nie warto codziennie odświeżać raportu w oczekiwaniu na zmianę.

Ja pracuję tak: stan faktyczny ustalam z danych od użytkowników, przyczynę szukam w narzędziach laboratoryjnych i w rozbiciu LCP na cztery odcinki, a skutek weryfikuję ponownie w danych z pola po kilku tygodniach. Do bieżącej kontroli używam pomiaru wbudowanego we własną stronę, bo daje wynik z tego samego dnia i pozwala patrzeć na konkretne szablony, nie na grupy adresów.

Kolejność napraw, gdy oba wskaźniki są słabe

Tu wracamy do arytmetyki z początku tekstu, bo ona wyznacza plan.

Zaczynam zawsze od czasu odpowiedzi serwera, jeśli przekracza akceptowalny poziom. Nie z sympatii do infrastruktury, ale ponieważ ten odcinek jest podłogą, poniżej której LCP nie zejdzie. Optymalizowanie obrazków przy dwusekundowym TTFB to poprawianie części, która nie decyduje o wyniku.

Kiedy pierwszy odcinek jest w porządku, przechodzę do opóźnienia wczytania zasobu — czyli do tego, jak szybko przeglądarka dowiaduje się o istnieniu najważniejszego elementu. To zwykle najtańsze poprawki o największym efekcie: wskazanie priorytetu dla obrazka głównego, wyłączenie leniwego wczytywania dla treści widocznej od razu, przeniesienie plików blokujących renderowanie, ograniczenie zewnętrznych zasobów w nagłówku dokumentu.

Dopiero potem zajmuję się wagą samego zasobu: format obrazu, wymiary dopasowane do rzeczywistego rozmiaru wyświetlania, kompresja. Na końcu zostaje opóźnienie renderowania, które najczęściej oznacza rozmowę o skryptach zewnętrznych i o tym, ile narzędzi analitycznych oraz marketingowych wykonuje się przed pokazaniem treści.

Jak o tym rozmawiać z działem technicznym

Ostatnia rzecz jest komunikacyjna, ale decyduje o tym, czy poprawki w ogóle powstaną.

Zgłoszenie „strona jest wolna, popraw LCP” jest bezużyteczne i zwykle wraca z odpowiedzią, że serwer ma niskie obciążenie. Zgłoszenie skuteczne wygląda inaczej: podaje konkretny szablon strony, segment urządzeń, wynik z danych od użytkowników, rozbicie na cztery odcinki i wskazanie, który z nich odpowiada za większość czasu. Do tego element zidentyfikowany jako największy oraz jedna rzecz do wykonania.

W tej rozmowie warto też wyraźnie rozdzielić odpowiedzialności, bo to skraca dyskusję. Za czas odpowiedzi serwera odpowiada zespół utrzymania i architektura aplikacji. Za opóźnienie wczytania zasobu i za wagę obrazków odpowiada w dużej mierze warstwa szablonu i redakcja. Za opóźnienie renderowania — ten, kto decyduje o liczbie skryptów wpuszczanych na stronę, a to zwykle marketing, czyli my.

Ostatnie zdanie mówię z pełną świadomością, bo w audytach regularnie znajduję sytuację, w której dział techniczny zrobił swoją część, a wskaźnik nadal jest zły przez narzędzia dołożone od strony marketingowej. Rozdzielenie TTFB i LCP pozwala to pokazać na liczbach, zamiast szukać winnego.