- Algorytmik
- SEO
- PageSpeed Insights: dwa wyniki na jednej stronie i który z nich oddaje dane użytkowników
PageSpeed Insights: dwa wyniki na jednej stronie i który z nich oddaje dane użytkowników
W raporcie jest ocena z 28 dni prawdziwych wizyt i osobny wynik Lighthouse z symulacji. Wyjaśniam, skąd rozbieżność, jakie są progi i co robić, gdy danych z pola brak.
Spis treści
- Dwa wyniki w PageSpeed Insights: skąd się biorą
- Dane z pola: CrUX, 28 dni i trzy wskaźniki Core Web Vitals
- Kiedy ocena Core Web Vitals jest zaliczona
- Wynik Lighthouse: co oznacza 90, 50 i warunki testu
- Dlaczego wyniki się różnią i dlaczego zmieniają się bez zmian na stronie
- Który wynik liczy się w Google
- Brak danych z pola: co to znaczy i co możesz zrobić
- Jak czytać raport w praktyce
W PageSpeed Insights masz dwa niezależne wyniki. Pierwszy to ocena Core Web Vitals z danych prawdziwych użytkowników Chrome z ostatnich 28 dni. Drugi to wynik Lighthouse, policzony w symulowanym wczytaniu strony. Do oceny, jak strona działa dla ludzi, służą dane z pola. Wynik laboratoryjny nadaje się głównie do szukania przyczyn problemów.
Rozbieżność jest więc zamierzona: oba pomiary dotyczą innych rzeczy. Poniżej rozpisuję, skąd każdy się bierze, jakie ma progi i kiedy któregoś z nich w raporcie zabraknie. Opieram się na dokumentacji PageSpeed Insights w Google for Developers.
W skrócie
- Dane z pola pochodzą z raportu Chrome User Experience (CrUX) i obejmują ostatnie 28 dni; dane PSI odświeżają się codziennie.
- Wynik Lighthouse: 90 i więcej to dobry, 50-89 wymaga poprawy, poniżej 50 jest słaby.
- Progi Core Web Vitals dla danych z pola: LCP do 2500 ms, INP do 200 ms, CLS do 0,1 - oceniany jest 75. centyl.
- Lighthouse symuluje na telefonie urządzenie średniej klasy (Moto G4) w sieci komórkowej, na komputerze emulowany pulpit z łączem przewodowym.
- Dokumentacja PSI nie opisuje wpływu wyników na pozycje w Google, więc nie traktuj jej jako źródła takich wniosków.
Dwa wyniki w PageSpeed Insights: skąd się biorą
Według dokumentacji PSI zawiera dane z laboratorium i z pola. Różnią się metodą zbierania, a przez to i zastosowaniem.
| Dane z pola | Dane laboratoryjne | |
|---|---|---|
| Źródło | raport Chrome User Experience (CrUX) | Lighthouse |
| Co mierzy | rzeczywistych użytkowników, ich urządzenia i sieci | symulowane wczytanie na jednym urządzeniu i stałych warunkach sieci |
| Okres | poprzednie 28 dni | pojedynczy przebieg |
| Do czego służy | rejestrowanie wrażeń prawdziwych użytkowników | debugowanie w środowisku kontrolowanym |
| Ograniczenie | węższy zestaw danych, wymaga odpowiedniej liczby próbek | może nie odzwierciedlać wąskich gardeł z realnego środowiska |
Dokumentacja zaznacza też, że dobre dane laboratoryjne niekoniecznie oznaczają równie dobre wrażenia prawdziwych użytkowników.
Dane z pola: CrUX, 28 dni i trzy wskaźniki Core Web Vitals
Ocena wrażeń użytkowników w PSI opiera się na zbiorze CrUX. Narzędzie raportuje FCP, INP, LCP i CLS z poprzednich 28 dni, a dodatkowo eksperymentalny wskaźnik TTFB. Za Podstawowe wskaźniki internetowe (Core Web Vitals) dokumentacja uznaje INP, LCP i CLS.
PSI jest odświeżane codziennie. Zbiór CrUX w BigQuery aktualizuje się co miesiąc i jest ograniczony do danych na poziomie źródła (całej witryny). Oba obejmują ostatnie 28-dniowe okresy. Jeśli porównujesz liczby z PSI i z BigQuery, możesz więc widzieć różnice wynikające z częstotliwości odświeżania i poziomu agregacji.
Progi ocen
PSI ocenia jakość wrażeń na trzech poziomach: Dobra, Wymagana poprawa i Słaba. Progi ustawia zgodnie z inicjatywą Podstawowe wskaźniki internetowe.
| Wskaźnik | Dobry | Wymaga poprawy | Niski |
|---|---|---|---|
| FCP | do 1800 ms | 1800-3000 ms | ponad 3000 ms |
| LCP | do 2500 ms | 2500-4000 ms | ponad 4000 ms |
| INP | do 200 ms | 200-500 ms | ponad 500 ms |
| CLS | do 0,1 | między 0,1 a 0,25 | ponad 0,25 |
| TTFB (eksperymentalnie) | do 800 ms | 800-1800 ms | ponad 1800 ms |
Przy CLS polska wersja dokumentacji jest w tym miejscu nieczytelna (to tłumaczenie wygenerowane przez AI), więc pewne są wartości graniczne 0,1 i 0,25. Jeśli masz wątpliwość, sprawdź oryginał po angielsku.
Dlaczego 75. centyl
Nad słupkami rozkładu PSI podaje 75. centyl wszystkich danych. Google tłumaczy to tak: chodzi o to, by strony działały dobrze dla większości użytkowników, także w najtrudniejszych warunkach urządzenia i sieci. Wartość 75. centyla jest klasyfikowana tymi samymi progami co w tabeli wyżej.
Słupki zielony, bursztynowy i czerwony pokazują rozkład. Przykład z dokumentacji: 11 proc. na bursztynowym słupku LCP oznacza, że 11 proc. zaobserwowanych wartości LCP mieści się między 2500 a 4000 ms.
Kiedy ocena Core Web Vitals jest zaliczona
Agregację (dla strony albo całego źródła) PSI uznaje za zaliczoną, gdy 75. centyl każdego z trzech wskaźników jest dobry. Dokumentacja opisuje też przypadki brzegowe:
- Gdy brakuje wystarczających danych INP, ocena jest zaliczona, jeśli 75. centyle LCP i CLS są dobre.
- Gdy brakuje wystarczających danych LCP albo CLS, PSI nie może zsumować danych na poziomie strony ani źródła.
- Gdy nie ma żadnego z powyższych warunków spełnionych, agregacja nie przechodzi oceny.
W praktyce jeden słaby wskaźnik wystarczy, żeby ocena była niezaliczona, nawet gdy dwa pozostałe są zielone.
Wynik Lighthouse: co oznacza 90, 50 i warunki testu
Sekcja diagnostyki laboratoryjnej korzysta z Lighthouse. Analizuje podany adres URL w symulowanym środowisku w czterech kategoriach: wydajność, dostępność, sprawdzone metody i SEO. U góry widzisz wynik każdej z nich.
- 90 lub więcej: wynik prawidłowy.
- 50-89: wymaga poprawy.
- Poniżej 50: wynik słaby.
W kategorii Wydajność dostajesz też listę wskaźników: FCP, LCP, indeks szybkości, CLS, czas do pełnej interaktywności i całkowity czas blokowania. Każdy ma ikonę: zielony okrąg to dobry wynik, pomarańczowy kwadrat oznacza wymaganą poprawę, a czerwony trójkąt ostrzegawczy wynik niski. Pod spodem są audyty z wskazówkami, co poprawić; szczegóły poszczególnych audytów opisuje dokumentacja Lighthouse.
W jakich warunkach Lighthouse testuje
Według dokumentacji Lighthouse symuluje wczytanie strony:
- na telefonie: na urządzeniu średniej klasy (Moto G4) w sieci komórkowej,
- na komputerze: na emulowanym komputerze z połączeniem przewodowym.
Test jest uruchamiany w jednym z regionów: Azja, Europa lub Ameryka Północna. Lokalizację sprawdzisz w bloku środowiska w raporcie Lighthouse. To ważne, bo twoi użytkownicy mogą mieć szybsze albo wolniejsze urządzenia i łącza niż ten model testowy.
Dlaczego wyniki się różnią i dlaczego zmieniają się bez zmian na stronie
Dokumentacja podaje wprost powód rozbieżności. Dane z pola to historyczny raport skuteczności danego adresu, zanonimizowany i zebrany od użytkowników na różnych urządzeniach i w różnych warunkach sieci. Dane laboratoryjne to jedno symulowane wczytanie na jednym urządzeniu i stałym zestawie warunków. Nic dziwnego, że liczby nie są identyczne.
Drugi przypadek to wahania między kolejnymi przebiegami testu, gdy na stronie nic nie zmieniłeś. Dokumentacja wymienia popularne źródła zmienności:
- dostępność sieci lokalnej,
- dostępność sprzętu klienta,
- rywalizacja o zasoby klienta.
Jeśli porównujesz wyniki przed i po zmianie, jedno uruchomienie nie wystarczy. Uruchom test kilka razy i nie wyciągaj wniosków z różnicy kilku punktów. Liczba uruchomień nie wynika z dokumentacji, to moja praktyczna rada oparta na opisanej zmienności.
Który wynik liczy się w Google
Dokumentacja PSI nie mówi, jak wyniki wpływają na pozycje w wyszukiwarce, więc w tej sprawie nie mam z niej twardej odpowiedzi. Mówi natomiast, że ocena Core Web Vitals (INP, LCP, CLS) powstaje z danych o rzeczywistych użytkownikach, a nie z symulacji. Wniosek na użytek pracy: jeśli chcesz wiedzieć, czy strona jest dobra dla ludzi, patrz na dane z pola i 75. centyl. Wynik Lighthouse traktuj jako narzędzie diagnostyczne.
O progach Core Web Vitals w kontekście oceny strony przez Google piszę szerzej w tekście Pozycjonowanie strony w 2026: co ocenia Google, progi Core Web Vitals i plan na miesiąc.
Zielone 90+ w Lighthouse nie gwarantuje dobrych wrażeń prawdziwych użytkowników, o czym ostrzega sama dokumentacja. Zanim zainwestujesz godziny w poprawianie punktów, sprawdź, czy dane z pola w ogóle pokazują problem na LCP, INP albo CLS.
Brak danych z pola: co to znaczy i co możesz zrobić
Czasem sekcja z danymi użytkowników jest pusta albo pokazuje tylko wynik dla całej witryny. Według dokumentacji dzieje się tak w dwóch krokach:
- Strona może mieć za mało danych, gdy została niedawno opublikowana albo ma za mało próbek od rzeczywistych użytkowników. Wtedy PSI przechodzi do szczegółowości na poziomie źródła, czyli łącznych wrażeń na wszystkich stronach witryny.
- Źródło też może mieć za mało danych. Wtedy PSI nie pokaże żadnych danych o wrażeniach użytkowników.
Raport CrUX wymaga także, aby adres URL był publiczny (możliwy do pobrania i zindeksowania) oraz miał wystarczającą liczbę różnych próbek. Jeśli strona jest zablokowana przed robotami albo nie trafiła do indeksu, danych z pola możesz po prostu nie zobaczyć. Zobacz, jak działa plik robots.txt i indeksowanie strony w Google, a stan indeksacji konkretnego adresu sprawdzisz w Google Search Console.
W takiej sytuacji zostaje ci wynik Lighthouse, ale pamiętaj o jego ograniczeniach opisanych wyżej.
Jak czytać raport w praktyce
Kolejność, którą proponuję na podstawie opisu raportu:
- Sprawdź, czy sekcja danych użytkowników w ogóle się wyświetla i na jakim poziomie (strona czy źródło).
- Zobacz, czy ocena Core Web Vitals jest zaliczona, i który z trzech wskaźników ją psuje.
- Spójrz na rozkład słupków: ile procent doświadczeń trafia w czerwony pas.
- Dopiero potem zejdź do Lighthouse i audytów, by znaleźć konkretną przyczynę.
- Po wprowadzeniu poprawek pamiętaj, że dane z pola obejmują 28 dni, więc zmiana nie pojawi się natychmiast w całości.
Ostatni punkt wynika z okna 28 dni opisanego w dokumentacji: stare, wolne wizyty znikają z raportu stopniowo.
Czy TTFB wchodzi do Core Web Vitals?
Nie. Dokumentacja PSI wymienia jako Podstawowe wskaźniki internetowe INP, LCP i CLS. TTFB jest raportowany jako wskaźnik eksperymentalny, z progami 800 ms (dobry) i 1800 ms (słaby).
Czy polska wersja dokumentacji PSI jest wiarygodna?
Strona w Google for Developers ma adnotację, że tłumaczenia AI mogą zawierać błędy. W tabeli progów CLS widać to wyraźnie, więc przy wątpliwościach porównaj z wersją angielską.
Gdzie zadać pytanie o PageSpeed Insights?
Dokumentacja kieruje pytania o konkretne użycie narzędzia na Stack Overflow, po angielsku. Ogólne opinie można zgłaszać na liście adresowej, a pytania o dane wskaźników internetowych w grupie web-vitals-feedback.
Czy wynik Lighthouse może się różnić na telefonie i komputerze?
Tak, bo testy używają różnych symulowanych warunków: urządzenia średniej klasy (Moto G4) w sieci komórkowej dla telefonów oraz emulowanego komputera z łączem przewodowym dla pulpitu.
Źródła
- O narzędziu PageSpeed Insights - Google for Developers - dostęp 31.10.2026
Widzisz błąd albo nieaktualną liczbę? Napisz: kontakt. Poprawki opisuję w tekście z datą.
Autor i wydawca Algorytmika. Od lat pisze o wyszukiwarkach, AI i mediach społecznościowych, a na co dzień prowadzi serwisy, które żyją z ruchu z Google, Discover i sociali. Każdą liczbę w tekstach podpina pod źródło.
Jak pracuję i skąd biorę dane →
