PageSpeed Insights i Google Search Console mierzą szybkość strony na różne sposoby. PageSpeed Insights pokazuje dla jednego adresu URL dwa rodzaje danych: dane z testu laboratoryjnego (Lighthouse), wykonywanego w chwili sprawdzania na symulowanym urządzeniu, oraz dane od prawdziwych użytkowników z raportu Chrome UX Report (CrUX), jeśli jest ich wystarczająco dużo. Google Search Console pokazuje wyłącznie dane od użytkowników z ostatnich 28 dni, zbiorczo dla grup podobnych podstron w całym serwisie. Dlatego wynik „45/100” w PageSpeed Insights i status „Dobry” w Search Console mogą występować jednocześnie i nie są ze sobą sprzeczne.
Ten artykuł jest skierowany do właścicieli stron, marketerów, specjalistów SEO i programistów, którzy widzą różne wyniki w obu narzędziach i nie wiedzą, któremu wierzyć. Wyjaśniamy, skąd biorą się dane, dlaczego się różnią, które z nich mają znaczenie dla pozycji w Google i jak korzystać z obu narzędzi, żeby rzeczywiście przyspieszyć stronę.
Czym jest PageSpeed Insights i co dokładnie mierzy?
PageSpeed Insights (PSI) to bezpłatne narzędzie Google, które analizuje wydajność pojedynczego adresu URL na urządzeniach mobilnych i komputerach. Raport składa się z dwóch niezależnych części, które łatwo ze sobą pomylić.
Dane od użytkowników (field data)
Górna część raportu, oznaczona jako ocena wskaźników Core Web Vitals, pochodzi z Chrome UX Report (CrUX). To zbiór anonimowych pomiarów od użytkowników przeglądarki Chrome, którzy odwiedzali stronę w ciągu ostatnich 28 dni. Wyniki podawane są jako 75. percentyl, co oznacza, że 75% wizyt było tak szybkich lub szybszych.
Jeśli dany adres URL nie ma wystarczającego ruchu, PSI pokazuje dane dla całej domeny (origin), a przy bardzo małych serwisach nie pokazuje danych od użytkowników wcale. To częsta sytuacja w przypadku nowych stron i podstron o niewielkiej liczbie odwiedzin.
Dane laboratoryjne (lab data)
Dolna część raportu, z wynikiem od 0 do 100, pochodzi z Lighthouse, czyli testu wykonywanego na żądanie. Serwer Google ładuje stronę w kontrolowanych warunkach: na symulowanym, średniej klasy telefonie, z ograniczoną przepustowością sieci i spowolnionym procesorem.
Wynik wydajności to średnia ważona kilku metryk. W aktualnej wersji Lighthouse największe wagi mają:
- Total Blocking Time (TBT) – ok. 30%,
- Largest Contentful Paint (LCP) – ok. 25%,
- Cumulative Layout Shift (CLS) – ok. 25%,
- First Contentful Paint (FCP) i Speed Index – po ok. 10%.
Wagi zmieniają się wraz z kolejnymi wersjami Lighthouse, dlatego warto sprawdzać je w aktualnej dokumentacji. Dużą zaletą części laboratoryjnej jest lista konkretnych zaleceń, np. zmniejszenie nieużywanego JavaScriptu, kompresja obrazów czy usunięcie zasobów blokujących renderowanie.
Jak czytać raport PageSpeed Insights?
Wiele osób patrzy tylko na kolorowy wynik 0–100 i pomija ważniejszą informację. Raport najlepiej czytać w tej kolejności:
- Sprawdź, czy są dane od użytkowników i czy dotyczą tego adresu URL, czy całej domeny.
- Oceń Core Web Vitals – komunikat o zaliczeniu lub niezaliczeniu oceny jest bliższy temu, co widzi Google, niż wynik liczbowy.
- Przełącz widok mobilny i komputerowy – wyniki często różnią się znacząco.
- Dopiero potem przejdź do diagnostyki laboratoryjnej i zaleceń posortowanych według szacowanego wpływu na szybkość.
Jak Google Search Console mierzy szybkość strony?
Google Search Console mierzy szybkość w raporcie Podstawowe wskaźniki internetowe (Core Web Vitals). Korzysta wyłącznie z danych od prawdziwych użytkowników z Chrome UX Report i nie wykonuje testów laboratoryjnych.
Raport ocenia trzy wskaźniki Core Web Vitals, z progami dla 75. percentyla wizyt:
- LCP (Largest Contentful Paint) – czas wyświetlenia największego elementu treści: dobry do 2,5 s, słaby powyżej 4 s,
- INP (Interaction to Next Paint) – czas reakcji strony na interakcje użytkownika: dobry do 200 ms, słaby powyżej 500 ms,
- CLS (Cumulative Layout Shift) – stabilność układu podczas ładowania: dobry do 0,1, słaby powyżej 0,25.
INP zastąpił wcześniej stosowany wskaźnik FID, więc starsze poradniki mogą opisywać nieaktualny zestaw metryk.
Grupy adresów URL zamiast pojedynczych stron
Jedną z najważniejszych cech raportu w Search Console jest grupowanie adresów URL. Google łączy podstrony o podobnej strukturze i podobnych wynikach, np. wszystkie karty produktów czy wpisy blogowe, i przypisuje całej grupie jeden status: „Dobry”, „Wymaga poprawy” albo „Słaby”.
Status grupy wyznacza najsłabszy wskaźnik. Jeśli LCP i INP są dobre, a CLS słaby, cała grupa trafia do kategorii „Słaby”. Raport jest prowadzony osobno dla urządzeń mobilnych i komputerów.
Search Console pokazuje też zmiany w czasie, co pozwala zauważyć pogorszenie po wdrożeniu nowego szablonu, wtyczki czy skryptu reklamowego. Nie podaje natomiast wyniku 0–100 ani szczegółowych rekomendacji technicznych.
Dlaczego w Search Console brakuje danych o szybkości?
Komunikat o braku wystarczających danych oznacza, że strona nie ma w Chrome UX Report dość pomiarów od użytkowników. Dotyczy to najczęściej nowych serwisów, stron firmowych o niewielkim ruchu i witryn, na które użytkownicy wchodzą głównie z innych przeglądarek niż Chrome.
Brak raportu nie jest karą ani błędem technicznym. Google nie ma po prostu danych, na których mógłby oprzeć ocenę. Szybkość takiej strony można kontrolować testami laboratoryjnymi w PageSpeed Insights i własnymi pomiarami na urządzeniach docelowych klientów.
PageSpeed Insights a Google Search Console – najważniejsze różnice
Oba narzędzia korzystają częściowo z tego samego źródła danych, lecz odpowiadają na inne pytania. PageSpeed Insights pokazuje, jak zachowuje się konkretna strona i co można w niej poprawić. Search Console przedstawia natomiast szybkość całego serwisu z perspektywy realnych użytkowników.
Najważniejsze różnice:
- Źródło danych – PSI łączy dane od użytkowników (CrUX) z testem laboratoryjnym (Lighthouse), GSC korzysta tylko z danych od użytkowników.
- Zakres analizy – PSI bada jeden adres URL naraz, GSC ocenia cały serwis podzielony na grupy podobnych stron.
- Czas pomiaru – test laboratoryjny w PSI pokazuje stan „tu i teraz”, a dane od użytkowników w obu narzędziach obejmują ostatnie 28 dni.
- Forma wyniku – PSI podaje wynik 0–100 i wartości metryk, GSC pokazuje statusy i liczbę adresów URL w każdej kategorii.
- Metryki – test laboratoryjny nie mierzy INP, bo wymaga on prawdziwych interakcji, więc w jego miejscu pojawia się TBT jako wskaźnik zastępczy.
- Rekomendacje – PSI podaje listę konkretnych usprawnień, GSC wskazuje jedynie, który wskaźnik jest problemem i których grup adresów dotyczy.
- Dostęp – PSI działa dla każdej publicznej strony bez logowania, GSC wymaga zweryfikowania własności witryny.
PSI pełni przede wszystkim funkcję diagnostyczną, przydatną podczas pracy technicznej nad stroną. Search Console służy raczej do monitorowania kondycji całego serwisu przez właściciela strony lub specjalistę SEO.
A czym różni się Lighthouse w przeglądarce Chrome?
Lighthouse jest dostępny także w narzędziach deweloperskich Chrome, w zakładce Lighthouse. Wykorzystuje ten sam silnik co część laboratoryjna PageSpeed Insights, ale test odbywa się na Twoim komputerze i z Twoim połączeniem internetowym.
Wynik może się więc różnić od PSI, ponieważ wpływają na niego moc procesora, rozszerzenia przeglądarki, otwarte karty i jakość łącza. Test lokalny sprawdza się podczas pracy nad stroną, np. na wersji testowej niedostępnej publicznie. Do porównań w czasie lepiej używać PSI, gdzie warunki testu są bardziej powtarzalne. Przed lokalnym pomiarem warto wyłączyć rozszerzenia lub skorzystać z okna incognito.
Dlaczego wyniki w PageSpeed Insights i Search Console się różnią?
Różnice między narzędziami są normalne i wynikają ze sposobu zbierania danych. Kilka przyczyn pojawia się szczególnie często:
- Laboratorium kontra rzeczywistość – Lighthouse testuje stronę na symulowanym, wolniejszym telefonie i sieci. Jeśli większość Twoich użytkowników korzysta z nowych smartfonów i szybkiego internetu, dane z CrUX będą lepsze niż wynik testu.
- Pierwsza wizyta kontra powroty – test laboratoryjny zawsze ładuje stronę „na zimno”, bez pamięci podręcznej. Użytkownicy wracający do serwisu mają część zasobów w cache, więc ich doświadczenie jest szybsze.
- Pojedynczy URL kontra grupa – w PSI sprawdzasz np. stronę główną, a w Search Console widzisz ocenę całej grupy, która może obejmować setki podobnych podstron.
- Opóźnienie danych – po wdrożeniu poprawek test laboratoryjny pokaże zmianę od razu, a dane od użytkowników będą się poprawiać stopniowo przez kolejne 28 dni.
- Zmienność testu – wynik Lighthouse może różnić się o kilka lub kilkanaście punktów między kolejnymi pomiarami, np. przez obciążenie serwera, reklamy czy skrypty zewnętrzne.
- Elementy zależne od użytkownika – banery cookies, personalizacja, testy A/B czy treści ładowane po zalogowaniu działają inaczej w teście niż u prawdziwych odwiedzających.
Przykład z praktyki
Sklep internetowy ma w PageSpeed Insights wynik 38/100 na urządzeniach mobilnych, głównie przez rozbudowane skrypty analityczne i czat. Jednocześnie w Search Console wszystkie grupy adresów mają status „Dobry”, bo klienci korzystają głównie z nowych telefonów, a większość ruchu to powracający użytkownicy.
Nie oznacza to, że niski wynik laboratoryjny można zignorować. Może on sygnalizować problem, który będzie widoczny u użytkowników korzystających z wolniejszych urządzeń lub pojawi się po dodaniu kolejnej wtyczki. Ograniczenie zbędnych skryptów nadal ma więc sens.
Które dane bierze pod uwagę Google przy pozycjonowaniu?
W ocenie jakości strony Google wykorzystuje dane od prawdziwych użytkowników, czyli wskaźniki Core Web Vitals z Chrome UX Report. To te same dane, które widzisz w raporcie Search Console i w górnej części raportu PageSpeed Insights.
Wynik 0–100 z Lighthouse nie jest bezpośrednim czynnikiem rankingowym. To wskaźnik pomocniczy, który ułatwia diagnozę i porównywanie zmian. Strona z wynikiem 60 może mieć dobre Core Web Vitals i odwrotnie.
Szybkość strony jest jednym z wielu sygnałów, a Google wielokrotnie podkreślał, że trafność i jakość treści mają większe znaczenie. Poprawa Core Web Vitals rzadko sama wywinduje stronę na pierwsze miejsce, ale przy podobnej jakości treści może przesądzić o przewadze nad konkurencją. Szybsza strona zwykle poprawia też współczynnik konwersji i zmniejsza liczbę porzuceń, niezależnie od wpływu na pozycje.
Jak korzystać z PageSpeed Insights i Search Console razem?
Oba narzędzia można traktować jako kolejne etapy tego samego procesu. Praca może wyglądać tak:
- Zacznij od Search Console – w raporcie Podstawowe wskaźniki internetowe sprawdź, czy są grupy ze statusem „Słaby” lub „Wymaga poprawy” i którego wskaźnika dotyczą.
- Wybierz przykładowe adresy URL – Search Console podaje przykładowe strony z każdej grupy problemów.
- Przeanalizuj je w PageSpeed Insights – porównaj dane od użytkowników z testem laboratoryjnym i przejrzyj listę zaleceń, np. dotyczących największego elementu LCP albo przesunięć układu.
- Wprowadź poprawki – najpierw w szablonie, który dotyczy całej grupy, a nie pojedynczej podstrony.
- Zweryfikuj efekt w teście laboratoryjnym – ponowny test w PSI szybko pokaże, czy zmiana działa.
- Rozpocznij weryfikację w Search Console – po kliknięciu „Sprawdź poprawkę” Google monitoruje grupę przez ok. 28 dni i potwierdza, czy problem został rozwiązany.
Jakie poprawki najczęściej pomagają?
Przy optymalizacji poszczególnych wskaźników najczęściej stosuje się:
- dla LCP – kompresję i właściwy format głównego obrazu (np. WebP lub AVIF), preload największego elementu, szybszy serwer i CDN,
- dla INP – ograniczenie ciężkiego JavaScriptu, podzielenie długich zadań, opóźnienie ładowania skryptów zewnętrznych, np. czatów i narzędzi marketingowych,
- dla CLS – podawanie wymiarów obrazów i ramek reklamowych, rezerwowanie miejsca na banery, unikanie wstawiania treści nad już wyświetlonymi elementami.
Jakie inne narzędzia warto znać?
PageSpeed Insights i Search Console wystarczają większości właścicieli stron. Przy większych serwisach przydają się również narzędzia uzupełniające:
- WebPageTest – szczegółowe testy laboratoryjne z wyborem lokalizacji, urządzenia i przeglądarki oraz wykresem ładowania każdego zasobu,
- raporty i panele oparte na Chrome UX Report – pozwalają śledzić historię wskaźników domeny w dłuższym okresie niż 28 dni,
- pomiary RUM (Real User Monitoring) – np. biblioteka web-vitals przesyłająca wyniki do systemu analitycznego. Daje dane od wszystkich użytkowników, nie tylko z Chrome, i pozwala analizować je według podstron, urządzeń czy źródeł ruchu.
Własne pomiary RUM są szczególnie przydatne, gdy trzeba szybko sprawdzić efekt wdrożenia bez czekania na aktualizację danych w Chrome UX Report.
Najczęstsze błędy w interpretacji wyników
Przy analizowaniu wyników PageSpeed Insights i Search Console powtarza się kilka nieporozumień:
- Pogoń za wynikiem 100/100 – maksymalny wynik w Lighthouse rzadko jest realny dla rozbudowanych serwisów i nie przekłada się automatycznie na lepsze pozycje. Ważniejsze jest przejście progów „dobrych” wartości Core Web Vitals.
- Ocena całego serwisu na podstawie strony głównej – strona główna często jest najlepiej zoptymalizowana, a problemy dotyczą np. kart produktów czy listingów kategorii.
- Porównywanie pojedynczych testów – różnica kilku punktów między dwoma pomiarami to zwykle efekt zmienności testu, a nie realnej zmiany. Lepiej wykonać kilka pomiarów i patrzeć na medianę.
- Oczekiwanie natychmiastowej zmiany w Search Console – dane od użytkowników aktualizują się stopniowo, a pełny efekt poprawek widać po ok. 28 dniach.
- Mylenie widoku mobilnego i komputerowego – Google ocenia je osobno, a wyniki mobilne są zwykle wyraźnie słabsze.
- Brak danych potraktowany jako problem – jeśli strona ma mały ruch, Search Console może nie pokazywać raportu. Wtedy można opierać się na testach laboratoryjnych i własnych pomiarach, np. z biblioteki web-vitals zapisującej wyniki w analityce.
Różnica między PageSpeed Insights a Google Search Console sprowadza się do tego, że pierwsze narzędzie służy do diagnozy konkretnej strony, a drugie do monitorowania doświadczeń prawdziwych użytkowników w całym serwisie. Dane z Search Console pozwalają wskazać problemy widoczne w rzeczywistym ruchu, natomiast PageSpeed Insights pomaga znaleźć ich techniczne przyczyny i szybko sprawdzić efekt wprowadzonych zmian.
analityk marketingowy
Specjalista marketingu internetowego z doświadczeniem sięgającym 2004 roku, kiedy rozpoczął pracę nad pozycjonowaniem serwisów WWW. Od 2014 roku ekspert na oficjalnym polskim forum Google. Jako jeden z pierwszych wdrażał zaawansowane rozwiązania analityczne oparte na Google Tag Managerze.
- E-mail: adam@wildmoose.pl
- Telefon: +48 500 405 405
W końcu zrozumiałem, dlaczego wysoki wynik testu nie musi oznaczać dobrych Core Web Vitals.
Najbardziej przydatne było wyjaśnienie różnicy między danymi laboratoryjnymi a rzeczywistymi wizytami użytkowników. Wcześniej łatwo było porównywać te wartości tak, jakby mierzyły dokładnie to samo.
Dobrze opisano, że Search Console może oceniać całą grupę podobnych adresów, a pokazany URL jest tylko przykładem. To zmienia podejście do szukania problemu, bo zamiast poprawiać jedną podstronę trzeba sprawdzić wspólny szablon.
Informacja o 28-dniowym okresie danych terenowych dobrze tłumaczy, czemu efekt optymalizacji nie pojawia się od razu.
PageSpeed Insights i Google Search Console traktowałem wcześniej trochę zamiennie. Tutaj jasno pokazano, że pierwsze narzędzie lepiej nadaje się do diagnozowania konkretnej strony, a drugie do sprawdzania skali problemu w całym serwisie.
Dla mnie ważne było zwrócenie uwagi na 75. percentyl. Sam fakt, że strona działa szybko na moim komputerze, nie mówi jeszcze wiele o doświadczeniach osób korzystających ze słabszych telefonów i wolniejszych sieci.
Przydatna jest też uwaga, żeby osobno analizować mobile i desktop. Wyniki dla obu urządzeń potrafią przecież wyglądać zupełnie inaczej.
Dobrze, że wyjaśniono również sytuację, gdy dane dotyczą całej domeny, a nie konkretnego adresu. Łatwo przeoczyć oznaczenie origin i później wyciągać błędne wnioski z wartości pokazanych przy jednej podstronie.
Najbardziej praktyczna jest kolejność pracy: najpierw znaleźć problematyczną grupę, potem sprawdzić kilka stron korzystających z tego samego rozwiązania i dopiero poprawiać komponent lub szablon. To dużo bardziej logiczne niż gonienie za wynikiem 100 punktów na stronie głównej.
PageSpeed Insights jest tu dobrze pokazany jako narzędzie diagnostyczne, a nie po prostu generator jednej liczby od 0 do 100. Szczególnie przydatna jest lista rzeczy do sprawdzenia: obrazy, JavaScript, CSS, serwer i przesunięcia układu.
Warto było przeczytać fragment o LCP, INP i CLS, bo punktacja Lighthouse często odciąga uwagę od samych metryk. Teraz znacznie łatwiej rozdzielić ocenę laboratoryjną od tego, co rzeczywiście jest mierzone u użytkowników.
Najwięcej uporządkowała mi część o rozbieżnych wynikach. Dobry test wykonany w kontrolowanych warunkach nie oznacza automatycznie, że użytkownicy na starszych urządzeniach, słabszym internecie czy w innych lokalizacjach mają takie samo doświadczenie. Z drugiej strony pojedynczy słabszy pomiar laboratoryjny też nie musi oznaczać problemu całego serwisu. Sensowne jest więc patrzenie na kilka pomiarów, dane historyczne i powtarzające się problemy, zamiast reagowania na każdą zmianę kilku punktów.