Jak czytać raport Lighthouse bez paniki

Pierwsza zasada: wynik to nie Twoja strona

Otwierasz raport Lighthouse po raz pierwszy i widzisz ścianę liczb, kolorowe pola oraz ostrzeżenia dotyczące rzeczy, o których nigdy wcześniej nie słyszałeś. Naturalną reakcją jest panika. Wynik jest czerwony. Siedemnaście audytów zakończyło się niepowodzeniem. Strona na pewno jest zepsuta?

Prawdopodobnie nie. Lighthouse to narzędzie diagnostyczne, a nie świadectwo ocen. Wynik jest syntetycznym benchmarkiem uruchamianym w warunkach laboratoryjnych — często na ograniczonym połączeniu, z symulacją telefonu ze średniej półki z 2017 roku. Mówi, jak Twoja strona działa w tym konkretnym scenariuszu, a nie jak doświadczają jej prawdziwi użytkownicy w praktyce.

To ważne, ponieważ większość zespołów skupia się na wyniku i traci z oczu kontekst. Wynik 65 może być całkowicie akceptowalny dla złożonej aplikacji webowej z danymi w czasie rzeczywistym. Wynik 95 może nadal oznaczać słabe doświadczenie, jeśli zoptymalizowano niewłaściwe rzeczy. Wynik jest punktem wyjścia do analizy, a nie miarą sukcesu.

Co czytać najpierw: Core Web Vitals

Pomiń ogólny wynik wydajności. Przewiń do sekcji Metrics i spójrz na trzy liczby: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) oraz Interaction to Next Paint (INP). To Core Web Vitals i są to jedyne metryki wydajności, których Google używa jako sygnału rankingowego.

• LCP mierzy, ile czasu zajmuje wyrenderowanie największego widocznego elementu. Cel: poniżej 2,5 sekundy. Jeśli przekraczasz 4 sekundy, użytkownicy zbyt długo czekają na zobaczenie istotnej treści.
• CLS mierzy stabilność wizualną — jak bardzo strona „skacze” podczas ładowania. Cel: poniżej 0,1. Jeśli przekraczasz 0,25, użytkownicy przypadkowo klikają niewłaściwe elementy, bo przyciski zmieniły położenie.
• INP mierzy responsywność — jak szybko strona reaguje na kliknięcia, stuknięcia i naciśnięcia klawiszy. Cel: poniżej 200 ms. Jeśli przekraczasz 500 ms, strona sprawia wrażenie ociężałej.

Te trzy metryki korelują z rzeczywistą frustracją użytkowników. Napraw je, zanim zaczniesz martwić się czymkolwiek innym.

Opportunities kontra Diagnostics: poznaj różnicę

Lighthouse dzieli swoje ustalenia na dwie kategorie: Opportunities i Diagnostics. Opportunities są uporządkowane według szacowanej oszczędności czasu. Diagnostics to dodatkowy kontekst — rzeczy, które mogą być problemami albo wcale nimi nie są.

Zacznij od Opportunities. Jeśli Lighthouse mówi, że „Eliminate render-blocking resources” może zaoszczędzić 1,2 sekundy, to konkretna wygrana. Jeśli mówi, że „Reduce unused JavaScript” może zaoszczędzić 0,1 sekundy, prawdopodobnie nie warto robić refaktoryzacji.

Diagnostics są trudniejsze. „Avoid an excessive DOM size” brzmi źle, ale jeśli Twój CLS jest w porządku, a INP jest szybki, duży DOM może nikomu nie szkodzić. Diagnostyka to wskazówki, nie nakazy. Badaj te, które pasują do Twoich rzeczywistych metryk.

Audyty, które zwykle możesz zignorować

Niektóre ostrzeżenia Lighthouse są przestarzałe albo nadmiernie rygorystyczne. Oto te, które najczęściej wywołują niepotrzebną panikę:

