Blog · 7 listopada 2026 · 9 min czytania
Jak czytać raport PageSpeed Insights (bez programisty)
Wkleiłeś adres swojej strony w pagespeed.web.dev, zobaczyłeś czerwone 38 i czterdzieści linijek technicznych komunikatów. Ten tekst mówi, co w tym raporcie czytać, w jakiej kolejności i co spokojnie pominąć – tak, żebyś po dziesięciu minutach wiedział, czy masz problem, jak duży i komu go zlecić.
To są dwa raporty w jednym
Najważniejsza rzecz, której PageSpeed nie tłumaczy wprost: na jednej stronie dostajesz dwa różne pomiary, które potrafią sobie przeczyć.
| Sekcja | Skąd dane | Do czego służy | Kiedy jej nie ma |
|---|---|---|---|
| „Co odczuwają prawdziwi użytkownicy” (u góry) | Z przeglądarek Chrome Twoich odwiedzających z ostatnich 28 dni (raport Chrome UX). Pokazywany jest wynik 75. percentyla, czyli taki, że trzy czwarte wizyt było szybszych | To jest prawda o Twojej stronie i to te liczby bierze pod uwagę Google. Werdykt „Zaliczono / Nie zaliczono” ocenę Core Web Vitals dotyczy właśnie tej sekcji | Gdy strona ma za mało ruchu – wtedy widzisz tylko komunikat o braku danych albo dane dla całej domeny zamiast tej jednej podstrony |
| „Zdiagnozuj problemy z wydajnością” (niżej, z wynikiem 0–100) | Jedno uruchomienie narzędzia Lighthouse na serwerze Google: symulowany telefon ze średniej półki i wolniejsza sieć komórkowa | Do diagnozy: mówi dlaczego jest wolno i co poprawić. Daje listę plików i zaleceń dla wykonawcy | Zawsze jest – ale to pomiar laboratoryjny, nie doświadczenie klientów |
Dlatego zdarza się, że klienci „zaliczają” Core Web Vitals, a wynik laboratoryjny jest pomarańczowy – albo odwrotnie. Google sam pisze, że dane terenowe to historia z realnych urządzeń i sieci, a laboratorium to kontrolowany, jednorazowy test. Dla decyzji biznesowej liczy się góra, dla listy zadań – dół.
Patrz na „Telefon”, nie na „Komputer”
Zakładki na górze raportu przełączają urządzenie. Wynik na komputerze jest prawie zawsze lepszy i prawie zawsze nieistotny: większość ruchu firmowych stron idzie z telefonów, Google indeksuje wersję mobilną, a pomiar laboratoryjny symuluje słaby telefon celowo. Jeśli chcesz zapamiętać jedną liczbę z raportu, niech to będzie wynik mobilny. Dlaczego telefon tak bardzo różni się od laptopa, opisaliśmy w tekście o wolnej stronie na telefonie.
Co znaczy wynik 0–100
Duża liczba w kółku to średnia ważona pięciu pomiarów laboratoryjnych. Według dokumentacji Lighthouse (wersja 10 i nowsze) wagi są takie:
| Pomiar | Waga | Co czuje użytkownik |
|---|---|---|
| Total Blocking Time (TBT) | 30 % | Strona „wisi”: widać ją, ale nie da się kliknąć, bo telefon przetwarza skrypty |
| Largest Contentful Paint (LCP) | 25 % | Jak długo czeka na największy element – zwykle zdjęcie w nagłówku albo główny tytuł |
| Cumulative Layout Shift (CLS) | 25 % | Treść skacze w trakcie ładowania: chciał kliknąć „Zadzwoń”, trafił w baner |
| First Contentful Paint (FCP) | 10 % | Jak długo patrzy na pusty ekran, zanim pojawi się cokolwiek |
| Speed Index | 10 % | Jak szybko wypełnia się widoczna część ekranu |
Przedziały są trzy: 0–49 czerwony (słabo), 50–89 pomarańczowy (do poprawy), 90–100 zielony (dobrze). Dwie rzeczy, które oszczędzą Ci nerwów: po pierwsze, ten sam adres uruchomiony dwa razy może dać wynik różniący się o kilka punktów – to normalne, serwer Google i Twój serwer mają lepsze i gorsze chwile; nie reaguj na różnicę 72 → 68. Po drugie, wynik 100 jest zarezerwowany dla stron prawie bez skryptów; dla firmowej strony z formularzem, mapą i analityką realnym celem jest zielony zakres, nie setka.
Trzy liczby, które decydują o werdykcie Google
W sekcji z danymi prawdziwych użytkowników trzy pomiary są oznaczone jako Core Web Vitals. Progi „dobry” są takie same dla wszystkich stron na świecie:
- LCP do 2,5 s – największy element widoczny w ciągu dwóch i pół sekundy.
- INP do 200 ms – strona reaguje na dotknięcie w jedną piątą sekundy (ten pomiar istnieje tylko w danych terenowych, laboratorium pokazuje zamiast niego TBT).
- CLS do 0,1 – treść prawie nie skacze.
Werdykt „Zaliczono” wymaga, żeby wszystkie trzy były w zieleni na poziomie 75. percentyla. Jedna pomarańczowa i całość nie przechodzi. Więcej o tym, skąd biorą się złe wyniki każdej z trzech liczb, w tekście Core Web Vitals po ludzku.
Lista zaleceń: co znaczą najczęstsze komunikaty
Pod wynikiem jest lista komunikatów (w zależności od wersji nazwana „Diagnostyka” albo „Statystyki”), każdy z rozwijaną listą plików. Dokładne brzmienie zmienia się między wersjami, ale na firmowych stronach wciąż wracają te same pozycje. Tłumaczenie na ludzki i kto to zwykle naprawia:
| Komunikat | Co to znaczy | Kto naprawia i ile pracy |
|---|---|---|
| Wyświetlaj obrazy w formatach nowej generacji / Odpowiednio dobieraj rozmiar obrazów | Zdjęcia są za duże – wgrane prosto z aparatu albo w starym formacie. Najczęstsza przyczyna złego LCP | Często Ty sam (wtyczka do kompresji, ponowne wgranie) albo godzina pracy webmastera |
| Zmniejsz czas wykonywania JavaScript / Zminimalizuj pracę w wątku głównym | Za dużo skryptów: wtyczki, slider, czat, kilka systemów analityki. Główna przyczyna złego TBT i INP | Webmaster: przegląd wtyczek i widżetów, usunięcie nieużywanych, opóźnione ładowanie reszty. Pół dnia do dnia |
| Wyeliminuj zasoby blokujące renderowanie | Pliki stylów i skryptów, które przeglądarka musi pobrać w całości, zanim cokolwiek pokaże. Wpływa na FCP i LCP | Webmaster; często załatwia to dobrze skonfigurowana wtyczka optymalizacyjna. Kilka godzin |
| Skróć czas początkowej odpowiedzi serwera | Serwer długo „myśli”, zanim wyśle pierwszy bajt – słaby hosting, brak pamięci podręcznej, ciężki motyw. Wszystko inne czeka na to | Hosting (zmiana pakietu lub firmy) albo webmaster (cache po stronie serwera). Od godziny do przenosin |
| Użyj wydajnych zasad pamięci podręcznej | Przeglądarka klienta pobiera te same pliki przy każdej wizycie zamiast je zapamiętać. Nie boli przy pierwszej wizycie, boli przy każdej następnej | Webmaster lub hosting, zwykle kilka linijek konfiguracji. Godzina |
| Unikaj dużych przesunięć układu | Elementy bez zarezerwowanego miejsca (obrazy bez wymiarów, baner cookies, reklamy, czcionki) przesuwają treść. To jest CLS | Webmaster; zwykle drobne poprawki w szablonie. Godzina lub dwie |
| Zmniejsz wpływ kodu firm zewnętrznych | Czat, mapa, piksele reklamowe, osadzone wideo – kod, którego nie kontrolujesz, ale który Twój klient musi pobrać | Decyzja biznesowa (co naprawdę potrzebne) plus webmaster (ładowanie dopiero po interakcji). Godzina |
| Obraz LCP nie został wczytany z priorytetem / Wstępnie wczytaj obraz LCP | Największe zdjęcie ładuje się na końcu kolejki, choć powinno na początku | Webmaster, jedna zmiana w kodzie strony. Pół godziny |
Co możesz pominąć
- „Szacowane oszczędności” nie sumują się. Jeśli przy pięciu zaleceniach widzisz 1,2 s + 0,8 s + 0,6 s…, nie znaczy to, że po wszystkich poprawkach strona będzie szybsza o 3 s. Zalecenia nakładają się na siebie; traktuj te liczby jako kolejność, nie jako obietnicę.
- Pozostałe trzy kółka (ułatwienia dostępu, sprawdzone metody, SEO) to przydatne, ale płytkie testy automatyczne jednej strony. Zielone SEO w PageSpeed nie znaczy, że strona jest dobrze widoczna w Google – znaczy, że ma tytuł, opis i da się ją zaindeksować.
- Pojedyncze pliki w rozwijanych listach, jeśli nie jesteś webmasterem. Ty masz wiedzieć, które zalecenia są na górze; co zrobić z plikiem
jquery.min.js, niech wie wykonawca. - Strona główna jako jedyny test. Sprawdź też stronę z ofertą, cennikiem i kontaktem – to tam klienci podejmują decyzję, a tam często jest gorzej (galerie, mapy, formularze).
Jak zamienić raport w listę zadań
- Zapisz punkt wyjścia. Zrzut ekranu górnej sekcji (prawdziwi użytkownicy) i wyniku mobilnego, z datą. Bez tego nie sprawdzisz, czy ktoś coś poprawił.
- Zapisz, które z trzech liczb Core Web Vitals są poza zielenią. To definiuje problem: złe LCP to zwykle obrazy i serwer, złe INP to skrypty, złe CLS to szablon.
- Z listy zaleceń przepisz pięć górnych w kolejności, w jakiej je pokazuje raport. Do każdego dopisz, kto to robi, z tabeli wyżej.
- Zacznij od serwera i obrazów, skończ na skryptach. Serwer, bo czeka na niego wszystko inne; obrazy, bo to najtańsza i najpewniejsza poprawa; skrypty na końcu, bo wymagają decyzji, z czego rezygnujesz.
- Odbierz pracę pomiarem, nie zapewnieniem. Pomiar laboratoryjny od razu po poprawkach, dane prawdziwych użytkowników po 28 dniach. Jeśli wykonawca mówi „zrobione”, a wynik mobilny się nie ruszył – nie jest zrobione.
Ten sam pomiar plus to, czego PageSpeed nie sprawdza
Darmowy szybki skan Webskan uruchamia pomiar mobilny Lighthouse dla Twojej strony i obok niego sprawdza przekierowanie na https, certyfikat, nagłówki bezpieczeństwa i podstawy SEO. Bez e-maila, bez rejestracji, wynik w ok. 30 sekund.
Chcesz dostać gotową listę zadań zamiast ją przepisywać? Audyt pogłębiony Webskan (249 zł) mierzy wydajność na telefonie i komputerze dla wielu podstron naraz, tłumaczy zalecenia na konkretne pliki i priorytety, a do tego sprawdza SEO techniczne, bezpieczeństwo, dostępność i zepsute linki. W cenie ponowne sprawdzenie po poprawkach i 30 dni Webskan Monitora.
Źródła
- Google, About PageSpeed Insights – dane terenowe vs laboratoryjne, 28 dni, 75. percentyl, ocena Core Web Vitals
- Chrome for Developers, Lighthouse performance scoring – wagi pomiarów i przedziały wyniku
- Google Search Central, Core Web Vitals a wyniki wyszukiwania – progi LCP/INP/CLS