PageSpeed Insights – co to jest i czy 100/100 jest potrzebne?

Czym jest PageSpeed Insights

Dane laboratoryjne kontra dane od realnych użytkowników

Dokumentacja rozdziela to jednoznacznie: „Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics”.1

Konkretnie: część laboratoryjna, w tym słynny wynik punktowy, powstaje z symulacji w Lighthouse. Część terenowa pochodzi z Chrome User Experience Report i obejmuje doświadczenia realnych użytkowników z ostatnich 28 dni.1

Stąd dwa wnioski oszczędzające nerwy. Po wdrożeniu poprawek dane terenowe nie zmienią się od razu: trzeba odczekać, aż nowe doświadczenia wypełnią 28-dniowe okno. I strona może nie mieć danych terenowych w ogóle, jeśli nie zbierze ich dość, by trafić do zbioru CrUX.1 Brak tej sekcji nie jest błędem narzędzia.

Co dokładnie znaczy „real-world bottlenecks”

Zastrzeżenie o wąskich gardłach brzmi abstrakcyjnie, dopóki nie zestawi się dwóch pomiarów tej samej strony. Zrobiliśmy to na własnej.

W teście laboratoryjnym z 20 sierpnia 2026 (emulacja telefonu, procesor spowolniony czterokrotnie, sieć bez ograniczeń) czternaście naszych stron zmieściło się w progach z zapasem: mediana LCP 370 ms przy dopuszczalnych 2500.2

Dzień później policzyliśmy, ile żądań sieciowych wykonuje strona główna przy wczytaniu. Wyszło 87, z czego 33 do jednego zewnętrznego hosta z grafikami emoji.3

To jest właśnie różnica między laboratorium a terenem, pokazana na jednej stronie. Przy łączu bez ograniczeń 33 dodatkowe żądania kosztują milisekundy i w wyniku nie widać ich wcale. Na słabym zasięgu, gdzie liczy się każde nawiązanie połączenia, ta sama strona zachowa się inaczej, a laboratoryjny pomiar nadal pokaże 370 ms.

Praktyczna zasada: dobry wynik laboratoryjny wyklucza pewne problemy, a nie potwierdza szybkości. Liczbę żądań i zewnętrznych hostów warto sprawdzić osobno, bo to właśnie ona odpowiada za różnicę między testem a rzeczywistością.

Terenowe mówią czy, laboratoryjne dlaczego

Sensowna kolejność: patrzymy na dane terenowe, żeby wiedzieć, czy jest problem, a na dane laboratoryjne i podpowiedzi Lighthouse, żeby zrozumieć, dlaczego. Wynik pojedynczego uruchomienia testu bywa zmienny, więc jeden pomiar laboratoryjny nie jest podstawą do wniosków.

Wynik punktowy nie jest oceną Google

Najczęstszy błąd polega na traktowaniu punktacji jak oceny wystawionej przez Google i optymalizowaniu pod symulację zamiast pod doświadczenie odwiedzających. Punktacja pochodzi wyłącznie z testu laboratoryjnego; w ocenie strony liczą się Core Web Vitals mierzone na realnym ruchu.

Drugi częsty błąd to sprawdzanie efektu poprawek następnego dnia, bo dane terenowe reagują z opóźnieniem liczonym w tygodniach.

Z czym łączy się wynik PageSpeed

PageSpeed Insights raportuje Core Web Vitals i wiąże się z oceną page experience, a poprawa wyników pokrywa się z pracą nad szybkością strony.

Najczęstsze pytania

Dlaczego nie widzę danych o realnych użytkownikach?
Bo strona musi zebrać ich wystarczająco dużo, żeby trafić do zbioru Chrome User Experience Report. Brak tej sekcji nie oznacza błędu.

Jak szybko widać efekt poprawek?
W danych laboratoryjnych od razu, w terenowych dopiero wtedy, gdy nowe doświadczenia wypełnią 28-dniowe okno zbierania.

Czy trzeba mieć 100 punktów?
Nie. Punktacja pochodzi z symulacji, a o ocenie strony decydują wskaźniki z realnego ruchu.

Mam dobry wynik laboratoryjny. Czy strona jest szybka?
Niekoniecznie. Test bez ograniczeń łącza nie pokaże kosztu dużej liczby żądań. Warto policzyć je osobno.

Źródła

1. Google, „About PageSpeed Insights” (odczyt 2026-08-21): „Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics”; „PSI reports real users’ (…) experiences over the previous 28-day collection period”; „In order to show user experience data for a given page, there must be sufficient data for it to be included in the CrUX dataset”. Zobacz dokumentację Google →

2. Pomiar własny essaseo.pl z 2026-08-20 na 14 podstronach: headless Chrome, emulacja ekranu 412×915, procesor spowolniony czterokrotnie, bez dławienia sieci, dwa przebiegi, brany gorszy wynik. Mediana LCP 370 ms, wartości skrajne 292 i 2112 ms; żadna strona nie przekroczyła progu 2500 ms.

3. Pomiar własny essaseo.pl z 2026-08-21: rejestracja wszystkich żądań sieciowych przy wczytaniu strony głównej: 87 odpowiedzi, w tym 33 z zewnętrznego hosta z biblioteką grafik emoji.