PageSpeed Insights – darmowy audyt strony w kilkanaście sekund

Jest darmowe narzędzie od Google, które w kilkanaście sekund powie Ci, co spowalnia Twoją stronę. Bez rejestracji, bez limitu sprawdzeń, bez wersji płatnej ukrytej pod przyciskiem. Nazywa się PageSpeed Insights i większość osób używa go źle – patrzy na jedną liczbę i wyciąga z niej wnioski, których ta liczba nie unosi.

Ten tekst jest o tym, jak czytać ten raport, żeby faktycznie coś z niego wynikało.

Jak zrobić audyt

1. Wejdź na pagespeed.web.dev.
2. Wklej adres strony i kliknij „Analizuj”.
3. Poczekaj kilkanaście sekund.

To wszystko. Na górze raportu zobaczysz dwie zakładki: Telefon i Komputer. Domyślnie otwiera się telefon i to dobrze, bo wyniki na nim są zauważalnie gorsze – Google symuluje wolniejszy procesor i słabsze łącze. Skoro większość ruchu na stronach małych firm idzie z telefonów, to właśnie tę zakładkę traktuj poważnie.

Sprawdź osobno stronę główną i jedną–dwie podstrony. Podstrony ofertowe albo wpisy blogowe bywają zbudowane inaczej niż strona główna i potrafią mieć zupełnie inne problemy.

Wynik 0–100 to nie jest ocena Twojej strony

Kolorowe koło na górze raportu ma trzy progi:

• 90–100, zielony – dobrze.
• 50–89, pomarańczowy – jest co poprawiać.
• 0–49, czerwony – coś jest wyraźnie nie tak.

I teraz rzecz, o której mało kto uprzedza: ten wynik szumi. Uruchom test trzy razy pod rząd, nie zmieniając ani jednej linijki kodu, a dostaniesz trzy różne liczby – różnica rzędu kilku, czasem kilkunastu punktów jest zupełnie normalna.

Nie jest to błąd narzędzia. Test laboratoryjny nie mierzy Twojego łącza, tylko symuluje wolne połączenie mobilne na podstawie tego, co pobrał. Symulacja z definicji ma rozrzut, a do tego dochodzi obciążenie serwerów Google w danej chwili.

Praktyczny wniosek: nie porównuj pojedynczych odczytów. Jeśli chcesz sprawdzić, czy zmiana pomogła, zrób po trzy pomiary przed i po, i porównaj mediany. A jeśli wynik spadł Ci z 96 na 92 po zmianie koloru przycisku – to prawie na pewno szum, a nie Twoja zmiana.

Nie ma też sensu gonić za setką. Różnica między 92 a 100 jest dla użytkownika niewidoczna, a często kosztuje wycięcie czegoś, co realnie służy stronie – animacji, czcionki, mapy dojazdu. Powyżej 90 przestań optymalizować i wróć do treści.

Dwie sekcje raportu, których nie wolno mylić

To jest najważniejszy fragment tego tekstu. Raport pokazuje dwa komplety liczb i one mówią o czymś zupełnie innym.

Dane terenowe – co przeżyli prawdziwi użytkownicy

Sekcja u góry, opisana jako „Dowiedz się, jakich wrażeń doświadczają Twoi użytkownicy”. To anonimowe pomiary zebrane z przeglądarek Chrome osób, które faktycznie odwiedziły Twoją stronę, uśrednione z ostatnich 28 dni.

To są dane, które liczą się dla Google w rankingu. Mają jednak dwa haczyki: pojawiają się dopiero wtedy, gdy strona ma dostatecznie dużo ruchu (świeże i małe strony zobaczą tu komunikat o braku danych), i reagują z opóźnieniem – po poprawce trzeba czekać nawet cztery tygodnie, aż okno 28 dni się przesunie.

Dane laboratoryjne – jeden sztuczny przebieg tu i teraz

Sekcja niżej, z kolorowym wynikiem i listą diagnostyki. To pojedynczy test wykonany przed chwilą na symulowanym telefonie. Nie mówi nic o Twoich użytkownikach, za to mówi dokładnie, co poprawić – i daje wynik od razu, bez czekania cztery tygodnie.

