PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) to bezpłatne narzędzie Google, które ocenia stronę na dwa różne sposoby: pokazuje, jak faktycznie doświadczyli jej rzeczywiści odwiedzający (dane terenowe), oraz jak wypadł pojedynczy symulowany test (wynik laboratoryjny 0–100). To liczba 0–100, którą wszyscy się obsesyjnie przejmują — i nie ona służy Google do rankingu. Nie panikuj więc z powodu czerwonego wyniku.

Czym jest PageSpeed Insights

PageSpeed Insights działa pod adresem pagespeed.web.dev. Jest bezpłatne, nie wymaga logowania i działa dla każdego publicznego URL-a — także URL-i konkurentów. Wklejasz URL, a narzędzie testuje zarówno urządzenia mobilne, jak i desktop (mobilna karta jest domyślna, a wyniki mobilne są prawie zawsze niższe).

Dwie rzeczy pokazywane przez PSI

To część, która myli wszystkich, więc ujmę ją prosto. PSI pokazuje dwa osobne raporty dla tej samej strony:

1. Dane terenowe — czego doświadczyli prawdziwi ludzie. Pochodzą z Chrome UX Report (CrUX), czyli od prawdziwych użytkowników Chrome odwiedzających stronę w ciągu ostatnich 28 dni. To sekcja oznaczona „Discover what your real users are experiencing”. Właśnie tu znajdziesz Core Web Vitals Assessment — proste Passed albo Failed.
2. Dane laboratoryjne — jeden test symulowany. PSI uruchamia też raz Google Lighthouse na symulowanym telefonie i połączeniu sieciowym, po czym zwraca wynik Performance 0–100 oraz listę sugerowanych poprawek.

Jedna rzecz do zapamiętania

Wynik 0–100 nie jest czynnikiem rankingowym. Google pozycjonuje na podstawie terenowych Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift — mierzonych u rzeczywistych użytkowników. Wynik laboratoryjny 0–100 to osobna liczba z osobnego systemu. Możesz uzyskać 72 i nadal zaliczyć Core Web Vitals.

Kilka innych rzeczy też często wprowadza w błąd:

• Wynik zmienia się przy każdym uruchomieniu. To jeden test symulowany, więc liczba się waha. Uruchom go kilka razy i nie wyciągaj wniosków ze zmiany o 3–5 punktów.
• Nie potrzebujesz 100. Niemal nikt nie uzyskuje 100. Celuj w zaliczenie Core Web Vitals, a nie w idealną liczbę.
• Dobry wynik nie gwarantuje szybkiej strony dla rzeczywistych użytkowników, a „zły” wynik nie oznacza, że prawdziwi użytkownicy cierpią.

Szczerze mówiąc, jeśli witryna nie jest rzeczywiście wolna, nie od tego bym zaczynał. Chcesz pełnego omówienia — danych terenowych i laboratoryjnych, progów p75, fallbacków danych oraz różnic między PSI, Lighthouse i Search Console? Przejdź do karty Advanced.

TL;DR — PSI (pagespeed.web.dev) raportuje dwie niezależne analizy jednego URL-a: dane terenowe z Chrome UX Report — rzeczywistych użytkowników z kroczącego okresu 28 dni, które napędzają Core Web Vitals Assessment Passed/Failed na p75 — oraz dane laboratoryjne, czyli pojedynczy test Lighthouse dający wynik Performance 0–100 i diagnostykę. Wynik 0–100 jest danymi laboratoryjnymi i nie jest czynnikiem rankingowym; ranking korzysta z terenowych Core Web Vitals (LCP/INP/CLS). Dane terenowe wymagają odpowiedniej liczby próbek CrUX (najpierw poziom URL-a, potem originu, a w przeciwnym razie „No data”). Wynik laboratoryjny również zmienia się między uruchomieniami — wykonaj kilka testów. PSI to interfejs WWW; Lighthouse to silnik; raport Search Console to jeszcze jeden widok danych CrUX.

PSI to dwa narzędzia w jednym płaszczu

