PageSpeed Insights –
jak interpretować wyniki
i co poprawić

PageSpeed Insights (PSI) to jedno z tych narzędzi, które właściciele stron otwierają raz, patrzą na wynik, martwią się przez chwilę i zamykają — bo nie wiedzą, co zrobić z informacjami, które dostali. Tymczasem raport PSI to bardzo konkretna mapa problemów z wydajnością, która mówi wprost, co naprawić.

Wyjaśniam, jak go czytać od początku do końca.

Czym jest PageSpeed Insights i skąd bierze dane?

PageSpeed Insights to bezpłatne narzędzie Google dostępne pod adresem pagespeed.web.dev. Wpisujesz adres strony i po kilkunastu sekundach otrzymujesz raport wydajności z dwoma typami danych:

• Dane terenowe (Field Data) — rzeczywiste pomiary zebrane od użytkowników Chrome przez ostatnie 28 dni. To dane z Chrome User Experience Report (CrUX). Jeśli Twoja strona ma wystarczający ruch, PSI pokaże te dane — i to właśnie one są uwzględniane przez Google w rankingach.
• Dane laboratoryjne (Lab Data) — symulowany test przeprowadzony przez Lighthouse w kontrolowanych warunkach. Użyteczne do debugowania, ale nie odzwierciedlają dokładnie doświadczeń prawdziwych użytkowników.

Ważna zasada: priorytetyzuj dane terenowe nad laboratoryjnymi. Wynik laboratoryjny może różnić się znacząco od terenowego — zależy od infrastruktury serwerowej, CDN i zachowania prawdziwych użytkowników. Google rankinguje na podstawie danych terenowych.

Jak rozumieć wynik od 0 do 100?

Wynik Performance Score w PSI to zagregowana liczba od 0 do 100, obliczana na podstawie kilku metryk wydajności z różnymi wagami. Nie jest to ocena jednej metryki, lecz ważona średnia.

• 90–100 — dobry. Strona działa wydajnie, prędkość nie powinna być problemem rankingowym.
• 50–89 — do poprawy. Są obszary wymagające uwagi, ale sytuacja nie jest krytyczna.
• 0–49 — słaby. Strona prawdopodobnie odpycha użytkowników i traci pozycje przez wolne ładowanie.

Zawsze sprawdzaj oba wyniki — mobilny i desktopowy. Wynik mobilny jest zazwyczaj niższy (urządzenia mają mniej zasobów obliczeniowych) i to on ma większe znaczenie dla SEO, ponieważ Google indeksuje strony mobile-first.

Kluczowe metryki w raporcie

LCP – Largest Contentful Paint

Czas ładowania największego widocznego elementu. Cel: poniżej 2,5 s. To najważniejsza metryka w zestawie Core Web Vitals — ma największą wagę w algorytmie rankingowym Google.

INP – Interaction to Next Paint

Responsywność na interakcje użytkownika (kliknięcia, tapnięcia). Cel: poniżej 200 ms. Wysoki INP oznacza, że strona „lagnuje" po kliknięciu przycisku lub linku.

CLS – Cumulative Layout Shift

Stabilność układu strony. Cel: poniżej 0,1. Wysoki CLS oznacza, że elementy strony przesuwają się podczas ładowania — co frustruje użytkowników i może powodować przypadkowe kliknięcia.

FCP – First Contentful Paint

Czas do pierwszego renderowania jakiejkolwiek treści (tekstu lub obrazu). Cel: poniżej 1,8 s. Wysoki FCP sprawia, że użytkownik widzi pustą stronę przez zbyt długo i opuszcza ją, zanim cokolwiek się załaduje.

TTFB – Time to First Byte

Czas od wysłania żądania HTTP do otrzymania pierwszego bajtu odpowiedzi z serwera. Cel: poniżej 800 ms, idealnie poniżej 200 ms. Wysoki TTFB wskazuje na problemy po stronie serwera — wolny hosting, brak cachowania lub ciężkie zapytania do bazy danych.

TBT – Total Blocking Time

Suma czasu, przez który główny wątek przeglądarki był zablokowany przez długie zadania JavaScript. Wysoki TBT bezpośrednio przekłada się na wysoki INP. Cel: poniżej 200 ms.

