W tym poradniku dowiesz się, jak używać PageSpeed Insights w 7 krokach i jak czytać jego raport od danych użytkowników do listy poprawek. PageSpeed Insights to darmowe narzędzie Google, które dla jednego adresu URL pokazuje dane od prawdziwych użytkowników Chrome z ostatnich 28 dni oraz test laboratoryjny Lighthouse z listą poprawek. Kroki: test, ocena Core Web Vitals, brak danych polowych, wynik Lighthouse, diagnostyka, poprawki, ponowny pomiar.
Poradnik jest dla właściciela strony i początkującego SEO-wca. Progi, wagi metryk i nazwy sekcji raportu są aktualne na październik 2026: uwzględniają INP zamiast FID i insighty z Lighthouse 13 (wersja wydana 10 października 2025 roku).
PageSpeed Insights w skrócie: co mierzy narzędzie
PageSpeed Insights (PSI) to narzędzie Google pod adresem pagespeed.web.dev, które łączy w jednym raporcie dwa rodzaje danych o wydajności strony. Według dokumentacji PageSpeed Insights dane polowe pochodzą z Chrome User Experience Report (CrUX) i obejmują poprzedni 28-dniowy okres, a dane laboratoryjne pochodzą z testu Lighthouse.
Dane polowe w PageSpeed Insights to LCP, INP, CLS i FCP oraz eksperymentalny TTFB, raportowane na 75. percentylu wizyt. Dane laboratoryjne to wynik Lighthouse w czterech kategoriach: Performance, Accessibility, Best Practices i SEO. Dokumentacja PSI opisuje test laboratoryjny jako przydatny do debugowania, bo jest robiony w kontrolowanych warunkach.
| Cecha | Dane polowe (CrUX) | Dane laboratoryjne (Lighthouse) |
|---|---|---|
| Źródło | prawdziwi użytkownicy Chrome | jeden symulowany test w centrum danych Google |
| Okres | ostatnie 28 dni | chwila testu |
| Metryki | LCP, INP, CLS, FCP, TTFB | FCP, LCP, TBT, CLS, Speed Index |
| INP | tak | nie (zastępnik: TBT) |
| Do czego | ocena Core Web Vitals, ta sama baza co raport w Google Search Console | szukanie przyczyn i testowanie poprawek |
| Dostępność | tylko dla stron z wystarczającym ruchem | dla każdego publicznego URL-a |
Test Lighthouse nie zmierzy INP, bo w laboratorium nikt nie klika strony. Według web.dev Lighthouse używa wtedy Total Blocking Time (TBT) jako zastępnika metryki interaktywności.
Jak używać PageSpeed Insights: 7 kroków
Raport PageSpeed Insights czytam zawsze w tej samej kolejności, od danych użytkowników do szczegółów technicznych:
- Uruchom test konkretnego URL-a w wersji mobilnej i desktopowej.
- Przeczytaj ocenę Core Web Vitals z danych polowych.
- Sprawdź, skąd są dane polowe: z adresu URL, z całego originu, czy ich brak.
- Odczytaj wynik Performance i rozbij go na metryki.
- Przejdź do diagnostyki i znajdź element LCP oraz zasoby blokujące.
- Dobierz poprawki do metryki, która nie przechodzi.
- Zmierz ponownie w PSI, a efekt u użytkowników sprawdź po 28 dniach.
Krok 1. Uruchom test konkretnego URL-a
Test w PageSpeed Insights uruchamiasz, wklejając pełny adres URL na pagespeed.web.dev i klikając „Analyze”. Raport ma dwie zakładki, Mobile i Desktop, i każda zakładka ma osobne dane polowe oraz osobny test Lighthouse.
Test mobilny w PageSpeed Insights jest celowo wolny. Według dokumentacji throttlingu Lighthouse PSI symuluje sieć o opóźnieniu (RTT) 150 ms i przepustowości 1,6 Mb/s oraz spowalnia procesor 4-krotnie. Emulowane urządzenie to według konfiguracji Lighthouse Moto G Power z 2022 roku z ekranem 412×823 px. Dokumentacja PSI nadal wspomina o Moto G4, ale kod Lighthouse używa Moto G Power.
Testuję w PageSpeed Insights osobno szablony, a nie tylko stronę główną: wpis, kategorię, stronę produktu, archiwum tagu. Szablony różnią się obrazkami, skryptami i czasem odpowiedzi serwera. W crawlu Screaming Frog bynajmniej.pl z 14.10.2026 aż 10 URL-i odpowiadało dłużej niż 1000 ms i były to archiwa tagów i kategorii, czyli strony, których nikt nie wkleja do PSI jako pierwszych.
Krok 2. Przeczytaj ocenę Core Web Vitals
Ocena Core Web Vitals (Core Web Vitals Assessment) w PageSpeed Insights to werdykt „Passed” albo „Failed” z danych polowych CrUX. Strona przechodzi ocenę, gdy na 75. percentylu spełnia wszystkie trzy progi naraz. Progi z pomocy Google do raportu Podstawowe wskaźniki internetowe:
| Metryka | Co mierzy | Dobry | Do poprawy | Słaby |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | wyrenderowanie największego elementu | ≤ 2,5 s | ≤ 4 s | > 4 s |
| INP (Interaction to Next Paint) | reakcję na kliknięcia i klawisze | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | przesunięcia układu | ≤ 0,1 | ≤ 0,25 | > 0,25 |
INP zastąpił FID jako Core Web Vital 12 marca 2024 roku, co potwierdza ogłoszenie na web.dev. Poradnik o PageSpeed Insights, który w 2026 roku nadal opisuje FID jako podstawowy wskaźnik, jest nieaktualny.
Jedna metryka powyżej progu wystarcza, żeby ocena Core Web Vitals w PSI była „Failed”. Strona z LCP 2,8 s na 75. percentylu nie przejdzie oceny nawet przy dobrym INP i CLS.
Krok 3. Sprawdź, skąd są dane polowe
Dane polowe w PageSpeed Insights mają trzy możliwe stany. Według dokumentacji PSI, gdy pojedynczy URL nie ma wystarczająco danych w CrUX, narzędzie pokazuje dane całego originu (protokół i domena), a gdy origin też ich nie ma, sekcji danych polowych brak. Przełącznik „This URL / Origin” w raporcie mówi, który poziom widzisz.
Brak danych polowych w PageSpeed Insights wynika z zasad zbierania CrUX. Według metodologii CrUX strona musi być publiczna (kod 200, bez noindex w meta robots i nagłówku X-Robots-Tag) i „wystarczająco popularna”, a Google nie ujawnia progu ruchu. CrUX zbiera dane tylko z Chrome na Windows, macOS, ChromeOS, Linuksie i Androidzie, od użytkowników z włączonymi statystykami użytkowania i synchronizacją historii. Chrome na iOS, Edge i aplikacje z WebView są poza CrUX.
Strona z ruchem głównie z iPhone’ów może więc mieć w PageSpeed Insights mało danych polowych mimo sporej liczby wizyt. Przy braku danych polowych zostaje test Lighthouse i własny pomiar RUM, a ocena Core Web Vitals w PSI jest wtedy niedostępna.
Krok 4. Odczytaj wynik Performance i jego wagi
Wynik Performance w PageSpeed Insights to liczba od 0 do 100 z testu Lighthouse. Według dokumentacji PSI wynik 90–100 jest dobry (zielony), 50–89 wymaga poprawy (pomarańczowy), a 0–49 jest słaby (czerwony). Wynik powstaje ze średniej ważonej pięciu metryk laboratoryjnych, opisanej w dokumentacji wyniku Lighthouse:
| Metryka laboratoryjna | Waga w wyniku Performance |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
Wagi metryk w Lighthouse oznaczają, że TBT, LCP i CLS dają razem 80% wyniku Performance. Wagi obowiązują od Lighthouse 10, a według zapowiedzi Lighthouse 13 z 10 października 2025 roku wersja 13 nie zmieniła sposobu liczenia wyniku.
Wynik Performance zmienia się między kolejnymi testami tego samego URL-a. Dokumentacja Lighthouse jako przyczyny zmienności podaje testy A/B, zmienne reklamy, routing ruchu w internecie, rozszerzenia przeglądarki i antywirusy. Różnica kilku punktów między dwoma testami nie jest więc sygnałem, że strona się zepsuła.
Krok 5. Przejdź do diagnostyki
Sekcja diagnostyki w PageSpeed Insights w Lighthouse 13 składa się z „insights”, czyli tych samych analiz co panel Performance w Chrome DevTools. Według zapowiedzi Lighthouse 13 stare audyty zniknęły z raportu i z pliku JSON, a nowe insighty grupują kilka dawnych audytów w jeden:
| Insight w Lighthouse 13 | Zastępuje dawne audyty | Pomaga przy metryce |
|---|---|---|
LCP request discovery (lcp-discovery-insight) | prioritize-lcp-image, lcp-lazy-loaded | LCP |
Render-blocking requests (render-blocking-insight) | render-blocking-resources | FCP, LCP |
Document request latency (document-latency-insight) | redirects, server-response-time, uses-text-compression | TTFB, LCP |
Image delivery (image-delivery-insight) | audyty formatów WebP/AVIF, kompresji i rozmiaru obrazków | LCP |
Layout shift culprits (cls-culprits-insight) | layout-shifts | CLS |
Insight LCP request discovery w PageSpeed Insights czytam jako pierwszy, bo pokazuje, który element jest elementem LCP i czy przeglądarka znalazła go od razu w HTML. Przyciski z nazwami metryk nad diagnostyką zawężają listę do jednej metryki, np. tylko LCP albo tylko CLS.
Raport PageSpeed Insights z dawnymi nazwami w rodzaju „Eliminate render-blocking resources” albo „Serve images in next-gen formats” jest zrzutem ze starszej wersji Lighthouse. Google zapowiedział wdrożenie Lighthouse 13 w PSI w tygodniu po 10 października 2025 roku.
Krok 6. Dobierz poprawki do metryki, która nie przechodzi
Poprawki z PageSpeed Insights mają sens tylko wtedy, gdy celujesz w metrykę, która nie przechodzi w danych polowych. Lista najczęstszych przyczyn według przewodników web.dev:
- Słaby LCP: obraz LCP z lazy loadingiem, brak
fetchpriority="high"na obrazie LCP, ciężkie obrazki i wolna odpowiedź serwera. Według web.dev o optymalizacji LCP obrazu LCP nie wolno ładować leniwie, a według web.dev o TTFB dobry TTFB to do 0,8 s. - Słaby INP: długie zadania JavaScriptu (powyżej 50 ms) w obsłudze kliknięć, duży DOM i skrypty zewnętrzne. W teście Lighthouse objawem jest wysoki TBT.
- Słaby CLS: obrazki bez atrybutów
widthiheight, reklamy i embedy bez zarezerwowanego miejsca oraz fonty podmieniane po załadowaniu. Rozwiązania opisuje web.dev o optymalizacji CLS.
Ciężkie obrazki to typowy materiał dla insightu Image delivery w PageSpeed Insights. W audycie bynajmniej.pl, który zrobiłem 14.10.2026, crawl Screaming Frog znalazł 6 obrazków powyżej 2 MB, w tym PNG wygenerowane w ChatGPT w 2025 roku po 2,5–3,7 MB, oraz 26 obrazków powyżej 100 KB. Odpowiedź serwera bynajmniej.pl jest za to szybka: TTFB około 190 ms (mediana 3 prób z Polski), czyli wyraźnie poniżej progu 0,8 s z web.dev.
Na WordPressie poprawki LCP robię najpierw na obrazkach, potem na wtyczkach ładujących JavaScript, a dopiero na końcu na serwerze, bo taka kolejność zwykle wymaga najmniej zmian w kodzie. Taka kolejność poprawek LCP to moja rekomendacja, a nie reguła Google.
Krok 7. Zmierz ponownie i sprawdź efekt po 28 dniach
Test Lighthouse w PageSpeed Insights pokaże efekt poprawki od razu, a dane polowe CrUX dopiero po kilku tygodniach, bo obejmują ruchome okno 28 dni. Raport Podstawowe wskaźniki internetowe w Google Search Console korzysta z tych samych danych CrUX i grupuje podobne URL-e, a walidacja poprawki trwa w nim 28 dni. Jak czytać ten raport, opisuję w poradniku Google Search Console: jak korzystać.
Moim zdaniem ponowny test w PageSpeed Insights trzeba zrobić 2–3 razy i porównać mediany metryk, a nie pojedynczy wynik. Porównanie median ogranicza wpływ zmienności opisanej w dokumentacji Lighthouse.
PageSpeed Insights API: test wielu adresów naraz
PageSpeed Insights API pozwala testować wiele URL-i skryptem zamiast ręcznego wklejania. Według dokumentacji PSI API API działa z kluczem i bez klucza, ale klucz jest zalecany przy częstych, automatycznych zapytaniach. Przykładowe zapytanie:
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com/&strategy=MOBILE&category=PERFORMANCE&key=TWOJ_KLUCZ"Parametry PSI API opisuje dokumentacja metody runPagespeed. Parametr strategy przyjmuje MOBILE albo DESKTOP i domyślnie jest to desktop, więc test mobilny trzeba zamówić jawnie. Parametr category przyjmuje PERFORMANCE, ACCESSIBILITY, BEST_PRACTICES i SEO, a bez niego API uruchamia tylko kategorię Performance. Klucz API polecam założyć od razu, bo zapytania bez klucza bywają odrzucane błędem 429 „Quota exceeded”. Aktualne limity zapytań dla klucza sprawdzisz w Google Cloud Console na stronie limitów PageSpeed Insights API.
Masowy test w PSI API ma sens przy przeglądzie szablonów, np. jako część audytu SEO. Odpowiedź API zawiera w polu loadingExperience dane polowe URL-a, a w polu originLoadingExperience dane całego originu.
Czego nie robić z wynikiem PageSpeed Insights
Wynik Performance w PageSpeed Insights nie jest oceną Core Web Vitals. Google w dokumentacji page experience pisze, że systemy rankingowe używają Core Web Vitals, ale dobre wyniki nie gwarantują wysokich pozycji, a Google pokazuje najtrafniejszą treść nawet przy słabym page experience. Core Web Vitals w tej dokumentacji to dane od użytkowników, a nie punkty z testu laboratoryjnego.
Najpopularniejszy mit o PageSpeed Insights mówi, że 100/100 na mobile podniesie stronę w Google. Zielone kółko ładnie wygląda na zrzucie ekranu w ofercie, ale Google nie deklaruje, że liczy punkty Lighthouse. Moim zdaniem lepiej mieć „Passed” w ocenie Core Web Vitals i wynik 75 niż 100 punktów na stronie, której użytkownicy widzą LCP po 4 sekundach.
Pozostałe błędy przy pracy z PageSpeed Insights:
- Testowanie tylko strony głównej. Wpisy, kategorie i produkty mają inne szablony i inne problemy.
- Porównywanie wyniku mobilnego z desktopowym. Test mobilny ma 4-krotnie spowolniony procesor i sieć 1,6 Mb/s, więc wynik mobilny jest zwykle niższy.
- Wdrażanie każdej sugestii z diagnostyki. Insight, który nie dotyczy metryki z oceną „Failed”, ma niski priorytet.
- Ocena poprawki po jednym dniu w danych polowych. Okno CrUX ma 28 dni.
Różnice między testem a użytkownikami są naturalne. Według web.dev o różnicach danych laboratoryjnych i polowych test laboratoryjny ładuje stronę z pustym cache i bez bfcache, a CLS w laboratorium liczy tylko przesunięcia podczas ładowania, podczas gdy CLS w danych polowych obejmuje cały czas życia strony, także przewijanie.
FAQ: najczęstsze pytania o PageSpeed Insights
Jaki wynik w PageSpeed Insights jest dobry?
Dobry wynik Performance w PageSpeed Insights to 90–100 punktów, 50–89 wymaga poprawy, a poniżej 50 jest słaby. Ważniejsza od punktów jest ocena Core Web Vitals „Passed”, czyli LCP do 2,5 s, INP do 200 ms i CLS do 0,1 na 75. percentylu.
Dlaczego wynik PageSpeed Insights zmienia się przy każdym teście?
Wynik PageSpeed Insights zmienia się, bo każdy test Lighthouse to osobny pomiar zależny od sieci, obciążenia serwera, reklam i testów A/B. Dane polowe CrUX w tym samym raporcie nie zmieniają się między testami, bo obejmują 28 dni.
Dlaczego wynik mobilny jest niższy niż desktopowy?
Wynik mobilny w PageSpeed Insights jest niższy, bo test emuluje telefon Moto G Power z 4-krotnie spowolnionym procesorem i siecią o opóźnieniu 150 ms i przepustowości 1,6 Mb/s. Test desktopowy działa na emulowanym komputerze z łączem przewodowym.
Dlaczego PageSpeed Insights nie pokazuje danych od użytkowników?
PageSpeed Insights nie pokazuje danych polowych, gdy strona i cała domena mają za mało wizyt w Chrome User Experience Report albo gdy strona nie jest publiczna (np. ma noindex). CrUX nie zbiera danych z Chrome na iOS, Edge ani aplikacji z WebView.
Czy wynik PageSpeed Insights wpływa na pozycje w Google?
Systemy rankingowe Google według dokumentacji Google Search Central używają Core Web Vitals z danych od użytkowników, ale dobre wyniki nie gwarantują wysokich pozycji. Google nie deklaruje, że używa punktowego wyniku Lighthouse z PageSpeed Insights.
Czym różni się PageSpeed Insights od Lighthouse?
Lighthouse to otwartoźródłowy test laboratoryjny dostępny w Chrome DevTools i z wiersza poleceń, a PageSpeed Insights uruchamia Lighthouse na serwerach Google i dokłada dane polowe CrUX z 28 dni. Lighthouse odpalony lokalnie zależy od mocy Twojego komputera, a PSI ma stałe warunki testu.
Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.
Dodaj komentarz