Najważniejszą rzeczą do zrozumienia o PageSpeed Insights jest to, że nie jest to jedna analiza — są to dwie analizy pokazane w jednym interfejsie. web.dev ujmuje to jasno: “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” („PSI to narzędzie raportujące dane terenowe z CrUX i dane laboratoryjne z Lighthouse dla danej strony”). Te połówki pochodzą z różnych systemów, mierzą różne rzeczy i mają znaczenie z różnych powodów. Połącz je, a niemal każde pytanie o PSI stanie się mylące; rozdziel je, a wszystko zacznie być jasne.

Dane terenowe: czego doświadczyli prawdziwi użytkownicy

Górna sekcja — „Discover what your real users are experiencing” — korzysta z Chrome UX Report (CrUX). web.dev opisuje API CrUX jako zapewniające “low-latency access to aggregated real-user experience data at page and origin granularity” („niskolatencyjny dostęp do zagregowanych danych doświadczeń rzeczywistych użytkowników na poziomie strony i originu”) w postaci “28-day rolling average” („kroczącej średniej z 28 dni”). PSI aktualizuje dane codziennie; zbiór danych CrUX w BigQuery jest publikowany co miesiąc.

Kilka mechanizmów, które mają znaczenie:

• Core Web Vitals Assessment jest Passed/Failed na poziomie p75. Dokumentacja Chrome mówi: “to pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” („aby zaliczyć, percentyl musi być sklasyfikowany jako „good” dla wszystkich trzech Core Web Vitals. W przeciwnym razie ocena ma status „failed””). Są to Largest Contentful Paint (good < 2,5 s), Interaction to Next Paint (good < 200ms) i Cumulative Layout Shift (good < 0,1). PSI pokazuje też FCP i TTFB jako „Other metrics” — są informacyjne, ale nie należą do werdyktu.
• Istnieje jeden udokumentowany wyjątek i dotyczy wyłącznie INP. Jeśli strona nie ma dość próbek CrUX, aby zaraportować INP, aktualny przewodnik PSI mówi, że nadal może ocenić Pass/Fail na podstawie dobrych wartości p75 LCP i CLS. Nie ma równoważnego wyjątku dla LCP ani CLS — jeśli któregokolwiek z nich brakuje z powodu niewystarczających danych, nie odczytuj tego jako zaliczenia; niewystarczające dane nie są udokumentowanym bezpłatnym zaliczeniem żadnej metryki poza INP.
• p75 oznacza 75. percentyl. Pokazana wartość opisuje doświadczenie, w którym 75% odsłon strony było szybszych. web.dev wybrał 75. percentyl, ponieważ jest “resistant to outliers” („odporny na wartości odstające”) — to cel surowszy niż mediana.
• INP zastąpił FID w marcu 2024 r. Jeśli oglądasz stare zrzuty ekranu lub poradniki (w tym moje starsze teksty Ahrefs o PageSpeed Insights i Core Web Vitals), mogą nadal pokazywać FID; ocena korzysta obecnie z INP.
• Fallback URL → origin → „No data”. Jeśli dla konkretnego URL-a nie ma dość danych CrUX, PSI przechodzi na dane poziomu originu (zagregowane dla całej witryny). Jeśli danych CrUX nie ma w ogóle, zobaczysz „No data”, ale Lighthouse nadal się uruchomi. Jak zauważa web.dev, “CrUX data is only available when sites meet certain eligibility criteria” („dane CrUX są dostępne tylko wtedy, gdy witryny spełniają określone kryteria kwalifikacji”) oraz “PSI is only available for public URLs.” („PSI jest dostępne tylko dla publicznych URL-i”). Strony o małym ruchu i zupełnie nowe często nie mają terenowych danych na poziomie URL-a.

Przed zapisaniem wniosku przeczytaj etykietę zakresu. CrUX na poziomie URL-a opisuje kwalifikującą się próbkę terenową przypisaną do tego URL-a. Fallback na poziomie originu jest użytecznym sygnałem dla całej witryny, ale sam nie może diagnozować testowanej strony. „No data” oznacza, że próbka terenowa jest niedostępna lub niewystarczająca — nie że strona zaliczyła, nie zaliczyła albo nie otrzymała ruchu. Wynik Lighthouse poniżej może nadal diagnozować kontrolowany test laboratoryjny, ale nie uzupełnia braku danych terenowych.

Dane laboratoryjne: wynik Lighthouse 0–100

