Przestań być niewolnikiem score’u Lighthouse

Większość osób optymalizujących strony WWW skupia się na jednym celu: zielony wynik w PageSpeed Insights czy też Lighthouse.

Ale prawda jest taka, że wysoki score nie zawsze oznacza szybkie działanie strony dla użytkownika. Zapewniam Cię, że można tak zmodyfikować kod strony, że odpowiedni rezultat w PSI się pojawi i wszystko będzie "świecić" na zielono, a rzeczywistość będzie zupełnie inna - użytkownicy będą odbierali ją jako wolną.

Dlaczego? Bo Lighthouse czy PageSpeed Insights to symulacje i równie dobrze odpowiednie wyniki można symulować.

Oprócz tego narzędzia typu Pagespeed Insights mierzą tylko początkowy stan witryny, na samej górze (bez wchodzenia w interakcję z nią). Metryka CLS (stabilność układu) może wskazywać na odpowiednią wartość, a mimo to wiele elementów może przesuwać się w miarę korzystania ze strony wśród odwiedzających - np. w momencie scrollowania w dół witryny. Tego Lighthouse czy Pagespeed Insights nie zmierzą.

To samo z interakcjami. Skąd wiesz na bazie Lighthouse, że jest problem z responsywnością strony (metryka INP)? Nie dowiesz się. Ale skutecznie pozyskasz takie informacje od rzeczywistych użytkowników na bazie RUM - czyli Real User Monitoring.

Od razu powiem Ci też, że nie musisz "żyłować" wyników w Pagespeed Insights, aby było 100/100. Równie dobrze w LH czy PSI wynik może oscylować na poziomie 60/100 albo 70/100, a użytkownicy nadal będą zadowoleni. Serio. Nie trzeba wyrywać sobie włosów z głowy i spędzać na optymalizacji długich tygodni, by coś zaświeciło się na zielono. Chyba, że dla własnego ego - przy czym dobrze byłoby, żeby nie przepalać czasu, a tym samym pieniędzy.

[aktualizacja 15.10.2025] Jeżeli natomiast testujesz jakąś stronę, otrzymując wynik w Lighthouse/PSI np. 20/100, nie oznacza jednocześnie, że wszystko jest w porządku.

Naszym obowiązkiem jest, aby spełnić wszystkie kryteria wydajnej witryny czy aplikacji, przechodząc przez odpowiednią sekwencję kroków. Zasadniczo wcale nie potrzebujesz do tego narzędzia typu Pagespeed Insights. Rekomendacje w Lighthouse mogą w tym oczywiście pomóc, ale do pewnego etapu. Zachęcam do szerszego patrzenia na kondycję całej strony, np. analizując dogłębnie waterfall zasobów. Po spełnieniu wszystkich wymogów, jeśli wynik w Lighthouse czy PageSpeed nadal oscyluje np. w granicach 80/100 - zbierz trochę danych spośród rzeczywistych użytkowników i działaj dalej, ale tylko jeśli sytuacja tego wymaga.

Optymalizacja wydajności to nie zadanie typu "one-time". To nie jest też sprint. To maraton.

Zacznij mierzyć rzeczywistość = RUM!

Nie interesuje nas, jak szybko strona ładuje się w laboratorium.
Interesuje nas jak użytkownik ją odbiera - czy może szybko wejść w interakcje, czy coś się zacina, czy przewijanie jest płynne, czy formularz reaguje natychmiast, czy nic nam się nie przesuwa.

Tego właśnie dostarczają dane RUM (Real User Monitoring) - czyli rzeczywiste metryki zebrane od prawdziwych użytkowników.
RUM to nie test - to ciągły pomiar doświadczenia użytkownika.

Dopiero na tej podstawie, wiedząc o określonym problemie, możemy skupić się na optymalizacji i wykorzystać inne narzędzia jak WebPageTest czy DevTools.

Przykłady systemów RUM