Krótko: dane terenowe to ocena, dane laboratoryjne to diagnoza. Do poprawiania strony używasz tych drugich. Do sprawdzenia, czy poprawa faktycznie dotarła do ludzi – tych pierwszych, miesiąc później.

Core Web Vitals po ludzku

Trzy wskaźniki, które Google traktuje jako miarę wrażeń użytkownika:

• LCP – po jakim czasie pojawia się największy element widoczny bez przewijania: zwykle zdjęcie w nagłówku albo duży tytuł. Krótko mówiąc: kiedy odwiedzający widzi, że strona się załadowała. Dobrze: do 2,5 s. Powyżej 4 s – źle.
• INP – ile strona zwleka z reakcją, gdy ktoś w nią kliknie. Zastąpił starszy wskaźnik FID w 2024 roku i jest od niego surowszy, bo patrzy na wszystkie interakcje, a nie tylko pierwszą. Dobrze: do 200 ms. Powyżej 500 ms – źle.
• CLS – jak bardzo treść skacze podczas wczytywania. Znasz to uczucie, gdy celujesz w link, a w ostatniej chwili doładowuje się baner i klikasz coś innego. To właśnie mierzy CLS. Dobrze: do 0,1. Powyżej 0,25 – źle.

Z tej trójki najczęściej leży LCP i najczęściej winne są zdjęcia – za duże, w starym formacie albo ładowane w złej kolejności.

Sekcja, którą naprawdę warto czytać: „Diagnostyka”

Przewiń raport poniżej wyniku. Znajdziesz tam listę konkretnych problemów, każdy z oszacowaniem, ile dałoby się na nim zyskać. Ta lista jest posortowana od najbardziej opłacalnych poprawek i to ona jest właściwą wartością całego narzędzia.

Jedna uwaga do tych oszacowań: traktuj je jako kolejność, a nie obietnicę. Wpis „szacowana oszczędność 280 ms” nie znaczy, że po poprawce strona wczyta się o 280 ms szybciej – to wyliczenie z tej samej symulacji, która daje rozrzut wyniku. Ale kolejność na liście jest rzetelna: pozycja z góry naprawdę zwykle znaczy więcej niż ta z dołu.

Każdy wpis można rozwinąć. Zobaczysz wtedy konkretne adresy plików – dokładnie te, które trzeba naprawić. To bardzo praktyczne, jeśli przekazujesz raport komuś, kto zajmuje się stroną: nie musisz niczego tłumaczyć, wystarczy wysłać link do wyniku.

Cztery problemy, które widuję najczęściej

Za duże zdjęcia

Numer jeden, z ogromną przewagą. Zdjęcie zrobione telefonem ma 4 000 pikseli szerokości i 5 MB, a na stronie wyświetla się w ramce szerokiej na 600 pikseli. Przeglądarka i tak musi pobrać całe. W raporcie zobaczysz to jako „Ulepsz dostarczanie obrazów” albo „Odpowiednio dopasuj rozmiar obrazów”.

Poprawka: przeskaluj zdjęcia do rozmiaru, w jakim faktycznie są pokazywane, i zapisz w nowoczesnym formacie (WebP, a najlepiej AVIF). To zwykle oznacza spadek wagi o 60–80% bez widocznej różnicy w jakości.

Zasoby blokujące renderowanie

Przeglądarka trafia w nagłówku strony na plik ze stylami albo skryptem i wstrzymuje rysowanie, dopóki go nie pobierze. Użytkownik patrzy w tym czasie na białą stronę. To pozycja „Prośby o zablokowanie renderowania”.

Czcionki

Ładowanie kroju z zewnętrznego serwera to dodatkowe połączenie zanim pojawi się jakikolwiek tekst. Efekt to albo pusta przestrzeń w miejscu napisów, albo tekst, który po chwili przeskakuje – i to drugie psuje CLS. Rozwiązanie: trzymać czcionki na własnym serwerze i przewidzieć zastępczy krój o zbliżonych proporcjach.