Dolna sekcja to pojedynczy test Lighthouse na symulowanym urządzeniu i połączeniu, który generuje wynik Performance oraz listę możliwości i diagnostyki. Przedziały Google: “A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.” („Wynik 90 lub wyższy uznaje się za dobry. Wynik od 50 do 89 wymaga poprawy, a poniżej 50 uznaje się za słaby”).

Co trzeba wiedzieć o teście laboratoryjnym:

• Jest symulowany, a test mobilny jest celowo wolny. Telefon mobilny emuluje urządzenie średniej klasy na ograniczonym łączu; desktop używa szybszego profilu emulacji. Dlatego wynik mobilny prawie zawsze jest niższy od desktopowego — i dlatego dane terenowe od prawdziwych użytkowników często wyglądają lepiej niż sugeruje diagnostyka laboratoryjna.
• Wynik jest zmienny. Każdy test to nowy, wykonywany po stronie serwera audyt Lighthouse — strona, centrum danych Google, warunki sieciowe, a nawet wersja Chrome/Lighthouse mogą zmienić liczbę między uruchomieniami. Zalecam wykonanie kilku testów (3–5) i patrzenie na zakres, zamiast traktować pojedynczy wynik jak ewangelię. Kilka punktów różnicy to szum.
• Przy porównywaniu testów zapisuj więcej niż wynik. Odpowiedź API zawiera znacznik czasu, żądany i końcowy URL, typ urządzenia, emulowane środowisko, wersję Lighthouse i ostrzeżenia — przechowuj je obok każdego wyniku. Dwa wyniki „72” nie są porównywalne, jeśli jeden powstał w innej wersji Lighthouse albo trafił na przekierowanie, którego drugi nie miał. Nie uśredniaj nieopisanych wyników; opisuj je albo nie porównuj.
• Wersje Lighthouse poruszają się niezależnie od API PSI. PSI pozostało przy API v5, ale stojący pod nim silnik Lighthouse nadal dostaje nowe wydania (najpóźniejsza wersja odnotowana w notach wydania Google w tym przeglądzie to Lighthouse 13.0 z datą 2025-10-20) — pola audytu, wagi i przedziały mogą zmieniać się wraz z silnikiem, choć kontrakt API się nie zmienia.
• „Estimated savings” nie sumują się. Sekundy pokazane przy każdej diagnostyce zakładają, że poprawka jest wykonywana osobno. Problemy wzajemnie na siebie wpływają; rzeczywiste korzyści prawie zawsze są mniejsze niż suma pojedynczych szacunków. Traktuj je kierunkowo, a nie jak budżet, który możesz zsumować.
• Wagi metryk zmieniają się z wersjami Lighthouse. Wynik Performance to ważona kombinacja metryk laboratoryjnych (metryki czasu ładowania, Total Blocking Time i CLS mają największą wagę), ale dokładne wagi zmieniają się między wydaniami Lighthouse — sprawdzaj aktualny kalkulator wyników, zamiast ufać stałemu podziałowi.

Mit, który powoduje najwięcej szkód: „wynik jest czynnikiem rankingowym”

Nie jest. Wynik Performance 0–100 to laboratoryjna liczba Lighthouse, a nie znalazłem aktualnego oficjalnego źródła Google Search, które dokumentowałoby ten wynik jako dane wejściowe rankingu lub wiązało zmianę wyniku ze zmianą pozycji. Dokumentacja Google dotycząca jakości strony wskazuje natomiast na terenowe Core Web Vitals — dane CrUX od rzeczywistych użytkowników, czyli ten sam typ danych, który pokazuje terenowa sekcja PSI na poziomie p75. (Warto zachować precyzję: publiczny widok danych terenowych PSI jest powierzchnią raportową z własnymi regułami kwalifikacji i fallbacku; Google nie opublikowało dokładnego wewnętrznego potoku zasilającego ranking, więc traktuj „dane terenowe” jako sygnał tego samego rodzaju, a nie zakładaj identyczności bajt po bajcie z tym, co pokazuje PSI). Strona może mieć w laboratorium wynik 72 i nadal zaliczać Core Web Vitals, bo jej dane rzeczywistych użytkowników są dobre — to różne liczby z różnych systemów. Powiązany mit — „dobry wynik laboratoryjny równa się dobremu doświadczeniu rzeczywistych użytkowników” — jest błędny z tego samego powodu: warunki laboratoryjne nie są warunkami Twoich odwiedzających. Gdy dane terenowe i laboratoryjne się rozchodzą, dane terenowe są ważniejsze dla SEO.

