Ktoś przesłał ci link do PageSpeed Insights i zobaczyłeś czerwone liczby? Nie panikuj. Te metryki mówią prostym językiem o trzech rzeczach, które klient czuje na swoim telefonie: czy strona w ogóle się wczytała, czy reaguje na kliknięcia i czy wszystko nie przeskakuje pod palcem. Google zaleca właścicielom stron dobre Core Web Vitals dla sukcesu w wyszukiwarce i ogólnego doświadczenia użytkownika. To nie jest wyrok — to mapa, co naprawić w pierwszej kolejności, żeby strona nie odstręczała ludzi, którzy już na nią weszli.
W tym artykule znajdziesz: dokładne progi Google bez żargonu, wyjaśnienie każdej metryki przykładem z twojej branży, schemat jak czytać raport w pięć minut i konkretną kolejność napraw. Dowiesz się też, jak rozmawiać z wykonawcą, żeby nie wydawać pieniędzy na rzeczy, które nie mają sensu.
Trzy metryki, trzy odczucia klienta
Co mierzy LCP i dlaczego to ważne
Każda z trzech metryk Core Web Vitals mierzy coś innego, ale wszystkie odpowiadają na proste pytanie: jak klient czuje się na twojej stronie.
LCP (Largest Contentful Paint) — czas, po którym widać największy element na ekranie. Dla klienta to odpowiedź na pytanie: „czy strona w ogóle działa?". Jeśli otwierasz stronę dentysty, a główne zdjęcie gabinetu ładuje się cztery sekundy — klient myśli, że coś jest nie tak, i zamyka stronę. Dobry LCP to 2,5 sekundy lub mniej; próg mierzy się na 75. percentylu wczytań strony.
Co mierzy INP i dlaczego klient się irytuje
INP (Interaction to Next Paint) — czas reakcji strony na kliknięcie, dotknięcie lub wpisanie tekstu. Dla klienta to odpowiedź na pytanie: „czy strona mnie słucha?". Kiedy klikasz w przycisk „Umów wizytę", a strona milczy pół sekundy, zanim cokolwiek się dzieje — irytuje to. Dobry INP to 200 milisekund lub mniej; powyżej 500 ms uznaje się za słabe.
Co mierzy CLS i dlaczego tekst ucieka
CLS (Cumulative Layout Shift) — ile rzeczy przesuwa się na ekranie podczas czytania. Dla klienta to odpowiedź na pytanie: „czy mogę spokojnie czytać?". Wyobraź sobie, że czytasz opis usługi, nagle wyskakuje baner cookies, tekst ucieka w dół i tracisz miejsce. Strony powinny mieć CLS 0,1 lub mniej, mierzone na 75. percentylu.
| Metryka | Co mierzy | Co czuje klient | Dobry próg |
|---|---|---|---|
| LCP | Czas wczytania największego widocznego elementu | „Czy strona w ogóle działa?" | ≤ 2,5 s |
| INP | Czas reakcji na każdą interakcję | „Czy strona mnie słucha?" | ≤ 200 ms |
| CLS | Łączne przesunięcie układu podczas używania strony | „Czy mogę spokojnie czytać?" | ≤ 0,1 |
Dlaczego 75. percentyl, a nie średnia
Kiedy widzisz w raporcie „LCP 3,2 sekundy", możesz się zastanawiać, skąd ta liczba. Google nie liczy średniej ze wszystkich wizyt. Zamiast tego bierze 75. percentyl — co to oznacza w praktyce?
Weźmy przykład na liczbach umownych — podstaw swoje. Wyobraź sobie, że twoją stronę odwiedza 100 osób w miesiącu. Wyniki wczytań wyglądają tak: 70 osób wczytało stronę w 1,5 sekundy, 10 osób w 3 sekundy, 20 osób w 4 sekundy. Średnia wyniosłaby około 2,15 sekundy i wyglądałaby na dobrą (mniej niż 2,5 sekundy).
Właśnie ta wartość pokazuje się w raporcie, bo Google chce wiedzieć, czy większość użytkowników ma dobry czas, nie czy nieliczni mają fenomenalny.
Dlaczego to ma znaczenie dla ciebie?
Metryka na 75. percentylu mówi ci, czy przynajmniej trzy czwarte klientów nie ma powodów do narzekania.
Dane z pola a dane laboratoryjne w PageSpeed Insights
Kiedy wchodzisz na pagespeed.web.dev i wpisujesz adres swojej strony, widzisz dwa rodzaje danych: z pola i z laboratorium. Warto wiedzieć, czym się różnią i na których się skupić.
Dane z pola (field data) pochodzą od prawdziwych użytkowników, którzy odwiedzili twoją stronę w ostatnich 28 dni. Chrome mierzył ich LCP, INP i CLS w tle i wysłał te informacje do Google. To są dane, którym naprawdę warto ufać, bo pokazują, jak strona działa w realnym świecie — na różnych telefonach, w różnych sieciach, o różnych porach dnia.
Dane laboratoryjne (lab data) pochodzą z symulacji Lighthouse. PageSpeed Insights uruchamia twoją stronę w kontrolowanym środowisku: na średnim smartfonie, w średniej sieci 4G. To jest narzędzie do szukania problemów, nie do oceniania rzeczywistości. Lighthouse może pokazać czerwony LCP, ale jeśli dane z pola są zielone — nie panikuj. Raport może też pokazać, że masz zielone wartości, mimo że użytkownicy narzekają — wtedy dane z pola są ważniejsze.
Dlaczego dane z pola czasem nie istnieją? Jeśli twoja strona ma bardzo mało odwiedzin, Google nie ma wystarczająco dużo danych, żeby pokazać wiarygodne wartości. W takim przypadku musisz polegać na laboratoriach, ale traktuj to jako wskazówkę do poprawy, nie jako ostateczny werdykt.
PageSpeed Insights pokazuje dane laboratoryjne i z pola; nad rozkładem PSI podaje 75. percentyl metryk.
Zasada: decyzję podejmujesz na podstawie danych z pola, problemy szukasz w laboratoriach.
Jak czytać raport PageSpeed Insights w pięć minut
Nie musisz rozumieć każdego wiersza w raporcie. Wystarczy pięć kroków:
- 01Adres
- →02telefon
- →03pole
- →04czerwone
- →05diagnoza
- →06wykonawca
Oto schemat:
Wpisz adres w PageSpeed Insights → otwórz wynik na telefonie → przeczytaj dane z pola na górze → jeśli metryka czerwona, przewiń do diagnostyki → zapisz konkretną informację: „Na stronie usług LCP 4,2 s — główny obrazek".
Najczęstsze przyczyny słabego CLS: obrazy bez wymiarów, reklamy, osadzenia i iframe bez wymiarów, dynamicznie wstrzykiwane treści. Kiedy już wiesz, co jest nie tak, możesz zlecić naprawę konkretnej rzeczy, zamiast mówić „zrób stronę szybszą".
Które podstrony warto mierzyć
Nie musisz sprawdzać każdej podstrony. Wystarczy, że zmierzysz cztery-sześć kluczowych stron i będziesz znał kondycję całego serwisu:
- Strona główna — to twoja wizytówka, najczęściej pierwszy kontakt.
- Dwie-trzy najważniejsze usługi — te, z których ludzie dzwonią najczęściej.
- Strona kontaktów — kiedy ktoś już zdecydował się zadzwonić, nie może mieć problemów z wczytaniem numeru.
W Search Console (search.google.com/search-console) jest sekcja Core Web Vitals, która pokazuje, które adresy mają problemy. Jeśli dziesięć różnych stron usług ma ten sam problem — to wina szablonu, nie pojedynczej strony. W takim przypadku naprawiasz szablon i wszystkie strony się poprawiają jednocześnie.
Co naprawić w pierwszej kolejności — macierz wpływu i trudności
Nie wszystko da się naprawić naraz. Oto priorytety, które pozwolą ci zacząć od tego, co daje najwięcej za najmniej wysiłku:
| Co naprawić | Wpływ na metrykę | Trudność | Kiedy naprawiać |
|---|---|---|---|
| Obrazy bez wymiarów (width/height) | CLS, LCP | Niska | Natychmiast |
| Ciężkie banery graficzne na telefon | LCP | Niska | Natychmiast |
| Skrypty innych firm (czat, mapki, opinie) | INP | Średnia | Po obrazach |
| Czcionki z zewnętrznych serwerów | LCP | Średnia | Po obrazach |
| Wtyczki, które ładują zbędny JavaScript | INP | Średnia | Po czacie |
| Optymalizacja serwera (CDN, kompresja) | LCP | Wysoka | Na końcu |
Najczęstsze przyczyny słabego CLS to obrazy bez wymiarów, reklamy, osadzenia i iframe bez wymiarów oraz dynamicznie wstrzykiwane treści.
Czego nie robić
Zanim wydasz pieniądze na „przyspieszenie strony", zapamiętaj trzy zasady:
Nie gonić za 100 punktami w Lighthouse. Wynik 100 oznacza, że strona jest idealnie zoptymalizowana pod kątem testu, nie pod kątem twoich klientów. Często osiągnięcie 100 wymusza rezygnację z ważnych funkcji (mapek, formularzy, galerii). Celuj w zielone pole, nie w setkę.
Nie instalować „wtyczek przyspieszających" bez pomiaru przed i po. Większość takich wtyczek to zestawy gotowych rozwiązań, które czasem działają, a czasem psują więcej, niż naprawiają. Zmierz stronę przed zmianą, wprowadź jedną zmianę, zmierz ponownie. Dopiero wtedy wiesz, czy to pomogło.
Nie usuwać analityki na ślepo. Google Analytics, Meta Pixel i inne narzędzia to źródło wiedzy o tym, co robią twoi klienci. Zamiast je usuwać, sprawdź, czy ładują się asynchronicznie (nie blokują wczytywania strony). To zwykle wystarczy.
Szybkość strony to nie wszystko
Możesz mieć idealne Core Web Vitals, ale jeśli na stronie nie ma jasnej oferty — klient i tak nie zadzwoni. Strona może wczytywać się w sekundę, ale jeśli nie wiadomo, co oferujesz, za ile i jak zamówić, żadna prędkość nie pomoże.
Zanim wydasz pieniądze na optymalizację techniczną, sprawdź, czy strona ma: nagłówek z nazwą i główną usługą, cennik lub jasny przycisk do kontaktu, instrukcję jak zamówić. Jeśli tego nie ma, żadna prędkość nie zastąpi treści. Więcej o tym, dlaczego klienci nie zostawiają zapytań, przeczytasz w artykule Dlaczego klienci nie zostawiają zapytań. A o tym, jak dane restauracji wpływają na widoczność, przeczytaj w artykule Dane restauracji w Google i na portalach.
Zrób to sam za jeden wieczór
Nie potrzebujesz programisty, żeby zacząć. Oto pięć kroków, które wykonasz dziś wieczorem:
- Wejdź na pagespeed.web.dev i wpisz adres swojej strony głównej.
- Zrób to samo dla dwóch najważniejszych usług i strony kontaktów.
- Zapisz w tabeli (może być w Excelu lub na kartce): adres strony, LCP, INP, CLS — z kolorem zielonym, bursztynowym lub czerwonym.
- Dla każdej czerwonej metryki przeczytaj jedną linię w sekcji „Diagnostyka" — to podpowiedź, co jest nie tak.
- Wyślij wykonawcy wiadomość: „Na stronie [adres] mam [metryka] [wartość], wynik sugeruje [opis z diagnostyki]. Proszę o wycenę naprawy tego konkretnego elementu."
Powtórz pomiar po wprowadzeniu zmian. Jeśli wykonawca mówi, że coś jest niewykonalne albo drogie — wróć do tego artykułu, sprawdź, czy to faktycznie priorytet, i zdecyduj, czy warto.
Jak to wygląda, kiedy za prędkość strony odpowiada system
Ręczne sprawdzanie PageSpeed Insights raz na kwartał to dobry start, ale łatwo o tym zapomnieć. Lepiej zamienić to w stały rytm: regularnie mierzyć kluczowe strony w polu (dane realnych użytkowników), generować raport z metrykami, zamieniać czerwone wartości na konkretne zadania i powtarzać pomiar po wprowadzeniu zmian. Rezultat to historia zmian, którą widzisz czarno na białym: było źle, zrobiliśmy X, teraz jest lepiej.
Kiedy zamawiasz stronę internetową, od pierwszego dnia dostajesz wersję mobilną jako główną, podstawową konfigurację SEO i analitykę. Najczęstszy błąd to publikacja strony bez pomiaru — dlatego warto sprawdzić wyniki zaraz po uruchomieniu. Zobacz, jak to działa, na stronie usług w Warszawie.
Jeśli interesuje cię też konwersja na stronie, wyszukiwanie w Google, projektowanie interfejsów lub pomiar wyników — możemy zrobić pełny audyt twojego serwisu. Więcej o tym, jak mierzyć wyniki, przeczytasz w artykule Automatyzacja raportowania. Z kolei o tym, od czego zacząć automatyzację w małej firmie, piszemy w poradniku Od czego zacząć automatyzację.
Najczęściej zadawane pytania
Czy muszę mieć zielone Core Web Vitals, żeby być wysoko w Google?
Google bierze pod uwagę wiele czynników. Dobre Core Web Vitals to jeden z sygnałów, który może pomóc, ale sam nie gwarantuje pozycji. Strona ze świetnymi metrykami, ale bez treści i bez wartości dla użytkownika, nie wyprzedzi strony z nieco gorszymi metrykami, ale z lepszą odpowiedzią na pytanie klienta.
Co zrobić, gdy PageSpeed Insights pokazuje dane z pola, ale moja strona ma mało odwiedzin?
Jeśli masz mniej niż kilkaset wizyt miesięcznie, Google może nie mieć wystarczająco dużo danych. W takim przypadku polegaj na danych laboratoryjnych (Lighthouse) jako wskazówce, ale traktuj je z przymrużeniem oka — testuje na sztucznych warunkach. Najlepiej w takiej sytuacji po prostu zadbać o podstawy: optymalne obrazy, brak zbędnych skryptów, działający kod HTML.
Czy mogę sam naprawić CLS, jeśli nie znam HTML?
Często tak. Najczęstszy powód słabego CLS to obrazy bez wymiarów. Jeśli używasz WordPressa lub innego CMS, w większości przypadków wystarczy dodać atrybuty width i height do obrazka w edytorze. W kreatorach stron (Wix, Webflow, GoDaddy) — sprawdź w ustawieniach galerii lub w opcjach obrazka.
Ile kosztuje naprawa Core Web Vitals?
To zależy od problemu. Dodanie wymiarów do obrazów to minuta pracy — nawet darmowa, jeśli robisz to sam. Optymalizacja serwera lub przepisanie kodu pod duży ruch to większy projekt. Klucz to zacząć od pomiaru i konkretnego problemu, nie od ogólnego „przyspiesz stronę".
Czy usunięcie wtyczek zawsze pomaga?
Nie zawsze. Czasem wtyczka jest niezbędna (np. formularz kontaktowy, mapka Google). Zamiast usuwać, sprawdź, czy istnieje lżejsza alternatywa lub czy wtyczka ma opcję ładowania asynchronicznego. Czasem jedna wtyczka spowalnia stronę bardziej niż dziesięć innych — warto zmierzyć, która.
Jak często powinienem sprawdzać Core Web Vitals?
Po wprowadzeniu zmian — w ciągu tygodnia, żeby potwierdzić, że pomogło. Potem wystarczy raz na kwartał, chyba że dodajesz nowe funkcje (nowe galerie, wtyczki, integracje) — wtedy sprawdź po każdej zmianie.