PageSpeed Insights i Lighthouse — jak czytać wynik
Narzędzia PageSpeed Insights i Lighthouse generują raporty, które na pierwszy rzut oka mogą wydawać się skomplikowane. Duże kolorowe liczby, dziesiątki metryk, różne wyniki dla urządzeń mobilnych i desktopowych — łatwo się w tym zgubić. Ten artykuł pokazuje, jak czytać te dane w sposób użyteczny, bez wchodzenia w niepotrzebne techniczne detale.
Czym różni się PageSpeed Insights od Lighthouse
Lighthouse to silnik analizy — narzędzie wbudowane w przeglądarkę Chrome (zakładka DevTools → Lighthouse), które ocenia stronę w kontrolowanych warunkach laboratoryjnych. Możesz je uruchomić samodzielnie na dowolnym komputerze.
PageSpeed Insights to usługa Google dostępna pod adresem pagespeed.web.dev. Korzysta z silnika Lighthouse, ale uzupełnia wyniki o dane rzeczywiste zebrane przez Chrome User Experience Report (CrUX) — czyli dane od prawdziwych użytkowników odwiedzających daną stronę. To ważna różnica: laboratorium mówi, jak strona powinna działać, dane rzeczywiste mówią, jak faktycznie działa.
Co oznaczają cztery główne kategorie Lighthouse
Raport Lighthouse dzieli wyniki na cztery obszary. Każdy z nich oceniany jest w skali 0–100.
- Performance — szybkość ładowania strony. To jedyna kategoria, która bezpośrednio przekłada się na doświadczenie użytkownika i jest brana pod uwagę przez algorytmy Google w kontekście Core Web Vitals.
- Accessibility — dostępność cyfrowa. Sprawdza m.in. kontrast tekstu, opisy alternatywne obrazków, strukturę nagłówków i obsługę klawiatury.
- Best Practices — dobre praktyki techniczne. Obejmuje m.in. używanie HTTPS, brak podatnych bibliotek JS, poprawne proporcje obrazów.
- SEO — podstawowe sygnały techniczne istotne dla wyszukiwarek. Sprawdza m.in. obecność meta description, czytelność linków, crawlowalność strony.
Wynik w każdej kategorii nie jest równoważny — Performance 49 to poważny problem, SEO 90 przy kilku drobnych błędach to sytuacja do opanowania w godzinę.
Jak interpretować wynik Performance
Google klasyfikuje wyniki kolorem: 0–49 to czerwony (słabo), 50–89 to pomarańczowy (wymaga poprawy), 90–100 to zielony (dobry). Nie oznacza to jednak, że wynik 90 gwarantuje szybką stronę w odczuciu użytkownika — zależy to też od specyfiki treści, liczby zewnętrznych zasobów i zachowania samych użytkowników.
Ważniejsze niż ogólna liczba są konkretne metryki składowe.
Core Web Vitals — trzy metryki, na które warto patrzeć w pierwszej kolejności
- LCP (Largest Contentful Paint) — czas załadowania największego widocznego elementu strony (najczęściej główny obraz lub nagłówek). Cel: poniżej 2,5 sekundy.
- INP (Interaction to Next Paint) — czas reakcji strony na interakcję użytkownika (kliknięcie, wpisanie tekstu). Cel: poniżej 200 ms. Od 2024 roku zastąpiło FID jako oficjalna metryka Google.
- CLS (Cumulative Layout Shift) — skumulowane przesunięcia layoutu podczas ładowania strony. Cel: poniżej 0,1. Wysoki CLS powoduje, że elementy „skaczą” na ekranie — to frustrujące dla użytkownika i źle oceniane przez Google.
Pozostałe metryki Performance
- FCP (First Contentful Paint) — kiedy pojawia się pierwszy widoczny element. Dobre: poniżej 1,8 s.
- TBT (Total Blocking Time) — łączny czas, w którym główny wątek przeglądarki jest zablokowany. Koreluje z INP. Dobre: poniżej 200 ms.
- Speed Index — jak szybko strona wypełnia się treścią wizualnie. Dobre: poniżej 3,4 s.
Dane laboratoryjne kontra dane rzeczywiste
PageSpeed Insights pokazuje dwie sekcje: dane rzeczywiste (jeśli są dostępne dla danej domeny) i dane laboratoryjne. Dane rzeczywiste z CrUX są zbierane przez 28 dni i odzwierciedlają faktyczne warunki użytkowników — różne urządzenia, różne łącza internetowe. Mogą się różnić od laboratoryjnych nawet o kilkadziesiąt punktów.
Jeśli widzisz dobry wynik laboratoryjny, ale dane rzeczywiste są słabe — problem leży prawdopodobnie w ciężkich zasobach ładowanych z zewnątrz, skryptach śledzących lub renderowaniu po stronie klienta. Odwrotna sytuacja (słabe laboratorium, dobre dane rzeczywiste) zdarza się rzadziej i często wynika z agresywnego cachowania po stronie użytkownika.
Jak nie interpretować tych wyników
Kilka błędów pojawia się regularnie, gdy właściciele stron lub niespecjaliści samodzielnie czytają raporty.
- Porównywanie wyników desktop i mobile jak jednego wskaźnika. Google analizuje strony mobilnie jako priorytet (mobile-first indexing). Wynik 95 na desktopie i 48 na mobile to problem, nie kompromis.
- Skupianie się na ogólnej liczbie, a nie na konkretnych błędach. Raport poniżej wyniku pokazuje listę problemów z oszacowanym wpływem na czas ładowania. To tam jest mapa pracy do wykonania.
- Traktowanie każdego ostrzeżenia jak krytycznego błędu. Lighthouse raportuje też punkty informacyjne i niskie priorytety. Nie każde zalecenie wymaga natychmiastowego działania.
- Uruchamianie testu wielokrotnie i uśrednianie. Wynik może wahać się między uruchomieniami nawet o kilkanaście punktów. Miarodajne są dane rzeczywiste z CrUX, nie pojedynczy wynik laboratoryjny.
Od czego zacząć poprawę wyników
Jeśli analiza wskazuje na problemy, pracę warto zacząć od elementów z największym szacowanym wpływem na czas ładowania — Lighthouse oznacza je wprost w sekcji „Opportunities”. Najczęstsze przyczyny słabych wyników to nieskompresowane obrazy, brak lazy loadingu, duże pliki JavaScript blokujące renderowanie oraz powolny czas odpowiedzi serwera (TTFB).
Jeśli chcesz, żeby ktoś przejrzał wyniki Twojej strony i powiedział, co rzeczywiście wymaga naprawy — możemy to zrobić w ramach audytu technicznego.
FAQ - najczęstsze pytania
Czy wynik PageSpeed Insights ma bezpośredni wpływ na pozycje w Google?
Google uwzględnia Core Web Vitals jako jeden z sygnałów rankingowych, ale nie jest to czynnik decydujący o pozycji. Słabe wyniki mogą obniżać widoczność w wynikach wyszukiwania, jednak dobra treść i silna domena mogą kompensować umiarkowane problemy z wydajnością.
Jak często warto sprawdzać wyniki w PageSpeed Insights?
Dane CrUX odświeżają się co 28 dni, więc sprawdzanie częściej niż raz w miesiącu rzadko wnosi nową informację. Warto wracać do raportu po każdej większej zmianie na stronie — aktualizacji motywu, dodaniu nowych skryptów lub przebudowie szablonu.
Dlaczego wynik na mobile jest znacznie niższy niż na desktopie?
Lighthouse symuluje wolniejsze warunki sieciowe i słabszy procesor przy testach mobilnych, co odpowiada realistycznym warunkom użytkowania smartfonów. Różnica kilkudziesięciu punktów między mobile a desktopem jest częsta i nie oznacza błędu w konfiguracji — ale wynik mobilny jest ważniejszy, bo Google indeksuje strony właśnie w trybie mobile-first.
Co zrobić, gdy dane laboratoryjne są dobre, a dane rzeczywiste złe?
Rozbieżność najczęściej wskazuje na zasoby zewnętrzne ładowane po wejściu użytkownika na stronę — skrypty analityczne, piksele reklamowe lub czcionki z zewnętrznych serwerów. Warto przeanalizować zakładkę Network w DevTools podczas rzeczywistego ładowania strony, żeby zobaczyć, które zasoby blokują renderowanie.
Czy da się osiągnąć wynik 100 w kategorii Performance?
Technicznie tak, ale w praktyce strony z dynamiczną treścią, obrazami i zewnętrznymi skryptami rzadko go utrzymują. Ważniejsze jest osiągnięcie zielonych wyników w Core Web Vitals i eliminacja błędów o wysokim priorytecie — sama liczba 100 nie jest celem operacyjnym.
Czym różni się INP od starego FID i dlaczego zmiana ma znaczenie?
FID mierzył tylko czas reakcji na pierwszą interakcję użytkownika ze stroną. INP mierzy czas reakcji przez cały czas trwania wizyty, co daje pełniejszy obraz płynności obsługi strony. Strony, które zdawały test z FID, mogą mieć problemy z INP przy intensywnym użyciu JavaScript.