Skrypty firm trzecich

Czat, piksel reklamowy, mapa, wtyczka z opiniami, narzędzie do zgód na ciasteczka. Każde z osobna wygląda niewinnie, razem potrafią ważyć więcej niż cała reszta strony. To zwykle główny powód słabego INP.

Nie chodzi o to, żeby je wyrzucić, tylko żeby nie ładowały się wszystkie naraz przy starcie. Mapa dojazdu może poczekać, aż ktoś do niej przewinie.

Czego PageSpeed Insights nie sprawdzi

Narzędzie mierzy techniczną stronę wczytywania i tyle. Zielona setka nie znaczy, że strona jest dobra. Nie dowiesz się z niego:

• czy teksty odpowiadają na pytania, które faktycznie zadają Twoi klienci,
• czy strona jest widoczna na frazy, na których Ci zależy,
• czy formularz kontaktowy działa i czy wiadomości do Ciebie docierają,
• czy ktokolwiek klika w Twój przycisk „Zamów wycenę”,
• czy strona jest bezpieczna i aktualna.

Można mieć 100 punktów i zero zapytań. Wydajność jest warunkiem koniecznym, nie wystarczającym – dlatego nasz audyt strony obejmuje też te rzeczy, których żaden automat nie sprawdzi.

Przykład: co wyszło na tej stronie

Żeby nie zostawiać samej teorii – ta strona też dostała raport z czterema uwagami. Co z nich wyszło:

• Obraz w nagłówku – największa pozycja. Przeglądarka pobierała jeden wariant o szerokości 1133 pikseli, choć na typowym monitorze malowała go na około 610. Po dorobieniu kilku rozmiarów i formatu AVIF ten sam obrazek waży 18 kB zamiast 67 kB.
• Dwa arkusze stylów blokujące renderowanie – najpilniejsze style trafiły teraz prosto do kodu strony, a pełne arkusze doczytują się w tle. Do pierwszego wyrysowania strony przeglądarka potrzebuje jednego pliku zamiast trzech.
• Nieużywany kod dla starych przeglądarek – najmniejsza pozycja z całej listy. Raport szacował 11 kB, w rzeczywistości było to nieco ponad kilobajt.

Dwa wnioski z tego ćwiczenia. Pierwszy: pierwsza pozycja z listy była warta tyle, co cała reszta razem – kolejność w raporcie ma sens, zacznij od góry. Drugi: oszacowania bywają zawyżone, więc nie planuj pracy pod obietnicę oszczędności, tylko pod kolejność.

Od czego zacząć

Jeśli masz kwadrans i chcesz wiedzieć, na czym stoisz:

1. Sprawdź stronę główną i jedną podstronę, w zakładce „Telefon”.
2. Zerknij, czy są dane terenowe. Jeśli tak – to jest Twoja realna ocena.
3. Zjedź do diagnostyki i przeczytaj trzy pierwsze pozycje. Resztę na razie pomiń.
4. Jeśli na liście są zdjęcia – zacznij od nich, prawie zawsze to największy zysk.
5. Po poprawkach zrób po trzy pomiary i porównaj mediany, nie pojedyncze odczyty.

Warto też sprawdzić stronę konkurencji – narzędzie działa na każdym publicznym adresie, nie tylko własnym. Bywa pouczające.

Jeśli raport wygląda źle

Czerwony wynik na stronie sprzed kilku lat, opartej na rozbudowanym szablonie z kilkunastoma wtyczkami, to sytuacja typowa – i zwykle nie da się jej naprawić samym skręcaniem obrazków. Wtedy sensowniej policzyć, czy nie taniej wyjdzie modernizacja strony niż łatanie po kolei wszystkiego, co wypisał raport.

Chcesz, żebym przejrzał Twój raport i powiedział, co z tej listy naprawdę ma znaczenie, a co możesz spokojnie zignorować? Napisz do mnie – wystarczy adres strony. Przy okazji zajrzyj do tekstu o wyborze technologii, bo część problemów z wydajnością bierze się nie z zaniedbania, tylko z fundamentu, na którym stronę zbudowano.