PageSpeed Insights i Core Web Vitals: jak Google naprawdę mierzy jakość strony w 2025 roku

Większość osób, które po raz pierwszy uruchamiają test PageSpeed Insights, widzi kolorowe liczby i zastanawia się, czy wynik 72 oznacza coś dobrego, czy złego. Tymczasem szybkość strony od dawna nie jest tylko technicznym szczegółem – to realny czynnik wpływający na widoczność w Google, konwersje i zadowolenie użytkowników. Problem w tym, że wielu twórców stron i specjalistów SEO nadal traktuje wynik PageSpeed Insights jak rankingowy „score”. W rzeczywistości Google patrzy na wydajność znacznie szerzej – przez pryzmat Core Web Vitals, danych rzeczywistych (field data) i doświadczenia użytkownika. W tym artykule pokazuję, jak Google mierzy jakość stron, co znaczą metryki PSI, jakie zmiany wprowadziło INP i jak prawidłowo interpretować wyniki w 2025 roku.

PageSpeed Insights mierzone przez Google

Spis treści

1. Czym właściwie jest PageSpeed Insights?

PageSpeed Insights (PSI) to narzędzie Google, które analizuje stronę pod kątem wydajności i doświadczenia użytkownika. Wynik końcowy (0–100) to syntetyczna ocena z testu Lighthouse, ale raport zawiera też dane rzeczywiste (tzw. field data) z Chrome User Experience Report (CrUX) – anonimowo zebrane z przeglądarek użytkowników.

Zrozumienie różnicy między danymi laboratoryjnymi (lab data) a rzeczywistymi (field data) to podstawa:

Field data → to dane z prawdziwych użytkowników (CrUX), które wpływają na ocenę w Google Search Console i w rankingu.
Lab data → to dane testowe (symulacja Lighthouse), użyteczne do diagnozy problemów, ale nie brane bezpośrednio pod uwagę przez algorytmy rankingowe.

Dlatego można mieć stronę z wynikiem PSI 60/100, a mimo to doskonałe Core Web Vitals – i odwrotnie.

2. Core Web Vitals – kluczowe wskaźniki jakości strony

Google wyróżnia trzy główne wskaźniki, które wchodzą w skład Core Web Vitals (CWV). W 2025 roku ich lista wygląda następująco:

LCP (Largest Contentful Paint) – czas, w jakim największy element treściowy pojawia się na ekranie.
👉 Dobry wynik: ≤ 2,5 s

CLS (Cumulative Layout Shift) – stabilność wizualna strony (czy elementy „skaczą” podczas ładowania).
👉 Dobry wynik: ≤ 0,1

INP (Interaction to Next Paint) – nowy wskaźnik, który zastąpił FID (First Input Delay). Mierzy pełny czas reakcji strony na interakcję użytkownika (kliknięcie, przewinięcie, wpisanie tekstu).
👉 Dobry wynik: ≤ 200 ms

To właśnie te trzy wskaźniki są analizowane w raportach Search Console i w raportach CrUX.

Google potwierdza, że Core Web Vitals są jednym z czynników rankingowych, ale nie wprost — traktuje je jako część „Page Experience signals”. Innymi słowy: dobra wydajność nie gwarantuje topów, ale zła niemal zawsze szkodzi.

LCP, CLS, INP - Core Web Vitals

3. INP – największa zmiana w 2025 roku

W marcu 2024 roku Google oficjalnie zastąpił metrykę FID nową – INP (Interaction to Next Paint).

Dlaczego? Bo FID mierzył tylko pierwszą interakcję użytkownika z witryną, a INP analizuje pełne doświadczenie interaktywności – przez cały czas korzystania z witryny.

INP uwzględnia trzy fazy:

czas do rozpoczęcia obsługi zdarzenia (input delay),
czas przetwarzania zdarzenia (processing time),
czas do ponownego renderowania (presentation delay).

Z praktycznego punktu widzenia: Jeśli Twoja strona ma dużo JavaScriptu, animacji lub ciężkich komponentów SPA, właśnie INP pokaże, że użytkownik czeka zbyt długo na reakcję.

Google rekomenduje optymalizację przez:

redukcję „long tasks” w JS (podział kodu, lazy-loading),
delegowanie eventów (event delegation),
korzystanie z Web Workers do operacji ciężkich obliczeniowo,
stosowanie requestIdleCallback() i scheduler.yield().

