PageSpeed Insights - jak prawidłowo interpretować wyniki

Zacznij od Field data, nie od dużego kółka z wynikiem. To najczęstszy błąd, jaki widzimy przy audytach: ktoś otwiera PageSpeed Insights, widzi 47/100 i wpada w panikę, choć realni użytkownicy ładują stronę szybko.

PageSpeed Insights (PSI) pokazuje dwa zupełnie różne zestawy danych i to jest sedno całej interpretacji. Mylenie ich prowadzi do złych decyzji optymalizacyjnych.

Field data (dane terenowe) to pomiary od prawdziwych użytkowników Chrome, którzy odwiedzili Twoją stronę w ciągu ostatnich 28 dni. Pochodzą z Chrome UX Report (CrUX), liczone są jako 75. percentyl i to właśnie ich Google używa jako sygnału rankingowego. Pojawiają się w sekcji opisującej doświadczenie realnych użytkowników.

Lab data (dane laboratoryjne) to pojedyncza symulacja silnika Lighthouse w sztywnych warunkach: emulowane urządzenie mobilne klasy średniej, dławione łącze, czysty cache. Są powtarzalne i świetne do debugowania, ale opisują jeden test na jednym wirtualnym telefonie, a nie Twoich klientów.

Core Web Vitals to trzy metryki, które realnie wpływają na ranking, i tylko one z całego raportu są oficjalnym sygnałem Google. Reszta liczb jest pomocnicza.

LCP (Largest Contentful Paint) mierzy, kiedy renderuje się największy element widoczny bez przewijania – zwykle zdjęcie hero albo duży nagłówek. To odpowiedź na pytanie: kiedy użytkownik widzi, że strona załadowała treść. Najczęstsi winowajcy słabego LCP to nieskompresowane obrazy i wolna odpowiedź serwera.

INP (Interaction to Next Paint) zastąpił FID w marcu 2024 i jest znacznie surowszy. Mierzy opóźnienie między kliknięciem czy dotknięciem a reakcją interfejsu, biorąc pod uwagę najgorsze interakcje w sesji. Wysoki INP to prawie zawsze przeciążony JavaScript – skrypty firm trzecich, czaty, bannery zgody.

CLS (Cumulative Layout Shift) to suma przeskoków układu. Każdy, kto trafił palcem w zły przycisk, bo treść podskoczyła przy doczytywaniu reklamy, zna ten problem. Główne przyczyny to obrazy bez podanych wymiarów, dynamicznie wstrzykiwane elementy i fonty zmieniające layout.

Progi to wartości publikowane przez Google w dokumentacji web.dev. Strona zdaje ocenę CWV, gdy wszystkie trzy metryki w Field data mieszczą się w progach dobrych.

Wynik 0-100 dotyczy wyłącznie Lab data i jest ważoną średnią kilku metryk laboratoryjnych – nie ma w nim ani jednej liczby z CrUX. To dlatego strona z wynikiem 60 potrafi zdawać Core Web Vitals, a strona z wynikiem 95 potrafi je oblać.

Duże kółko z liczbą składa się głównie z Total Blocking Time, LCP laboratoryjnego i CLS laboratoryjnego, uzupełnionych o First Contentful Paint i Speed Index. To metryki z symulacji na słabym wirtualnym telefonie – użyteczne, by zlokalizować problem, ale nie po to, by raportować je zarządowi jako ocenę szybkości.

Tu pojawia się mit 100/100. Pogoń za perfekcyjną setką to najczęstsze marnowanie budżetu, jakie spotykamy. Powyżej progu dobrego CWV każdy kolejny punkt wymaga coraz większego nakładu pracy przy zerowym wpływie na ranking i znikomym na użytkownika. Czasem ostatnie punkty da się ugrać tylko kosztem funkcji, które realnie pomagają w sprzedaży.

Wynik laboratoryjny waha się też między testami o 5-10 punktów z powodu zmiennego obciążenia serwerów Google i sieci. Pojedynczy spadek to nie regres – to szum pomiarowy. Dlatego do oceny zmian bierze się medianę z kilku przebiegów, a nie jeden zrzut ekranu.

Sekcje Możliwości i Diagnostyka podpowiadają, gdzie szukać, ale nie wpływają wprost na wynik – to wskazówki, nie wyroki. Naprawiaj te, które dotykają Core Web Vitals, resztę pomiń.

Najczęściej powtarzające się rekomendacje da się zmapować na konkretne działania:

W sekcji Możliwości każda pozycja ma szacowany zysk czasowy – sortuj po nim malejąco i zaczynaj od góry. Pozycja obiecująca 0,02 s oszczędności nie jest warta godziny pracy, nawet jeśli świeci na czerwono.

Pamiętaj o rozdzieleniu widoku Mobile i Desktop. Google ocenia obie wersje osobno, a problemy wydajnościowe niemal zawsze są poważniejsze na mobile, bo tam działa słabszy procesor i wolniejsza sieć.

Brak Field data nie oznacza, że strona jest wolna – oznacza, że Google nie ma jeszcze wystarczająco dużo wizyt z Chrome, by zbudować próbkę. Nowe witryny i strony o małym ruchu po prostu nie zbierają danych CrUX przez pierwsze tygodnie.

W takiej sytuacji opieraj się na Lab data, ale ostrożnie. Traktuj je jako wskazówkę kierunkową: jeśli LCP laboratoryjny wynosi 8 sekund, masz realny problem niezależnie od braku danych terenowych. Jeśli mieści się w okolicach 2 sekund, prawdopodobnie jest dobrze, ale poczekaj na potwierdzenie z pola.

Dobrym uzupełnieniem jest raport Core Web Vitals w Google Search Console – grupuje adresy URL po szablonach i pokazuje trendy w czasie, czego pojedynczy test PSI nie zrobi. To także najlepsze miejsce, by mierzyć efekt wdrożonych poprawek na poziomie całego serwisu, a nie jednej podstrony.

Wpływ na ranking ma stan Core Web Vitals w Field data, a nie liczba w kółku – i nawet ten wpływ jest jednym z wielu sygnałów, nie przełącznikiem decydującym o pozycji. Trafność treści i intencja wyszukiwania ważą znacznie więcej.

W praktyce szybkość działa najczęściej jako czynnik rozstrzygający między stronami o zbliżonej jakości treści: gdy dwie odpowiedzi są równie dobre, szybsza i stabilniejsza wygrywa. Dlatego wydajność opłaca się traktować jako element szerszej strategii pozycjonowania SEO, a nie samodzielną dźwignię, która sama wypchnie stronę na pierwszą pozycję.

Drugi, często niedoceniany efekt jest konwersyjny. Wolne ładowanie i przeskakujący layout zwiększają liczbę porzuceń, zanim użytkownik w ogóle przeczyta ofertę. Poprawa LCP i CLS bywa odczuwalna w sprzedaży szybciej niż w rankingu – i to często ona uzasadnia budżet na optymalizację lepiej niż argument SEO.