Google PageSpeed Insights to jedno z najważniejszych narzędzi do analizy wydajności stron WWW. Dowiedz się, jak czytać wyniki, co oznaczają poszczególne metryki i jak poprawić wynik swojej strony.
Dlaczego warto rozumieć PageSpeed, a nie tylko gonić za setką
Google PageSpeed Insights (PSI) to darmowe narzędzie, które analizuje wydajność strony i zwraca wynik od 0 do 100 wraz z listą rekomendacji. Wynik 100 na desktopie osiąga większość dobrze zbudowanych stron. Na mobile — jest trudniej: symulacja odbywa się na wirtualnym urządzeniu o mocy zbliżonej do Moto G Power z throttlowanym połączeniem 4G. W efekcie wynik mobilny 60–70 to norma nawet dla dobrze zoptymalizowanych witryn. Problem polega na tym, że wiele firm traktuje ten wynik jak ocenę szkolną, nie rozumiejąc, co za nim stoi. W tym artykule wyjaśniam, jak czytać wyniki PSI i co z nich wyciągnąć w praktyce.
Core Web Vitals — trzy metryki, które liczą się dla Google
Od marca 2024 roku Google mierzy doświadczenie użytkownika trzema Core Web Vitals:
- LCP (Largest Contentful Paint) — czas renderowania największego widocznego elementu (zwykle hero image lub nagłówek). Cel: poniżej 2,5 s. Najczęstsza przyczyna słabego LCP to nieskompresowane obrazy, brak preloadu hero image i wolne TTFB.
- INP (Interaction to Next Paint) — nowa metryka responsywności, która zastąpiła FID (First Input Delay). Mierzy opóźnienie od kliknięcia/dotknięcia do momentu, gdy przeglądarka wyrenderuje odpowiedź wizualną. Cel: poniżej 200 ms. Ciężki JavaScript (duże bundle'e, blokujące skrypty trzecich stron) to główny winowajca.
- CLS (Cumulative Layout Shift) — mierzy niestabilność layoutu: elementy, które „skaczą" podczas ładowania. Cel: poniżej 0,1. Typowe przyczyny: obrazy bez zadeklarowanych wymiarów (
width/height), dynamicznie ładowane banery reklamowe, fonty bezfont-display: swap.
Te trzy metryki są czynnikiem rankingowym w Google Search od 2021 roku (Page Experience Update). Nie są jedynym czynnikiem — treść, linki i relevance nadal dominują — ale przy dwóch podobnych stronach lepsza wydajność może przesądzić o pozycji.
Dane laboratoryjne vs dane terenowe — skąd bierze się różnica
PSI prezentuje dwa zestawy danych. Dane terenowe (Field Data) pochodzą z Chrome User Experience Report (CrUX) — to realne pomiary od użytkowników Chrome z ostatnich 28 dni. Jeśli Twoja strona ma wystarczający ruch, zobaczysz sekcję „Assess your Core Web Vitals" z wynikami good/needs improvement/poor. Te dane są najbliższe rzeczywistości.
Dane laboratoryjne (Lab Data) to wynik jednorazowego testu Lighthouse na wirtualnym urządzeniu. Są powtarzalne, ale nie odzwierciedlają warunków prawdziwych użytkowników — nie uwzględniają różnorodności urządzeń, połączeń i zachowań. Wynik 45 w Lab Data przy zielonych Core Web Vitals w Field Data oznacza, że strona działa dobrze dla użytkowników, a test laboratoryjny jest po prostu surowy.
Podczas audytów PageSpeed, które przeprowadzamy w desi9n, zawsze zaczynamy od danych CrUX. Jeśli ich nie ma (za mały ruch), dopiero wtedy opieramy się na Lighthouse — ale z świadomością ograniczeń.
Metryki pomocnicze — co jeszcze warto znać
- FCP (First Contentful Paint) — czas do pojawienia się pierwszego elementu na stronie (tekst, obraz, SVG). Nie musi to być element główny — nawet spinner się liczy.
- TTFB (Time to First Byte) — czas od wysłania żądania do otrzymania pierwszego bajtu odpowiedzi z serwera. Cel: poniżej 800 ms. Wolne TTFB oznacza problem po stronie backendu, hostingu lub DNS.
- TBT (Total Blocking Time) — suma czasu, przez który main thread jest zablokowany (zadania JS dłuższe niż 50 ms). Koreluje z INP — wysoki TBT oznacza, że strona będzie reagować z opóźnieniem.
- Speed Index — jak szybko widoczna treść strony staje się kompletna. Przydatny do porównywania wersji strony przed i po optymalizacji.
Najczęstsze problemy i jak je naprawić
Obrazy
Nieskompresowane obrazy to najczęstsza przyczyna słabego LCP. Konwertuj do WebP lub AVIF, ustaw odpowiednie wymiary, dodaj loading="lazy" do obrazów poniżej fold i fetchpriority="high" do hero image. Element <picture> z fallbackiem na JPEG pozwala obsłużyć starsze przeglądarki. Więcej o formatach graficznych pisaliśmy osobno.
JavaScript
Skrypty trzecich stron (analityka, czaty, widgety reklamowe, consent banery) to główny winowajca wysokiego TBT i słabego INP. Odrocz ładowanie skryptów: defer zamiast async dla skryptów, które nie muszą działać natychmiast, i requestIdleCallback dla mniej krytycznych zadań. Usuwaj nieużywany kod — Lighthouse wskazuje unused JS w zakładce „Reduce unused JavaScript".
Cache i kompresja
Włącz Brotli (lub gzip) na serwerze — zmniejsza rozmiar przesyłanych zasobów o 60–80%. Ustaw długie nagłówki cache (Cache-Control: max-age=31536000) dla statycznych assetów (CSS, JS, fonty, obrazy) z hashami w nazwach plików.
Fonty
Zewnętrzne fonty (Google Fonts) generują dodatkowe żądania DNS i HTTP. Preloaduj krytyczne fonty (<link rel="preload" as="font">), hostuj je lokalnie i dodaj font-display: swap, żeby tekst był widoczny podczas ładowania fontu.
Inne narzędzia poza PageSpeed
PSI to nie jedyne źródło danych. Lighthouse (wbudowany w Chrome DevTools, zakładka „Lighthouse") daje ten sam audyt, ale z pełną kontrolą nad parametrami — możesz wybrać urządzenie, throttling i kategorie. WebPageTest pozwala testować z różnych lokalizacji i połączeń, generuje filmstrip i waterfall chart — nieoceniony przy diagnozie wolnego TTFB. GTmetrix łączy Lighthouse z Web Vitals i oferuje historię wyników, dzięki czemu widać trend po wdrożeniu zmian. Chrome DevTools → Performance to narzędzie do diagnozowania konkretnych problemów z JS — flame chart pokazuje, które funkcje blokują main thread i jak długo trwają poszczególne task'i.
Co z tym zrobić u siebie
- Sprawdź swoją stronę w PSI — najpierw sekcję Field Data (CrUX). Jeśli jest zielona, nie panikuj z powodu niskiego wyniku laboratoryjnego.
- Zoptymalizuj obrazy (WebP/AVIF, lazy loading, preload hero) — to zwykle daje największy zysk przy najmniejszym wysiłku.
- Zaudytuj skrypty trzecich stron — każdy dodatkowy tracker czy widget to koszt w INP i TBT.
- Jeśli potrzebujesz pełnej optymalizacji wydajności — przeprowadzamy audyty PageSpeed i wdrażamy rekomendacje, od konfiguracji serwera po refaktor frontendu.
Źródła
- Google PageSpeed Insights — narzędzie do audytu wydajności stron.
- web.dev — Core Web Vitals — oficjalne definicje LCP, INP i CLS z progami good/poor.
- Chrome UX Report (CrUX) — dokumentacja danych terenowych z Chrome.
- WebPageTest — zaawansowane testy wydajności z różnych lokalizacji i urządzeń.
LinkedIn/desi9n-pl 
FB/desi9npl 
@desi9n.pl