Dlaczego PageSpeed Insights kłamie: różnica między wynikiem laboratoryjnym a realnym użytkownika

Wpisujesz adres swojej strony w PageSpeed Insights i widzisz upragnione 100/100. Tymczasem klienci zgłaszają, że witryna ładuje się wolno, a konwersje nie rosną. Ten rozdźwięk między wynikiem a rzeczywistością wynika z fundamentalnego nieporozumienia dotyczącego tego, co właściwie mierzy to narzędzie. PageSpeed Insights nie kłamie w dosłownym sensie, ale prezentuje dane laboratoryjne, które często nie mają nic wspólnego z tym, jak Twoja strona zachowuje się w przeglądarkach prawdziwych odwiedzających.

Aby podejmować świadome decyzje optymalizacyjne, musisz zrozumieć architekturę tego narzędzia i różnicę między symulacją a rzeczywistością.

Dwa różne światy w jednym narzędziu

PageSpeed Insights to w rzeczywistości nakładka na dwa zupełnie różne źródła danych. Górna sekcja wyników to dane z realnych użytkowników (Field Data), pobierane z raportu Chrome User Experience Report (CrUX). Dolna sekcja to dane laboratoryjne (Lab Data), generowane przez narzędzie Lighthouse.

Lighthouse (dane laboratoryjne) to kontrolowane środowisko. Narzędzie uruchamia stronę w symulatorze, na z góry określonym urządzeniu (zazwyczaj emulowany Moto G Power lub podobny średniak) z sztucznie dławionym połączeniem sieciowym (często 4G z opóźnieniami) i w pełni czystą pamięcią podręczną (tzw. cold load). Test wykonuje się jeden raz, w izolowanym środowisku.

CrUX (dane z realnych użytkowników) to zagregowane dane telemetryczne z przeglądarki Chrome. Obejmują one 28-dniowe okno czasowe i pokazują, jak strona zachowywała się u tysięcy rzeczywistych użytkowników, na ich sprzęcie, w ich sieciach komórkowych i domowych Wi-Fi, z ich zainstalowanymi rozszerzeniami i zapełnioną pamięcią podręczną.

Dlaczego wynik PageSpeed nie pokazuje doświadczenia użytkownika

Głównym problemem jest to, że większość właścicieli stron i nieświadomych wykonawców skupia się wyłącznie na kolorowych paskach z sekcji laboratoryjnej. To prowadzi do fałszywego poczucia bezpieczeństwa. Dlaczego wynik PageSpeed nie pokazuje doświadczenia użytkownika? Ponieważ laboratorium nie uwzględnia zmienności świata rzeczywistego.

1. Zróżnicowanie sprzętu i sieci: Lighthouse testuje stronę na jednym, z góry ustalonym profilu urządzenia. Twoi klienci mogą otwierać stronę na kilkuletnich telefonach z dziesiątkami otwartych kart w tle, co drastycznie ogranicza dostępne zasoby CPU, lub na nowoczesnych flagowcach z szybkim 5G. Symulacja nie oddaje tej skali.
2. Stan pamięci podręcznej: Lighthouse zawsze testuje stronę jako pierwszą wizytę (czysta pamięć podręczna). W rzeczywistości powracający użytkownicy mają w przeglądarce zapisane zasoby statyczne (obrazy, CSS, JS), co sprawia, że dla nich strona załaduje się wielokrotnie szybciej niż wskazuje to test laboratoryjny.
3. Skrypty firm trzecich: W laboratorium skrypty analityczne, czaty online czy piksele reklamowe mogą załadować się w przewidywalny sposób. U realnych użytkowników te same skrypty często rywalizują o główny wątek (Main Thread), powodując zacinanie się interfejsu, czego symulowany test może nie uchwycić.

Kiedy wynik 100 nie oznacza szybkiej strony

Optymalizacja pod kątem wyniku 100/100 w Lighthouse to częsty błąd. Skupianie się wyłącznie na wskaźnikach laboratoryjnych prowadzi do sytuacji, w której kiedy wynik 100 nie oznacza szybkiej strony, a wręcz przeciwnie – maskuje poważne problemy.

Możesz uzyskać idealny wynik laboratoryjny, wycinając wszystkie zewnętrzne skrypty i upraszczając stronę do minimum. W izolowanym teście załaduje się błyskawicznie. Jednak w świecie rzeczywistym, jeśli Twój serwer ma długi czas odpowiedzi (TTFB) dla użytkowników z określonej lokalizacji geograficznej, lub jeśli skrypty śledzące blokują interakcję, realny użytkownik i tak odczuje frustrację. Lighthouse nie sprawdzi, jak strona radzi sobie pod obciążeniem ruchem z różnych stref czasowych, ani jak zachowuje się po 5 minutach przewijania zawartości.

Metryki, na które musisz patrzeć: LCP i INP