• „Does not use passive listeners to improve scrolling performance” — To mikrooptymalizacja, która rzadko robi zauważalną różnicę. Jeśli nie masz dowodów na zacinające się przewijanie, pomiń ją.
• „Image elements do not have explicit width and height” — To ma znaczenie dla CLS, ale tylko wtedy, gdy obrazy powodują przesunięcia układu. Jeśli Twój CLS jest już dobry, nie refaktoryzuj wyłącznie dla zaliczenia audytu.
• „Serve images in next-gen formats” — Tak, WebP i AVIF są mniejsze. Ale jeśli Twoje obrazy są już zoptymalizowane, a LCP jest szybki, to miły dodatek, a nie kryzys.
• „Avoid enormous network payloads” — Lighthouse oznacza wszystko powyżej 1,6 MB. Ale strona o rozmiarze 2 MB, która ładuje się szybko, jest lepsza niż strona 500 KB blokująca renderowanie. Skup się na tym, jak bajty są dostarczane, a nie tylko na sumie.

Co zrobić, gdy wszystko jest czerwone

Jeśli Twój wynik Lighthouse jest poniżej 50, a większość audytów kończy się niepowodzeniem, prawdopodobnie masz do czynienia z jedną z trzech przyczyn źródłowych:

1. Niezoptymalizowane fonty. Fonty webowe nadal są najłatwiejszą wygraną wydajnościową na większości stron. Sprawdź, czy ładujesz sześć grubości fontu, gdy używasz tylko dwóch, albo czy wysyłasz pliki WOFF zamiast WOFF2.
2. CSS i JavaScript blokujące renderowanie. Jeśli First Contentful Paint (FCP) przekracza 3 sekundy, coś blokuje przeglądarce możliwość malowania. Poszukaj dużych plików CSS lub synchronicznych skryptów w <head>.
3. Zbyt duże obrazy. Jeśli element LCP jest obrazem i ma 4 MB, to właśnie jest Twój problem. Skompresuj go, zastosuj lazy loading dla obrazów poniżej pierwszego ekranu i użyj składni obrazów responsywnych.

Napraw jedną z tych rzeczy i uruchom Lighthouse ponownie. Często zobaczysz skok o 20–30 punktów. Potem zajmij się kolejną.

Dane laboratoryjne kontra dane z pola: sprawdzenie rzeczywistości

Lighthouse działa w laboratorium. Symuluje wolne połączenie i wolne urządzenie, ale nie potrafi zasymulować prawdziwego zachowania użytkowników — tego, jak przewijają, w co klikają i czy korzystają z niestabilnego Wi‑Fi.

Aby sprawdzić rzeczywistość, porównaj wyniki Lighthouse z danymi z pola z Chrome User Experience Report (CrUX). CrUX pokazuje, jak prawdziwi użytkownicy Chrome doświadczali Twojej strony przez ostatnie 28 dni. Jeśli Lighthouse mówi, że LCP wynosi 4 sekundy, ale CrUX pokazuje 2 sekundy, zaufaj CrUX. Jeśli oba wyniki są złe, masz realny problem.

Dane CrUX znajdziesz w PageSpeed Insights (webowej wersji Lighthouse) albo w Google Search Console w sekcji „Core Web Vitals”. Jeśli wyniki się rozchodzą, sprawdź dlaczego. Może Twoi prawdziwi użytkownicy korzystają z szybszych sieci. Może Lighthouse testuje niezoptymalizowaną wersję deweloperską.

Kiedy ponownie uruchamiać Lighthouse

Lighthouse bywa szumne. Uruchom go trzy razy z rzędu, a otrzymasz trzy różne wyniki, nawet na tej samej stronie. Dzieje się tak, ponieważ wydajność jest zmienna — procesy w tle, wahania sieci i heurystyki przeglądarki wpływają na rezultat.

Aby uzyskać stabilny punkt odniesienia, uruchom Lighthouse w trybie incognito ze wszystkimi rozszerzeniami wyłączonymi albo użyj CLI z flagą --preset=desktop, aby uzyskać bardziej powtarzalne wyniki. Uruchom go trzy razy i uśrednij wyniki. Jeśli widzisz duże wahania (ponad 10 punktów), coś innego jest nie tak — być może serwer jest wolny albo strona za każdym razem ładuje inne zasoby.

Uruchamiaj Lighthouse ponownie po każdej istotnej zmianie. Wdrażasz nową strategię fontów? Sprawdź LCP. Włączasz lazy loading obrazów? Sprawdź CLS. Dodajesz skrypt zewnętrzny? Sprawdź INP. Wydajność nie jest jednorazową poprawką; to budżet, którego trzeba bronić.

