Dwa pomiary, dwa różne pytania
Lighthouse uruchamia stronę w określonych warunkach testowych i zapisuje przebieg jednego wczytania. Pozwala zajrzeć w szczegóły: zobaczyć zasoby opóźniające wyświetlenie treści, koszt skryptów czy przesunięcia układu. Wynik punktowy jest użytecznym skrótem, ale nie opisuje wszystkich wizyt w serwisie. Może się zmienić między uruchomieniami, nawet gdy nie wdrożono nowej wersji strony.
Dane rzeczywistych użytkowników, nazywane danymi terenowymi, pochodzą z wizyt odbywających się na różnych urządzeniach, w różnych sieciach i warunkach. Zwykle są prezentowane jako zagregowany obraz pewnego okresu, a nie wynik ostatniego wejścia na stronę. Mogą obejmować wiele odmian tego samego widoku: na przykład kartę produktu z innymi zdjęciami, opiniami lub elementami promocyjnymi.
Dlatego pytanie nie powinno brzmieć: „Który wynik jest prawdziwy?”. Oba mogą być poprawne w swoim kontekście. Lighthouse pomaga ustalić, co dzieje się podczas kontrolowanego testu; dane terenowe pomagają ocenić, czego doświadczają odwiedzający. Rozbieżność jest wskazówką do dalszej diagnostyki, a nie dowodem błędu w którymś narzędziu.
Najpierw upewnij się, że porównujesz to samo
Przed interpretacją liczb sprawdź zakres pomiaru. Czy raport terenowy dotyczy konkretnego adresu, czy całej domeny? Czy zestawiasz wyniki mobilne z mobilnymi? Czy test Lighthouse przeprowadzono na stronie dostępnej bez logowania i w takiej wersji, jaką widzi większość odwiedzających? Gdy brakuje wystarczających danych dla jednego adresu, narzędzie może pokazywać szerszy zakres albo nie pokazać wyniku terenowego wcale.
Znaczenie ma również czas. Test laboratoryjny opisuje chwilę jego wykonania, natomiast zagregowane dane użytkowników mogą jeszcze zawierać wizyty sprzed poprawki. Po wdrożeniu zmiany nie oczekuj więc, że oba widoki od razu się zrównają. Zanotuj datę wdrożenia i porównuj kolejne okresy, zamiast oceniać efekt na podstawie jednego odświeżenia raportu.
Sprawdź też, co dokładnie oznacza każda metryka. LCP dotyczy wyświetlenia głównego elementu treści, CLS — nieoczekiwanych przesunięć układu, a INP — reakcji na interakcje. Lighthouse może wskazywać Total Blocking Time jako laboratoryjną wskazówkę dotyczącą zajętości głównego wątku, lecz nie jest to pomiar INP wykonany podczas rzeczywistych interakcji. Porównuj odpowiadające sobie sygnały, nie samą ocenę punktową z pojedynczą metryką terenową.
Skąd bierze się dobry Lighthouse i słabe dane terenowe?
Wyobraź sobie sklep, którego karta produktu szybko ładuje się w teście, ale odwiedzający zgłaszają opóźnienia po dotknięciu przycisku wyboru wariantu. Lighthouse nie musi wykonać tej interakcji w sposób odzwierciedlający typową wizytę. Problem może ujawniać się dopiero po uruchomieniu dodatkowych skryptów, otwarciu panelu lub dłuższym korzystaniu ze strony. Wtedy warto sprawdzić przebieg konkretnych interakcji, a nie powtarzać wyłącznie test wczytywania.
Różnicę może też tworzyć profil odwiedzających: wolniejsze telefony, niestabilne połączenia, odległość od serwera albo duży udział pierwszych wizyt bez danych w pamięci podręcznej. Znaczenie mają elementy zależne od sytuacji, takie jak narzędzia zewnętrzne, baner zgody czy cięższe obrazy przy niektórych produktach. Kontrolowany test jednej karty może ich nie uchwycić.
Działanie diagnostyczne: wybierz kilka reprezentatywnych adresów i scenariuszy, a następnie sprawdź, czy problem powtarza się na określonych typach urządzeń lub podstron. Jeśli masz własny pomiar doświadczeń użytkowników, analizuj go z poszanowaniem prywatności i z podziałem na istotne grupy. Średnia dla całego serwisu może ukrywać trudności dotyczące jednego szablonu.
A co, gdy Lighthouse wypada słabo, a użytkownicy dobrze?
Pojedynczy test może trafić na chwilowe opóźnienie serwera, wolniejszą odpowiedź zasobu zewnętrznego albo mniej korzystny przebieg ładowania. Warunki testowe mogą też być trudniejsze niż warunki dużej części rzeczywistych wizyt. Najpierw powtórz pomiar kilka razy przy tych samych ustawieniach i sprawdź, czy słaby wynik jest stały. Zamiast skupiać się na punktach, obejrzyj szczegóły przebiegu i ustal, które elementy powodują opóźnienie.
Dobry wynik terenowy nie oznacza jednak, że ostrzeżenie laboratoryjne można zignorować. Dane zbiorcze mogą nie pokazywać doświadczeń niewielkiej grupy użytkowników albo nowego problemu, który pojawił się niedawno. Jeżeli Lighthouse regularnie wskazuje duży obraz opóźniający LCP lub skrypt zajmujący główny wątek, potraktuj to jako hipotezę do sprawdzenia na odpowiednich podstronach.
Prosta kolejność diagnozy
Zacznij od zapisania adresu, typu strony, urządzenia, źródła danych i czasu pomiaru. Następnie porównaj zakres raportów oraz metrykę, której dotyczy różnica. Powtórz test laboratoryjny w porównywalnych warunkach i sprawdź, czy odchylenie występuje stale. Osobno obejrzyj typowe scenariusze użytkownika: wejście z wyszukiwarki, przewijanie, wybór opcji lub wysłanie formularza.
Na koniec zapisz najbardziej prawdopodobną przyczynę i jedną zmianę, którą da się zweryfikować. W sklepie może to być optymalizacja zdjęcia produktu, a w serwisie informacyjnym — ograniczenie pracy skryptów po otwarciu menu. Po wdrożeniu sprawdź ponownie przebieg w Lighthouse, a dane terenowe obserwuj w kolejnych okresach. Taki cykl pozwala podejmować decyzje na podstawie zrozumiałego problemu, nie pogoni za jednym wynikiem.