Aby ocenić rzeczywistą wydajność, musisz przenieść uwagę z ogólnego wyniku na konkretne metryki Core Web Vitals, porównując ich wartości laboratoryjne z rzeczywistymi.

LCP (Largest Contentful Paint)

LCP mierzy czas renderowania największego elementu w widocznym obszarze (zazwyczaj baneru głównego lub tytułu). W laboratorium Lighthouse precyzyjnie wylicza, jak szybko zasób zostanie pobrany i wyrenderowany w idealnych warunkach sieciowych.

Jednak dane CrUX dla LCP pokazują prawdę o Twoim serwerze i sieci dostarczania treści (CDN). Jeśli laboratoryjne LCP wynosi 1,5 sekundy, ale realne LCP (z CrUX) wynosi 3,5 sekundy, problemem nie jest waga obrazka, ale np. brak CDN, wolny czas odpowiedzi serwera dla dalszych lokalizacji lub opóźnienia w resolverze DNS. Optymalizacja rozmiaru pliku (co podnosi wynik w Lighthouse) nie rozwiąże problemu opóźnień sieciowych u realnych użytkowników.

INP (Interaction to Next Paint)

INP to wskaźnik oceniający responsywność strony. Mierzy opóźnienie od momentu, w którym użytkownik kliknie przycisk lub rozpocznie przewijanie, do momentu, w którym przeglądarka wyrenderuje wizualną odpowiedź na tę akcję.

Tutaj różnica między laboratorium a rzeczywistością jest najbardziej bolesna. Lighthouse nie klika w interfejs jak człowiek. W sekcji laboratoryjnej widzisz ocenę Total Blocking Time (TBT), która jest tylko teoretycznym wskaźnikiem potencjalnej blokady wątku głównego. TBT dobrze koreluje z INP, ale go nie zastępuje.

Realny użytkownik, który wchodzi na stronę, przewija ją i próbuje otworzyć menu hamburgerowe w momencie, gdy w tle parsuje się ciężki skrypt JavaScript, doświadczy zacinania. CrUX uchwyci to jako słaby wynik INP. Lighthouse, wykonując swój jednorazowy, pasywny test, może zupełnie pominąć ten problem, dając Ci fałszywe zielone światło.

Jak technicznie diagnozować i poprawiać realną wydajność

Aby optymalizacja miała sens, musisz zmienić kolejność działań i opierać się na twardych danych, a nie na symulacjach.

1. Zacznij od sekcji Field Data w PSI: Jeśli PageSpeed Insights wyświetla dane z CrUX, to one są Twoim prawdziwym wynikiem. Ignoruj kolorowe paski z laboratorium, dopóki nie upewnisz się, że realne percentyle (P75) dla LCP i INP są w zielonej strefie.
2. Skorzystaj z Google Search Console: Raport Core Web Vitals w GSC agreguje dane CrUX dla całej witryny, pokazując dokładne adresy URL, które sprawiają problemy realnym użytkownikom. To najważniejsze źródło danych o wydajności.
3. Zaimplementuj Real User Monitoring (RUM): Jeśli Twoja strona ma mały ruch, CrUX może nie wyświetlać danych (brak wystarczającej próbki). Wtedy musisz wdrożyć własne skrypty RUM (np. web-vitals library), które zbierają dane o LCP i INP bezpośrednio z sesji Twoich klientów i wysyłają je do Twojego systemu analitycznego.
4. Audytuj skrypty firm trzecich: Sprawdź, ile zewnętrznych skryptów blokuje wątek główny. Użyj zakładki Network w narzędziach deweloperskich, aby zidentyfikować skrypty, które ładują się synchronicznie i opóźniają interakcję (co pogarsza INP).
5. Optymalizuj pod kątem INP, a nie TBT: Zamiast skupiać się wyłącznie na redukcji rozmiaru plików JS (co poprawia TBT w Lighthouse), przeanalizuj długie zadania (Long Tasks) w zakładce Performance. Podziel duże skrypty na mniejsze fragmenty (code splitting) i używaj requestIdleCallback lub setTimeout, aby ustąpić miejsca w wątku głównym, gdy użytkownik próbuje interagować ze stroną.

Rozdźwięk między testami laboratoryjnymi a doświadczeniem klientów to jeden z najczęstszych powodów, dla których teoretycznie zoptymalizowane strony nie przynoszą rezultatów biznesowych. Jeśli wskaźniki w Lighthouse sugerują idealną wydajność, a Twoi klienci wciąż czekają na załadowanie zawartości, problem leży w architekturze serwera, skryptach blokujących interakcje lub braku dostosowania do zmiennych warunków sieciowych. W takiej sytuacji powierzchowna optymalizacja pod wynik w narzędziu nie przyniesie efektu – konieczny jest gruntowny audyt techniczny, który uwzględnia rzeczywiste zachowanie witryny w przeglądarkach użytkowników.