Dane z terenu kontra wynik laboratoryjny, progi LCP, INP i CLS oraz kolejność napraw - jak czytać raport PageSpeed Insights i nie gonić za setką.
Raport PageSpeed Insights ma dwie części, które łatwo pomylić: dane z terenu (pomiary od prawdziwych użytkowników Chrome - to one liczą się dla Google) oraz wynik laboratoryjny 0-100 (symulacja jednego wejścia, przydatna wyłącznie do diagnozy). Strona z wynikiem 55 i zielonymi danymi z terenu jest w porządku. Odwrotnie - już nie.
Poniżej wyjaśniamy, co dokładnie znaczy każda liczba w raporcie, jakie są progi trzech kluczowych metryk, jak czytać listę zaleceń, żeby nie tracić dni na poprawki warte 50 milisekund, oraz w jakiej kolejności naprawiać, żeby najszybciej zobaczyć efekt.
To rozróżnienie jest fundamentem całego raportu:
Skąd biorą się rozbieżności? Twoi realni klienci wchodzą z lepszych telefonów, często z zapisanym cache, z polskich łączy - podczas gdy symulacja zakłada warunki celowo pesymistyczne. Dlatego wynik lab bywa dramatycznie niższy niż faktyczne doświadczenie użytkowników.
Jest też sytuacja odwrotna, znacznie groźniejsza: ładny wynik laboratoryjny przy czerwonych danych z terenu. Oznacza, że symulacja trafia w wersję strony, której klienci nie widzą - na przykład podstronę bez ciężkich elementów albo stan przed doładowaniem skryptów zewnętrznych.
Małe strony często w ogóle nie mają sekcji danych z terenu: zbyt mało odwiedzin, by Google zebrał statystycznie sensowną próbkę. Wtedy zostaje Ci wynik laboratoryjny jako jedyny drogowskaz - i to jest jedyna sytuacja, w której warto go traktować poważniej. Sprawdź wtedy dane dla całej domeny (PSI pokazuje je osobno) zamiast dla pojedynczego adresu.
| Metryka | Co mierzy | Dobrze | Źle |
|---|---|---|---|
| LCP | jak szybko pojawia się główny element strony | do 2,5 s | powyżej 4 s |
| INP | jak szybko strona reaguje na kliknięcia | do 200 ms | powyżej 500 ms |
| CLS | czy treść skacze podczas ładowania | do 0,1 | powyżej 0,25 |
Wartości pomiędzy oznaczają „wymaga poprawy" - stan, w którym strona działa, ale wyraźnie odstaje. Warto wiedzieć, że INP zastąpiło wcześniejszą metrykę FID: mierzy responsywność przez cały czas wizyty, a nie tylko przy pierwszym kliknięciu, więc jest znacznie trudniejsze do oszukania.
| Metryka | Typowy winowajca | Pierwsza naprawa |
|---|---|---|
| LCP | wolna odpowiedź serwera, ciężki obraz w nagłówku | cache serwerowy, kompresja obrazu hero |
| LCP | blokujące arkusze stylów i czcionki | ograniczenie CSS, lokalne czcionki |
| INP | nadmiar JavaScriptu, ciężkie wtyczki | usunięcie zbędnych wtyczek, odroczenie skryptów |
| INP | skrypty zewnętrzne (czaty, piksele, mapy) | ładowanie po interakcji zamiast od razu |
| CLS | obrazy bez podanych wymiarów | atrybuty width i height w kodzie |
| CLS | banery cookies i reklamy wskakujące nad treść | zarezerwowana stała przestrzeń |
Szczegółową instrukcję naprawy każdej z metryk zbiera osobny tekst o Core Web Vitals.
Lista „Możliwości" potrafi mieć dwadzieścia pozycji, ale nie są one równe. Praktyczna metoda:
Szerszy kontekst i pełną listę technik zbiera przewodnik Szybka strona WWW.
Zdrowy cel dla strony firmowej to zielone Core Web Vitals w danych z terenu oraz wynik mobilny w laboratorium powyżej 70-80. Pogoń za 100/100 kosztem analityki, czatu i map jest sztuką dla sztuki: klienci kupują na stronach szybkich, nie na perfekcyjnych w benchmarku.
Praktyczna zasada: jeśli strona ładuje się w oczach użytkownika poniżej dwóch sekund, reaguje natychmiast na kliknięcia i nic na niej nie skacze - jest gotowa. Dalsza optymalizacja to już liczby dla liczb.
Nie ten z laboratorium. Google bierze pod uwagę Core Web Vitals mierzone u prawdziwych użytkowników, a nie liczbę 0-100 z symulacji. Szybkość jest przy tym sygnałem pomocniczym - przy dwóch stronach o podobnej jakości treści szybsza wygra, ale sama szybkość nie wypchnie słabej strony na pierwsze miejsce.
Najpierw sprawdź dane z terenu. Jeśli są zielone, strona działa dobrze dla realnych użytkowników, a niski wynik laboratoryjny wynika z pesymistycznych założeń symulacji. Jeśli danych z terenu brak (mała strona), potraktuj wynik poważnie i zacznij od serwera oraz obrazów.
Bo test laboratoryjny to pojedynczy pomiar zależny od chwilowego obciążenia serwerów testowych, sieci i skryptów zewnętrznych. Wahania rzędu 10 punktów są normalne. Dlatego porównuj mediany z kilku pomiarów, a decyzje opieraj na danych z terenu.
Częściowo - dobra wtyczka cache i optymalizacji zasobów potrafi zrobić większość roboty przy WordPressie. Nie naprawi jednak wolnego serwera, przeładowanego motywu ani dwudziestu wtyczek robiących zapytania przy każdym wejściu. Agresywne ustawienia (łączenie i odraczanie wszystkiego) potrafią też zepsuć wygląd strony - zawsze sprawdzaj efekt po włączeniu.
Tak, i widać to najwyraźniej w czasie odpowiedzi serwera, który jest fundamentem metryki LCP. Dysk NVMe, nowoczesny serwer WWW z cache i aktualna wersja PHP potrafią ściąć ten czas kilkukrotnie, zanim jeszcze dotkniesz kodu strony. Odwrotnie: na przeciążonym serwerze żadna optymalizacja frontendu nie da zielonych metryk.
Obie, ale osobno. Strona główna bywa najcięższa (slider, animacje), a jednocześnie to podstrony ofertowe i wpisy bloga przyjmują większość ruchu z wyszukiwarki. Wybierz 3-4 najczęściej odwiedzane adresy z Google Analytics i to je monitoruj - poprawa tam przekłada się na realny ruch, a nie na jedną wizytówkę.
Wszystkie poradniki z kategorii: Szybkość i wydajność