Lighthouse niestabilny? Zmierz najpierw, ile z wyniku nie jest Twoje

👁 116 przeczytań

Ten sam adres, ten sam commit, żadna linia kodu nie ruszona - a wyniki Lighthouse od 60 do 96 punktów. Po zablokowaniu domen reklamowych i skryptu zgód wynik ustabilizował się na 77/77, rozrzut FCP spadł z 22% do 0,7%, a TBT zjechał do zera. Łącznie 121 pomiarów w dziewięciu seriach, żeby ustalić jedną rzecz: gdzie kończy się moja strona, a zaczyna cudzy JavaScript.

Dlaczego Lighthouse niestabilny to najczęściej nie wina Lighthouse

Zacząłem od założenia, że mam problem z metodologią. Sprawdziłem wszystko, co zwykle się sprawdza: te same warunki sieciowe, ten sam profil, przerwy między przebiegami, brak innych procesów obciążających procesor. Rozrzut się nie zmniejszył. Dolny wynik 60, górny 96, i praktycznie każda wartość pomiędzy.

Przełom przyszedł, kiedy przestałem traktować stronę jako jedną całość. Strona z reklamami to nie jeden dokument - to dokument plus aukcja, która rozgrywa się w czasie ładowania. Każdy przebieg to inna kreacja, inny zestaw pixeli, inna liczba zadań wrzuconych do wątku głównego. Narzędzie mierzy poprawnie. Po prostu mierzy coś, co za każdym razem jest inne.

Stąd prosty wniosek dla każdego, kto walczy z pagespeed różne wyniki: przestań szukać błędu w narzędziu i policz, ile z pomiaru pochodzi z zewnątrz.

Jak wyglądał pomiar

Dziewięć serii, łącznie 121 pomiarów tego samego adresu. Serie dzieliły się na dwie grupy: z pełnym stosem zewnętrznym i z zablokowanymi domenami reklamowymi oraz domeną dostawcy zgód. Blokowałem na poziomie sieci, nie przez wyłączanie skryptów w kodzie - chciałem, żeby strona próbowała je zaciągnąć i nie dostała odpowiedzi. To bardziej przypomina realną sytuację użytkownika z blokerem niż sztuczne usunięcie tagów.

Interesowały mnie trzy rzeczy: sam wynik punktowy, rozrzut First Contentful Paint między przebiegami w serii i Total Blocking Time. FCP wybrałem, bo to metryka, która teoretycznie nie powinna zależeć od reklam - render pierwszej treści dzieje się przecież wcześniej. Teoria nie wytrzymała.

Przed i po odcięciu skryptów trzecich stron

Najważniejsza liczba w tej tabeli to nie 77, a 0,7%. Rozrzut FCP na poziomie 22% oznacza, że nie da się odpowiedzialnie powiedzieć, czy jakakolwiek zmiana w kodzie pomogła - efekt typowej mikrooptymalizacji ginie w szumie. Przy 0,7% widzę każdą poprawkę rzędu kilkudziesięciu milisekund.

Druga rzecz: TBT spadł do zera. Nie do niskiej wartości - do zera. Cały czas blokowania wątku głównego na tej stronie pochodził z zewnątrz. Mój własny JavaScript nie wnosił do tej metryki nic.

Core web vitals reklamy: 445-467 KB, których nie kontrolujesz

Waga stosu zewnętrznego wahała się między 445 i 467 KB w zależności od przebiegu. To nie jest liczba, którą możesz zoptymalizować - możesz ją tylko zaakceptować albo usunąć. Zakres 22 KB między minimum a maksimum to zmienność samej aukcji: raz przyjdzie cięższa kreacja, raz lżejsza, raz dodatkowy pixel.

Konsekwencja praktyczna jest taka, że planując budżet wydajnościowy musisz liczyć od dołu, nie od góry. Jeśli 445 KB i całe TBT jest poza Twoim zasięgiem, to Twój realny sufit to 77 punktów - i każda rozmowa o „dojdziemy do 90” jest rozmową o usunięciu czegoś z tego stosu, a nie o Twoim kodzie.

To jest moja opinia, ale mocna: wynik 96, który zobaczyłem w jednym z przebiegów z reklamami, jest bardziej mylący niż wynik 60. Ten 60 przynajmniej nie daje fałszywego poczucia, że wszystko jest w porządku.

Co z tego wynika dla kolejności prac

Zmiana, która u mnie wynikła z tych 121 pomiarów, dotyczy kolejności, nie samych technik. Wcześniej zaczynałem od obrazków, fontów i critical CSS, bo to jest to, co zwykle widać na liście rekomendacji. Teraz zaczynam od podziału: ile punktów to ja, ile punktów to nie ja.

Jeśli wynik po odcięciu skryptów trzecich jest wysoki, a z nimi niski, to rozmowa nie jest techniczna - jest biznesowa. Dotyczy tego, ile zapytań reklamowych odpalamy, czy baner zgód musi blokować render i czy każdy pixel analityczny naprawdę jest potrzebny. Żaden lazy loading obrazków tego nie naprawi.

Jeśli natomiast wynik po odcięciu też jest niski - masz czysty sygnał i wiesz, że pracujesz nad własnym kodem. To dwie zupełnie różne ścieżki i szkoda tygodni na tę niewłaściwą.

Jak to sprawdzić u siebie

1. Wybierz jeden adres, który realnie generuje ruch i ma pełny stos reklamowy. Nie stronę główną, jeśli jest inna technicznie od podstron treściowych.
2. Wykonaj pierwszą serię pomiarów bez żadnych blokad. Minimum dziesięć przebiegów - przy jednym czy dwóch nie zobaczysz rozrzutu, tylko trafisz w losowy punkt.
3. Zapisz dla każdego przebiegu trzy wartości: wynik punktowy, FCP i TBT. Bez FCP nie policzysz rozrzutu, a rozrzut jest tu ważniejszy niż średni wynik.
4. Policz rozrzut FCP jako procent różnicy między najwyższą i najniższą wartością w serii. Powyżej kilku procent oznacza, że pojedynczy pomiar nie ma wartości diagnostycznej.
5. Zablokuj domeny reklamowe i domenę dostawcy zgód na poziomie sieci. Nie usuwaj tagów z kodu - chcesz zobaczyć, jak strona zachowuje się, gdy żądania nie dostaną odpowiedzi.
6. Powtórz serię w identycznych warunkach, ta sama liczba przebiegów. Porównaj rozrzut, nie tylko średni wynik.
7. Odczytaj z zakładki sieciowej sumaryczną wagę zasobów z domen zewnętrznych. Sprawdź ją w kilku przebiegach - u mnie wahała się o 22 KB, u Ciebie może bardziej.
8. Ustaw wynik z zablokowanym stosem jako swój realny punkt odniesienia. Każdą kolejną optymalizację porównuj do niego, nie do wyniku z reklamami.
9. Różnicę między wynikiem czystym i pełnym zanieść do rozmowy o monetyzacji. To tam się rozstrzyga, nie w repozytorium.