Nawet terenowe Core Web Vitals są dość małym sygnałem rankingowym. Ludzie z Google umniejszali ich znaczenie — Gary Illyes nazwał jakość strony czymś bliższym tie-breakerowi niż dużym sygnałem. Moje uczciwe stanowisko się nie zmieniło: nie sądzę, aby Core Web Vitals miały duży wpływ na SEO, i jeśli witryna nie jest skrajnie wolna, zwykle nie będę traktować ich naprawy priorytetowo przed treścią i linkami. Naprawiaj je dla użytkowników i w rzeczywiście wolnym przypadku — nie z paniki wywołanej czerwoną liczbą.

Jak faktycznie czytać raport PSI

1. Najpierw przeczytaj dane terenowe. Czy ocena Core Web Vitals ma status Pass czy Fail? To werdykt istotny dla SEO. Jeśli widzisz „No data”, nie ma jeszcze wystarczającego ruchu CrUX — pracujesz wyłącznie na danych laboratoryjnych.
2. Osobno sprawdź urządzenia mobilne i desktop. Mobilna karta jest domyślna i zwykle słabsza; ma też większe znaczenie, ponieważ Google indeksuje przede wszystkim wersję mobilną.
3. Następnie użyj diagnostyki laboratoryjnej, aby znaleźć przyczynę. Dane laboratoryjne są szybką pętlą informacji zwrotnej do znajdowania i naprawiania źródłowego problemu — zasobów blokujących renderowanie, zbyt dużych obrazów, przesunięć układu i długich zadań.
4. Napraw, a potem poczekaj. Dane terenowe obejmują kroczące okno 28 dni, więc poprawka wdrożona dziś może być w pełni widoczna w Core Web Vitals Assessment dopiero za 28 dni. Używaj danych laboratoryjnych do natychmiastowego potwierdzenia poprawki; danych terenowych — aby sprawdzić, czy rzeczywiście pomogła realnym użytkownikom.
5. Porównuj konkurentów. Ponieważ PSI działa dla każdego publicznego URL-a, możesz uruchomić test na stronach konkurenta i porównać jego terenowe Core Web Vitals z własnymi — to przypadek użycia, o którym większość poradników nie wspomina.

PSI a narzędzia, z którymi bywa mylone

• PSI a Lighthouse. Lighthouse to silnik; PSI to interfejs WWW, który uruchamia Lighthouse i nakłada na niego terenowe dane CrUX. Uruchamiając Lighthouse samodzielnie (w Chrome DevTools lub CLI), otrzymujesz audyt laboratoryjny na swoim urządzeniu i w swojej sieci, bez danych terenowych.
• PSI a raport Core Web Vitals w Search Console. Oba narzędzia korzystają z CrUX, więc oba odzwierciedlają doświadczenia rzeczywistych użytkowników. Różnica: Search Console grupuje podobne URL-e i raportuje na dużą skalę w całej usłudze, podczas gdy PSI działa dla pojedynczego URL-a (albo korzysta z fallbacku na poziomie originu). Jeśli GSC i PSI wydają się niezgodne, zwykle winne jest grupowanie.
• PSI a Chrome DevTools / WebPageTest / DebugBear / Ahrefs Site Audit. Te narzędzia oferują więcej konfiguracji (własne urządzenia, lokalizacje i ograniczanie sieci), a czasem także monitoring rzeczywistych użytkowników. Siłą PSI jest bezpłatność, brak konfiguracji i powiązanie z własnym zbiorem danych CrUX Google.

API PSI (do testów masowych)