Sekcja Opportunities – co naprawić w pierwszej kolejności

Sekcja Opportunities to lista konkretnych zmian, które PSI szacuje jako najefektywniejsze dla poprawy LCP i FCP. Każda pozycja zawiera szacowany zysk czasowy — to Twoja lista priorytetów.

Najczęściej pojawiające się rekomendacje i co z nimi zrobić:

Properly size images / Serve images in next-gen formats

Obrazy są za duże lub zapisane w starych formatach (JPEG, PNG). Rozwiązanie: przekonwertuj obrazy do formatu WebP (o 25–35% mniejszy przy tej samej jakości) i skaluj je do rzeczywistych wymiarów wyświetlania. Jeśli obraz jest wyświetlany jako 800 px szerokości, nie ma sensu serwować pliku o szerokości 3000 px.

Eliminate render-blocking resources

Skrypty JavaScript lub arkusze CSS ładowane w sekcji <head> blokują renderowanie strony. Rozwiązanie: dodaj atrybut defer lub async do niekrytycznych skryptów JS, przenieś je na koniec dokumentu, a CSS ładuj z media="print" i zmieniaj na all przez JavaScript dla niekrytycznych styli.

Reduce unused JavaScript / CSS

Na stronie ładują się duże pliki JS lub CSS, z których używana jest tylko część. Rozwiązanie: tree shaking (usunięcie nieużywanego kodu), code splitting (ładowanie tylko tego, co potrzebne na danej podstronie), usunięcie nieużywanych wtyczek i bibliotek.

Enable text compression

Serwer nie kompresuje plików tekstowych (HTML, CSS, JS) przed wysłaniem do przeglądarki. Rozwiązanie: włącz kompresję Gzip lub Brotli w konfiguracji serwera — zazwyczaj wystarczy dodanie kilku linii do pliku .htaccess.

Serve static assets with an efficient cache policy

Zasoby statyczne (obrazy, fonty, CSS, JS) są pobierane przy każdej wizycie zamiast być cachowane. Rozwiązanie: ustaw nagłówki Cache-Control z długim czasem wygaśnięcia dla zasobów, które rzadko się zmieniają.

Sekcja Diagnostics – głębsza analiza

Sekcja Diagnostics zawiera problemy, które nie mają bezpośredniego przeliczenia na czas, ale wpływają na ogólną wydajność. Warto tu zwrócić uwagę na:

• Avoid enormous network payloads — łączny rozmiar zasobów strony jest zbyt duży. Cel: poniżej 1600 KB.
• Minimize main-thread work — za dużo pracy na głównym wątku przeglądarki, co bezpośrednio wpływa na INP i TBT.
• Reduce the impact of third-party code — zewnętrzne skrypty (czaty, piksele, analityki) znacząco spowalniają stronę. Ładuj je z opóźnieniem lub zastąp lżejszymi alternatywami.

Od czego zacząć — praktyczna kolejność działań

Nie naprawiaj wszystkiego naraz. Skuteczna kolejność działań wygląda zazwyczaj tak:

1. Obrazy — najczęściej największy zysk przy relatywnie małym nakładzie. Kompresja i konwersja do WebP potrafi poprawić LCP o kilka sekund.
2. TTFB — jeśli przekracza 800 ms, naprawienie tego (lepszy hosting, cachowanie na poziomie serwera) przyniesie efekt dla wszystkich metryk jednocześnie.
3. Blokujące skrypty — dodanie defer do skryptów JS to często zmiana zajmująca 10 minut z dużym zyskiem dla FCP i TBT.
4. Kompresja Gzip/Brotli — jedna zmiana w konfiguracji serwera, często bez żadnych prac na stronie.
5. Cachowanie — ustawienie nagłówków cache dla zasobów statycznych.

Jeśli wynik mobilny jest poniżej 50 i chcesz kompleksowo zaadresować przyczyny — wdrożenie optymalizacji technicznej to usługa, w ramach której zajmuję się dokładnie tymi problemami. Możesz też zacząć od bezpłatnego audytu, żeby zobaczyć, jak Twoja strona wypada w porównaniu do benchmarków.