Narzędzia, które pomagają działać na podstawie ustaleń Lighthouse

Lighthouse mówi, co jest wolne. Nie zawsze mówi, jak to naprawić. Do tego potrzebujesz dodatkowych narzędzi:

• WebPageTest daje widok filmstrip pokazujący, jak strona ładuje się klatka po klatce. Niezbędne przy diagnozowaniu problemów z LCP i CLS.
• Panel Performance w Chrome DevTools pokazuje dokładnie, który JavaScript blokuje główny wątek. Użyj go, aby znaleźć źródło słabego wyniku INP.
• Narzędzia do kompresji obrazów pozwalają optymalizować obrazy bezpośrednio w przeglądarce, co jest szybsze i bardziej prywatne niż przesyłanie ich do usługi zewnętrznej. Przetwarzanie obrazów po stronie klienta to wygrana dla prywatności, ponieważ Twoje obrazy nigdy nie opuszczają Twojego komputera.

Lighthouse jest punktem wyjścia. Te narzędzia pomagają dokończyć pracę.

Najważniejsze wnioski

• Twój wynik Lighthouse jest laboratoryjnym benchmarkiem, a nie miarą rzeczywistego doświadczenia użytkowników. Zanim wpadniesz w panikę, porównaj go z danymi z pola z CrUX.
• Najpierw skup się na Core Web Vitals (LCP, CLS, INP). To metryki, które korelują z frustracją użytkowników i wpływem na SEO.
• Ustalaj priorytety Opportunities według szacowanej oszczędności czasu. Ignoruj Diagnostics, które nie pasują do Twoich rzeczywistych problemów z wydajnością.
• Niektóre audyty — takie jak passive listeners czy formaty obrazów nowej generacji — to mikrooptymalizacje. Najpierw napraw duże rzeczy.
• Uruchom Lighthouse trzy razy i uśrednij wyniki. Wydajność jest zmienna, a pojedynczy przebieg może wprowadzać w błąd.

FAQ

Q: Dlaczego mój wynik Lighthouse zmienia się za każdym razem, gdy go uruchamiam?
A: Lighthouse mierzy wydajność w zmiennych warunkach — szybkość sieci, obciążenie CPU i heurystyki przeglądarki wpływają na rezultat. Uruchom go trzy razy w trybie incognito i uśrednij wyniki, aby uzyskać stabilniejszy punkt odniesienia.

Q: Czy najpierw optymalizować pod mobile czy desktop?
A: Mobile. Lighthouse domyślnie używa symulacji mobile, ponieważ większość ruchu webowego pochodzi z urządzeń mobilnych, a urządzenia mobilne są wolniejsze. Jeśli wynik mobile jest dobry, wynik desktop zwykle też będzie w porządku.

Q: Mój wynik Lighthouse to 95, ale strona nadal wydaje się wolna. Co jest nie tak?
A: Lighthouse mierzy ładowanie strony, a nie interaktywność po załadowaniu. Sprawdź wynik INP i użyj panelu Performance w Chrome DevTools, aby sprofilować to, co dzieje się, gdy użytkownicy klikają lub przewijają. Możesz mieć problem z JavaScript, którego Lighthouse nie wychwytuje.

Q: Czy potrzebuję idealnego wyniku 100?
A: Nie. Wynik 90+ jest znakomity. Gonienie za 100 często oznacza optymalizowanie rzeczy, które nie mają znaczenia dla użytkowników. Skup się na rzeczywistych metrykach — LCP, CLS, INP — i zignoruj wynik.

Q: Czy mogę ufać Lighthouse, jeśli używam wielu skryptów zewnętrznych?
A: Lighthouse oznaczy skrypty zewnętrzne jako problem, ale nie zawsze potrafi odróżnić te konieczne od zbędnych. Użyj audytów „Avoid enormous network payloads” i „Reduce JavaScript execution time”, aby zidentyfikować najgorszych winowajców, a potem zdecyduj, czy warto je zostawić.

Źródła

• „Lighthouse performance scoring” — Google Developers
• „Core Web Vitals” — web.dev
• „Chrome User Experience Report” — Google Developers
• „WebPageTest Documentation” — WebPageTest.org