Nie musisz używać interfejsu WWW dla jednego URL-a naraz. API PageSpeed Insights (bazowe https://www.googleapis.com/pagespeedonline/v5) zwraca te same dane programowo. Najważniejsze parametry to url (wymagany), strategy (mobile albo desktop) oraz category (performance, accessibility, best-practices, seo). Odpowiedź dzieli się tak jak interfejs: loadingExperience (terenowe dane na poziomie URL-a), originLoadingExperience (terenowe dane na poziomie originu) i lighthouseResult (audyt laboratoryjny). W ten sposób możesz testować partię URL-i według harmonogramu, zamiast klikać je ręcznie.

Nie buduj trwałej automatyzacji danych terenowych na tym API. Własna dokumentacja API Google zaczyna się teraz od informacji, że planuje zaprzestać dołączania danych rzeczywistych CrUX do API PSI i kieruje automatyzacje do dedykowanego CrUX API albo CrUX History API. Nadal używaj API PSI do laboratoryjnego audytu Lighthouse — ta część nie jest objęta zmianą — ale jeśli planujesz masowe pobieranie danych terenowych, buduj je na API CrUX, a nie na loadingExperience/originLoadingExperience.

Miejsce PSI w wydajności stron

PSI to narzędzie pomiarowe, a nie cel sam w sobie. Pokazywane przez nie metryki — Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift — to Core Web Vitals, a kolejnym miejscem, do którego warto przejść (progi, znaczenie każdej metryki i sposoby poprawy), jest hub poświęcony tym metrykom. Lighthouse to laboratoryjny silnik PSI; CrUX (Chrome UX Report) to źródło danych terenowych zasilających górę każdego raportu PSI. Zrozum te trzy elementy, a PSI przestanie być tajemniczą skrzynką.

Podsumowanie AI

Skrócona wersja sekcji Advanced:

• PSI = dwa narzędzia w jednym interfejsie. Dane terenowe z Chrome UX Report (rzeczywiści użytkownicy) i dane laboratoryjne z pojedynczego testu Lighthouse, dla tego samego URL-a pod adresem pagespeed.web.dev. Bezpłatnie, bez logowania, każdy publiczny URL, urządzenia mobilne + desktop.
• Dane terenowe napędzają Core Web Vitals Assessment — Passed/Failed na 75. percentylu, dla LCP (<2,5 s), INP (<200ms) i CLS (<0,1). Kroczące okno 28 dni, aktualizacja codzienna. FCP i TTFB są pokazywane, ale nie liczą się do werdyktu.
• Dane laboratoryjne to wynik Performance 0–100 (90+ good, 50–89 needs work, <50 poor) i diagnostyka. Mobilny test jest ograniczony i daje niższy wynik niż desktop.
• Wynik 0–100 NIE jest udokumentowany jako czynnik rankingowy. Systemy rankingowe Google korzystają z terenowych Core Web Vitals (danych rzeczywistych z CrUX — tego samego typu, który pokazuje terenowa sekcja PSI, choć Google nie opublikowało dokładnego wewnętrznego potoku jako identycznego z publicznym widokiem PSI). Strona może uzyskać 72 i nadal zaliczyć CWV — to różne liczby z różnych systemów.
• Fallback CrUX: poziom URL-a → poziom originu → „No data” (Lighthouse nadal działa). Strony o małym ruchu i nowe często nie mają danych terenowych na poziomie URL-a.
• Wynik jest zmienny między uruchomieniami — testuj 3–5 razy. „Estimated savings” nie sumują się. Nie potrzebujesz 100.
• Najpierw czytaj dane terenowe (Passed/Failed), a potem użyj diagnostyki laboratoryjnej, aby znaleźć przyczynę; wdroż poprawkę, a następnie poczekaj do 28 dni, aż dane terenowe ją odzwierciedlą.
• PSI a Lighthouse (silnik kontra interfejs + dane terenowe) oraz PSI a raport CWV w Search Console (również CrUX, ale grupowane na dużą skalę). CWV to ogólnie niewielki sygnał rankingowy.

Oficjalna dokumentacja

Dokumentacja źródłowa Google oraz zespołów Chrome / web.dev.

Google / PageSpeed Insights

• Narzędzie PageSpeed Insights — samo narzędzie.
• PageSpeed Insights API — About — działanie PSI, dwa typy danych i przedziały wyniku 0–100.
• PSI API — referencja runPagespeed — parametry (url, strategy, category) i struktura odpowiedzi.

Chrome UX Report (źródło danych terenowych)

• Using CrUX in PageSpeed Insights — wyjaśnienie sekcji terenowej przygotowane przez Chrome.
• Metodologia CrUX — kwalifikacja, zgoda i uwzględniane strony.
• CrUX API — krocząca średnia z 28 dni zasilająca terenowe dane PSI.
• Przegląd CrUX — sposób, w jaki CrUX zasila sygnał jakości strony.

web.dev / Core Web Vitals

• Jakie istnieją narzędzia Core Web Vitals? — miejsce PSI wśród narzędzi CrUX/Lighthouse.
• Core Web Vitals — progi LCP/INP/CLS i reguła 75. percentyla.
• Definiowanie progów Core Web Vitals — dlaczego p75.
• Core Web Vitals i Google Search — kontekst sygnału rankingowego.

Cytaty ze źródła

Dosłowne wypowiedzi, każda połączona z fragmentem na stronie źródłowej.

Google / Chrome / web.dev — jak działa PSI

• “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” („PSI to narzędzie raportujące dane terenowe z CrUX i dane laboratoryjne z Lighthouse dla danej strony”) — web.dev. Przejdź do cytatu
• “PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.” („PSI jest dostępne tylko dla publicznych URL-i. Nie można go używać w witrynach deweloperskich, które nie są publicznie dostępne”) — web.dev. Przejdź do cytatu
• Sekcja terenowa jest opisana jako “Discover what your real users are experiencing.” („Odkryj, czego doświadczają Twoi prawdziwi użytkownicy”). — Chrome for Developers, CrUX in PSI. Przejdź do cytatu
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” („Aby zaliczyć, percentyl musi być sklasyfikowany jako „good” dla wszystkich trzech Core Web Vitals. W przeciwnym razie ocena ma status „failed””). — Chrome for Developers, CrUX in PSI. Przejdź do cytatu
• API CrUX zapewnia “low-latency access to aggregated real-user experience data at page and origin granularity” („niskolatencyjny dostęp do zagregowanych danych doświadczeń rzeczywistych użytkowników na poziomie strony i originu”) w postaci “28-day rolling average.” („kroczącej średniej z 28 dni”). — Chrome for Developers, CrUX API. Przejdź do cytatu

web.dev — progi

• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” („dobrym progiem do pomiaru jest 75. percentyl ładowań stron, podzielony według urządzeń mobilnych i desktopowych”). — web.dev, Core Web Vitals. Przejdź do cytatu
• “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance.” („jeśli co najmniej 75 procent odsłon witryny spełnia próg „good”, witrynę klasyfikuje się jako mającą „good” performance”). — web.dev, defining the thresholds. Przejdź do cytatu

Branża — rozróżnienie wyniku i rankingu (przekazane, nie Google)

• “The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings.” („Wynik Performance w PageSpeed Insights nie wpływa bezpośrednio na SEO. Jednak ocena Core Web Vitals od rzeczywistych użytkowników wpływa na rankingi Google”). — Matt Zeunert, DebugBear. Źródło
• “Core Web Vitals are the only metrics Google explicitly uses for grading.” („Core Web Vitals to jedyne metryki, których Google wyraźnie używa do oceniania”) oraz “Running the same URL just minutes apart can yield different scores.” („Uruchomienie tego samego URL-a w odstępie zaledwie kilku minut może dać różne wyniki”). — Ryan Sullivan, SiteCare. Źródło

Ściąga raportu PSI

Każda sekcja PSI: terenowa czy laboratoryjna i co oznacza

Dobre progi Core Web Vitals (terenowe, p75)

Przedziały wyniku Lighthouse (laboratoryjne)

• 90–100 — good · 50–89 — needs improvement · <50 — poor

Fallback danych terenowych

• CrUX na poziomie URL-a → jeśli danych jest za mało, poziom originu → jeśli nie ma ich wcale, „No data” (Lighthouse nadal działa).

Szybkie fakty

• Dane terenowe = kroczące 28 dni, aktualizowane codziennie → poprawka może być widoczna dopiero po 28 dniach.
• Wynik 0–100 jest zmienny — uruchom test 3–5 razy, ignoruj zmianę o 3–5 punktów.
• „Estimated savings” nie sumują się — zakładają, że każda poprawka jest wykonywana osobno.
• Mobilna karta jest domyślna i zwykle daje wynik niższy niż desktopowa.
• INP zastąpił FID w marcu 2024 r.

Narzędzia wokół PSI

• PageSpeed Insights (pagespeed.web.dev) — samo narzędzie: dane terenowe (CrUX) + laboratoryjne (Lighthouse), mobile i desktop, każdy publiczny URL.
• Google Lighthouse — laboratoryjny silnik uruchamiany przez PSI. Uruchom go lokalnie w Chrome DevTools (panel Lighthouse) albo przez CLI, aby wykonać audyt laboratoryjny na własnym urządzeniu i w sieci (bez danych terenowych).
• Google Search Console — raport Core Web Vitals — drugi widok oparty na CrUX; grupuje podobne URL-e i raportuje dane terenowe w całej usłudze.
• CrUX Vis / CrUX API / BigQuery — bezpośredni dostęp do danych terenowych stojących za PSI w ujęciu trendów. (Stary CrUX Dashboard w Looker Studio wycofano pod koniec listopada 2025 r. — potwierdzają to noty wydania Google i dedykowany wpis o wycofaniu, wskazując CrUX Vis (cruxvis.withgoogle.com) jako zastępstwo. Jeśli poradnik nadal każe używać Dashboardu, jest nieaktualny).
• PSI API — programowe testowanie wielu URL-i (url, strategy, category); odpowiedź dzieli się na loadingExperience, originLoadingExperience i lighthouseResult. Google ogłosiło plan zaprzestania dołączania danych rzeczywistych CrUX do tego API i obecnie zaleca dedykowane CrUX API lub CrUX History API do trwałej automatyzacji danych terenowych — nie buduj potoku zakładającego, że obiekty terenowe API PSI pozostaną długoterminowo.
• Ahrefs Site Audit i WebPageTest / DebugBear — więcej konfiguracji i, w niektórych przypadkach, monitoring rzeczywistych użytkowników poza pojedynczym testem Lighthouse.

Błędy PageSpeed Insights zniekształcające priorytety

• Traktowanie wyniku 0–100 jako czynnika rankingowego. Wynik to jeden test laboratoryjny Lighthouse. Istotna rankingowo ocena Core Web Vitals pochodzi z terenowych danych CrUX.
• Odczytywanie fallbacku originu jako wydajności URL-a. Gdy URL ma za mało próbek, PSI może pokazać dane poziomu originu. Sprawdź etykietę zakresu, zanim stwierdzisz, że sama strona zaliczyła albo nie zaliczyła.
• Reagowanie na pojedynczy test laboratoryjny. Odpowiedź serwera i środowisko syntetyczne się zmieniają. Powtarzaj dopasowane testy i używaj zakresu lub mediany, aby odróżnić sygnał od szumu.
• Dodawanie szacunków oszczędności z możliwości. Szacunki audytu nakładają się i zakładają niezależne poprawki. Traktuj je jako kierunkowe wskazówki, a nie obiecaną sumę.
• Oczekiwanie natychmiastowej zmiany danych terenowych po wdrożeniu. CrUX to kroczący widok 28 dni. Do natychmiastowej diagnozy używaj sekcji laboratoryjnej, a sekcji terenowej do potwierdzenia w czasie.
• Porównywanie wyników mobile i desktop, jakby warunki były identyczne. Oceniaj każdy profil względem niego samego i swoich odbiorców, zamiast traktować liczby jako jedną skalę.

PSI mówi „No data”

Objaw: sekcja terenowa nie ma wyniku CrUX, ale raport Lighthouse działa.

Prawdopodobna przyczyna: URL i origin nie spełniają wymagań kwalifikacji lub wielkości próby CrUX albo strona jest nowa lub ma mały ruch.

Poprawka i potwierdzenie: nie twórz wniosku o danych terenowych. Użyj diagnostyki laboratoryjnej do natychmiastowej pracy, sprawdź reprezentatywne szablony o większym ruchu i wróć później, aby zobaczyć, czy pojawił się wynik terenowy na poziomie URL-a lub originu.

PSI i Search Console się nie zgadzają

Objaw: URL wygląda zdrowo w PSI, ale jego grupa w Search Console jest słaba — albo odwrotnie.

Prawdopodobna przyczyna: PSI może pokazywać dane poziomu URL-a lub originu, podczas gdy Search Console grupuje podobne URL-e. Różnić mogą się też urządzenie, zakres i moment w kroczącym oknie.

Poprawka i potwierdzenie: dopasuj mobile/desktop, sprawdź zakres danych PSI i przeanalizuj kilka URL-i z grupy Search Console, zanim uznasz którykolwiek raport za błędny.

Wynik laboratoryjny zmienia się między uruchomieniami

Objaw: powtarzanie PSI daje wyraźnie różne wyniki albo wartości metryk.

Prawdopodobna przyczyna: zmienna odpowiedź serwera, żądanie strony trzeciej lub normalny szum pojedynczego testu laboratoryjnego zmieniły ślad.

Poprawka i potwierdzenie: uruchom tę samą strategię kilka razy, porównaj poszczególne metryki i wodospady żądań oraz zbadaj powtarzające się wąskie gardło, a nie sam wynik.

Poprawka jest widoczna w Lighthouse, ale nie w danych terenowych

Objaw: metryka laboratoryjna poprawia się od razu, a terenowa ocena Core Web Vitals pozostaje bez zmian.

Prawdopodobna przyczyna: CrUX nadal zawiera wizyty sprzed wydania w kroczącym oknie 28 dni albo poprawka nie pomogła użytkownikom i szablonom reprezentowanym w zbiorze terenowym.

Poprawka i potwierdzenie: zweryfikuj wdrożenie i ślad laboratoryjny, opisz datę wydania, a następnie obserwuj rozkład danych terenowych przez pełne okno raportowania.

Pobierz jeden wynik PSI z API

API rozdziela sekcje terenowe i laboratoryjne. Podaj własny klucz API i URL:

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

Zachowaj surową odpowiedź, aby data testu, strategia i zakres danych pozostały audytowalne.

Oddziel zakres danych terenowych od wyniku laboratoryjnego

Za pomocą jq wyodrębnij kategorię danych terenowych URL-a, kategorię fallbacku originu oraz wynik Lighthouse, zamiast zwijać je do jednej liczby:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

Brak wartości terenowej nie oznacza zera; oznacza, że dany zakres był niedostępny w odpowiedzi.

Powtórz test laboratoryjny bez ukrywania próbek

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

Raportuj wszystkie próbki albo udokumentowane podsumowanie; nie wybieraj wyłącznie najlepszego wyniku.

Sprawdź się: PageSpeed Insights

Pięć krótkich pytań o prawidłowe czytanie PSI. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Materiały warte uwagi

Moje powiązane teksty

• Google PageSpeed Insights: przewodnik dla początkujących — mój poradnik Ahrefs (uwaga: powstał przed zmianą FID→INP).
• Core Web Vitals: kompletny przewodnik — dane terenowe i laboratoryjne oraz moje ujęcie znaczenia CWV.
• Przewodnik dla początkujących po technicznym SEO — miejsce wydajności w szerszym obrazie.

Oficjalne

• Using CrUX in PageSpeed Insights — własne wyjaśnienie sekcji terenowej Chrome.
• Jakie istnieją narzędzia Core Web Vitals? — relacje między PSI, Lighthouse, CrUX i Search Console.

Inni autorzy

• How To Use PageSpeed Insights — Matt Zeunert (DebugBear); mocne techniczne omówienie wyniku i diagnostyki.
• PageSpeed Insights: Google’s Highly Misunderstood Diagnostic Tool — Ryan Sullivan (SiteCare); dobre rozprawienie się z mitami.
• Core Web Vitals Ranking Factor Is More Than A Tiebreaker — omówienie przez Search Engine Journal komentarzy Gary’ego Illyesa o znaczeniu CWV.
• Google Page Experience Update Is More Than A Tie Breaker — SE Roundtable; relacja Barry’ego Schwartza o charakterystyce sygnału jakości strony przez przedstawicieli Google.

Statystyki warte cytowania

• Niemal nikt nie uzyskuje 100. Tylko około 2% testowanych stron osiąga idealne 100, a wynik 50 już plasuje w górnych 25% — to przydatny kontekst dla każdego, kto panikuje z powodu liczby poniżej 90. Źródło
• Dane terenowe to krocząca średnia z 28 dni. Poprawka może potrzebować około 28 dni, aby w pełni pojawić się w Core Web Vitals Assessment — w międzyczasie używaj danych laboratoryjnych do szybkiej informacji zwrotnej. Źródło
• „Good” to 75. percentyl. Google ocenia na poziomie p75, aby „większość wizyt doświadczyła docelowego poziomu wydajności” — oznacza to, że nawet przy zaliczonym LCP 2,5 s jedna czwarta odwiedzających czekała dłużej. Źródło

Dziennik zmian