Jako audytor i developer korzystam z następujących systemów:

Zasadniczo pierwszym systemem RUM, na jaki patrzę to CrUX - czyli baza danych o wydajności naszej strony spośród rzeczywistych użytkowników, zbieranych przez przeglądarkę Google Chrome. Pamiętaj jednak, że są to tylko userzy Chrome i to nie wszyscy. Wartości metryk Core Web Vitals w CrUX to oczywiście jeden z czynników rankingowych w Google'u, więc te dane są bardzo istotne.

Niemniej jednak z samych metryk Core Web Vitals z CrUX trudno mieć pełny obraz.

INP prezentuje zawyżone dane? Fajnie, ale nie wiemy, o które interaktywne elementy chodzi.

CLS i pojawiające się przesunięcia układu? Wspaniale, ale które elementy się przesuwają?

Oczywiście można testować wtedy laboratoryjnie "na ślepo", ale przy większych serwisach może to być problematyczne.

Oprócz tego, dana strona może nie być zbyt popularna, a jej użytkownicy nie będą wysyłać danych wydajnościowych do CrUX. 

Dlatego też oprócz danych CrUX należy wyposażyć się w zewnętrzny system RUM i takie dane posiadać. Dodatkowy, który będzie dawał więcej szczegółów i uczyni naszą analizę i poprawę wydajności efektywną. Bez spędzania nad tym ogromu czasu.

Oprócz systemów RUM wymienionych powyżej na liście jest oczywiście sporo więcej - SpeedCurve, RUMVision itp. Ale w moim warsztacie pracy te trzy rozwiązania goszczą najczęściej.

Co dalej?

Mając dane RUM, możesz:

  • zidentyfikować realne problemy użytkowników
  • priorytetyzować poprawki według wpływu na UX i biznes
  • sprawdzać skuteczność zmian po wdrożeniu.

Dopiero wtedy optymalizacja ma sens - bo przestajesz zgadywać, a zaczynasz działać na podstawie rzeczywistych danych.

Dwie minuty o RUM z Cloudflare

Nagrałem krótkie wideo, w którym pokazuję w akcji system mierzenia wydajności wśród rzeczywistych użytkowników od Cloudflare. Jeśli korzystasz z tego CDN - po prostu to włącz i zaczniesz zbierać bardzo dużo przydatnych informacji na temat Twojej strony. Możesz też ustawić sobie powiadomienia mailowe, które będą zawierały statystyki i szczegóły. Będziesz cały czas na bieżąco z tematem poziomu wydajności Twojego projektu.

Web Performance w 2 minuty - wideo o Cloudflare Web Analytics

Wideo warsztat o narzędziach do analizy wydajności

W ramach mojego programu szkoleniowego Zoptymalizowany Frontend, przeprowadzam warsztaty na żywo. W październiku omawiałem właśnie Lighthouse, Pagespeed Insights i cały proces prawidłowego podejścia do tematu web performance.

Jeśli chcesz zobaczyć nagranie - dołącz do mojego kursu lub po prostu skontaktuj się ze mną (mogę Ci wysłać ten warsztat na zachętę :-)).

Kadr z warsztatu o optymalizacji wydajności

Nie pozwól, by Twoje decyzje o wydajności opierały się wyłącznie na syntetycznych rezultatach.

PageSpeed Insights to świetny punkt wyjścia, ale RUM to prawdziwy kompas.

Bo nie chodzi o to, by mieć 100/100.
Chodzi o to, by Twoja strona była szybka dla prawdziwych ludzi.

Jeśli masz wolną stronę i chcesz ją przyspieszyć - skontaktuj się ze mną. Przeprowadzam audyty wydajności i konstruuje rekomendacje techniczne do wdrożenia. Można też się ze mną umówić na konsultacje.

Jeśli chcesz dołączyć do mojego programu Zoptymalizowany Frontend - zapraszam na pokład.