4. Jak Google mierzy wydajność: dane z CrUX i Lighthouse

Google łączy dwa źródła danych:

CrUX (Chrome UX Report) – to dane z rzeczywistych wizyt użytkowników w Chrome.
Są aktualizowane co 28 dni i pokazują wyniki z podziałem na mobile i desktop.
Lighthouse – to narzędzie testowe, które wykonuje serię audytów w kontrolowanym środowisku (np. z ograniczoną przepustowością sieci).

Wynik PageSpeed Insights to połączenie obu:

górna część raportu → dane CrUX (prawdziwi użytkownicy),
dolna część → Lighthouse (symulacja).

To dlatego w wynikach PSI często widzisz np.:

„Raport nie zawiera danych o rzeczywistych użytkownikach”

Oznacza to po prostu, że Twoja strona ma zbyt mały ruch, by znaleźć się w bazie CrUX.

5. Jak interpretować raport PSI jak ekspert

PSI nie mówi Ci tylko, co jest źle — pokazuje, co naprawdę spowalnia użytkownika.

Najważniejsze sekcje:

Opportunities (Szanse) – wskazówki, co skróci czas ładowania (np. kompresja obrazów, minifikacja JS).
Diagnostics (Diagnostyka) – techniczne rekomendacje (np. błędy w cache, layout shifts).
Passed audits (Zaliczono) – wszystko, co działa dobrze (warto monitorować, żeby nie zepsuć).

Nie każda sugestia PSI ma znaczenie dla SEO. Niektóre audyty Lighthouse’a (np. „zredukować rozmiar DOM”) mają znaczenie tylko w testach syntetycznych – nie wpływają bezpośrednio na Core Web Vitals.

PSI a SEO

6. Czy wynik PSI ma wpływ na SEO?

Nie.

Google nie używa punktacji PSI (0–100) jako sygnału rankingowego. To tylko syntetyczny wynik Lighthouse’a, stworzony do diagnozy problemów.

Natomiast realne dane Core Web Vitals z CrUX – już tak.

To one są brane pod uwagę w algorytmach „Page Experience”.

Dlatego Twoim celem nie jest „100/100”, tylko:

LCP ≤ 2,5 s
CLS ≤ 0,1
INP ≤ 200 ms

I utrzymanie tych wartości dla 75. percentyla użytkowników.

7. Jak poprawić wyniki zgodnie z rekomendacjami Google

Oficjalne wytyczne znajdziesz na web.dev, ale poniżej skrót praktyki z dokumentacji:

Najważniejsze zasady:

Minimalizuj liczbę zasobów blokujących renderowanie (JS/CSS).
Używaj atrybutu fetchpriority=”high” dla kluczowych obrazów.
Optymalizuj hero image (LCP) – preload + odpowiedni format (AVIF/WebP).
Stosuj atrybuty width i height, by zapobiec CLS.
Podziel duże skrypty JS (code splitting).
Używaj CDN i cache HTTP/2 lub HTTP/3.
Testuj na mobile, nie tylko desktop.

Google zachęca też do używania PageSpeed Insights API i Lighthouse CI, by zautomatyzować audyty w procesie wdrożeniowym (CI/CD).

Narzędzia Google do monitorowania Core Web Vitals

8. Jak monitorować Core Web Vitals

Do bieżącego monitoringu możesz wykorzystać:

Google Search Console – raport „Podstawowe wskaźniki internetowe” (dla całej domeny).
Chrome User Experience Report (CrUX) – dane z realnych użytkowników.
PSI API – integracja wyników z raportami, np. w Looker Studio.
Lighthouse CI – testy wydajności w pipeline’ach developerskich.

Dzięki temu możesz wykrywać regresje wydajności automatycznie, zanim spadnie wynik w SERP.

9. Przykładowe przypadki optymalizacji

Case 1: Strona WordPress z builderem (Elementor, WPBakery)

Po włączeniu cache serwera + optymalizacji obrazów (ShortPixel) + critical CSS + preloading hero image — LCP spadło z 4,2 s do 2,1 s, INP poprawiło się z 280 ms do 180 ms.

Case 2: Strona React/Next.js

Wdrożenie code-splittingu i React.lazy() skróciło INP o 45%, a CLS spadło z 0,24 do 0,09.