PageSpeed a ranking Google 2026: co naprawdę ma znaczenie

Część przewodnika: SEO lokalne 2026, kompletny przewodnik dla małej firmy →
Ten artykuł wyjaśnia techniczny fragment SEO: co naprawdę pokazuje PageSpeed Insights i jak przekładać raport na decyzje.

Właściciel strony widzi czerwone 48 punktów na telefonie i zwykle pyta: „ile pozycji przez to tracę?”. Tego nie da się wiarygodnie przeliczyć. Google nie publikuje tabeli, w której 49 punktów oznacza spadek o trzy miejsca, a 90 punktów daje awans. Sam wynik PageSpeed nie jest też oceną całego SEO.

To nie znaczy, że szybkość można zignorować. Strona, która długo pokazuje główną treść, blokuje się po kliknięciu albo przesuwa formularz, utrudnia klientowi wykonanie zadania. Google uwzględnia Core Web Vitals w systemach rankingowych, ale nie obiecuje wysokiej pozycji za dobre wyniki. PageSpeed Insights pomaga sprawdzić problem. Trzeba tylko wiedzieć, na którą część raportu patrzeć.

PageSpeed Insights nie jest jedną oceną strony

PageSpeed Insights łączy dwa rodzaje pomiaru:

Dane terenowe CrUX pokazują zagregowane doświadczenia rzeczywistych użytkowników Chrome z poprzednich 28 dni. To w tej części znajdują się LCP, INP i CLS używane do oceny Core Web Vitals.
Dane laboratoryjne Lighthouse powstają podczas pojedynczego, syntetycznego testu. Dostajesz wynik Performance 0–100, metryki ładowania i listę diagnostycznych wskazówek.

Oficjalna dokumentacja PageSpeed Insights opisuje dokładnie ten podział. Dane terenowe mówią, co spotykało użytkowników. Laboratorium pomaga odtworzyć problem w powtarzalnych warunkach. Jeden zestaw nie zastępuje drugiego.

Jeśli górna sekcja nie zawiera danych, strona nie musi być wolna. Nowy lub rzadko odwiedzany adres może mieć za mało kwalifikujących się wizyt w CrUX. PageSpeed Insights może wtedy pokazać dane całego originu, czyli w uproszczeniu domeny z protokołem, albo nie pokazać danych terenowych wcale.

Co oznacza wynik Lighthouse 0–100

Wynik Performance jest ważoną oceną kilku metryk laboratoryjnych. Obecna metoda punktacji Lighthouse uwzględnia FCP, Speed Index, LCP, TBT i CLS. Każda metryka ma własną wagę, a wynik zależy od warunków testu.

Lighthouse koloruje zakresy tak:

90–100: dobry, kolor zielony,
50–89: wymaga poprawy, kolor pomarańczowy,
0–49: słaby, kolor czerwony.

To progi interfejsu narzędzia, nie progi widoczności w Google. Nie istnieje „minimalne 80 dla małej firmy” ani zasada, że 90 punktów na komputerze kompensuje 45 na telefonie.

Dwa przebiegi tego samego testu mogą się różnić

Przebieg A 58/100

Przebieg B 91/100

Przykład ilustracyjny, nie wynik Lokal360. Dlatego porównuj medianę kilku pomiarów w tych samych warunkach, zamiast wybierać najlepszy przebieg.

Na wynik wpływają między innymi obciążenie urządzenia, sieć, rozszerzenia przeglądarki, zawartość cache i chwilowa odpowiedź serwera. W PageSpeed Insights warunki testu są standaryzowane, ale kolejne uruchomienia nadal mogą się różnić. Ocena 89 i 91 nie oznacza nagłej zmiany jakości strony ani przeskoczenia niewidzialnego progu SEO.

Core Web Vitals to nie wynik 0–100

Core Web Vitals są trzema konkretnymi metrykami. Google ocenia ich 75. percentyl, osobno dla urządzeń mobilnych i komputerów. Dobry wynik oznacza, że co najmniej 75% zarejestrowanych wizyt osiągnęło dany próg lub wynik lepszy.

Metryka	Co opisuje	Dobry wynik	Wymaga poprawy	Słaby wynik
LCP	czas wyświetlenia największego elementu w początkowym widoku	≤ 2,5 s	> 2,5 s i ≤ 4 s	> 4 s
INP	responsywność podczas interakcji w trakcie wizyty	≤ 200 ms	> 200 ms i ≤ 500 ms	> 500 ms
CLS	największą serię nieoczekiwanych przesunięć układu	≤ 0,1	> 0,1 i ≤ 0,25	> 0,25

Ocena przechodzi tylko wtedy, gdy wszystkie trzy metryki są dobre i istnieje dla nich wystarczająca próbka. Pełne definicje i sposób obliczenia znajdziesz w naszym przewodniku po Core Web Vitals 2026 oraz w oficjalnym materiale Web Vitals.

Lighthouse nie mierzy terenowego INP podczas zwykłego testu ładowania. Wykorzystuje TBT jako laboratoryjny sygnał blokowania głównego wątku, ale TBT i INP nie są tym samym. Aby zbadać wolne kliknięcie, nagraj tę interakcję w Chrome DevTools, użyj biblioteki Web Vitals we własnym RUM lub odpowiedniego rozszerzenia.

Które dane wybrać, gdy raporty się różnią

Rozbieżność nie musi oznaczać błędu. Cztery sytuacje zdarzają się regularnie:

Wynik CrUX	Lighthouse	Rozsądna interpretacja
słaby	słaby	problem jest widoczny w terenie i można go odtworzyć w laboratorium
słaby	dobry	test nie odtworzył urządzeń, sieci, interakcji albo podstron, na których cierpią użytkownicy
dobry	słaby	pojedynczy test mógł trafić na gorsze warunki lub ujawnić regresję, której 28-dniowe okno jeszcze nie pokazuje
brak danych	dowolny	próbka CrUX jest za mała; potrzebujesz laboratorium i ewentualnie własnego RUM

Zawsze sprawdź, czy CrUX pokazuje konkretny URL, czy cały origin. Dane originu mogą być zdominowane przez najpopularniejsze podstrony i nie dowodzą, że testowany formularz działa tak samo. Z kolei raport Core Web Vitals w Search Console grupuje podobne adresy. To dobre narzędzie do oceny skali, ale nie debugger pojedynczego elementu.

Metodologia CrUX wyjaśnia źródło danych i kryteria kwalifikacji. Jeśli chcesz sprawdzić więcej niż wydajność, przejdź przez bezpłatne narzędzia do audytu strony albo uruchom nasz audyt strony.

Jak PageSpeed wpływa na ranking Google

Google mówi o tym ostrożniej niż wiele ofert SEO:

nie ma jednego sygnału „page experience”,
Core Web Vitals są używane przez systemy rankingowe,
dobry wynik w Search Console lub zewnętrznym narzędziu nie gwarantuje czołowej pozycji,
pogoń za idealną punktacją wyłącznie dla SEO może nie być dobrym wykorzystaniem czasu,
Google nadal stara się pokazać najbardziej trafną treść, nawet jeśli jej page experience jest słabsze.

Nie da się więc uczciwie napisać, że strona z LCP powyżej 2,5 s „nie wejdzie do TOP 10” albo że 28 dni czerwonego wyniku automatycznie uruchamia spadek. Google nie publikuje takiej reguły. Równie ryzykowne jest nazywanie szybkości prostym „tie-breakerem”, bo dokumentacja mówi o wielu sygnałach i ocenach, a nie o pojedynczym remisie.

Praktyczny wniosek jest mniej efektowny, ale użyteczny. Jeśli dwie podstrony odpowiadają na pytanie, strona wygodniejsza w użyciu ma mniej przeszkód. Nie zastąpi to sensownej oferty, lokalnej trafności ani treści. Dlatego optymalizację wydajności warto osadzić w szerszym planie pozycjonowania w Google.

Jak czytać raport PageSpeed Insights krok po kroku

1. Ustal zakres danych terenowych

Na górze raportu wybierz urządzenie i sprawdź, czy dane dotyczą URL-a czy originu. Zanotuj okres, wartości LCP, INP i CLS oraz rozkład zielonych, pomarańczowych i czerwonych wizyt. Nie patrz tylko na komunikat „zaliczone” lub „niezaliczone”. Rozkład pokaże, czy problem dotyczy małego ogona, czy większości użytkowników.

2. Wybierz metrykę, która wymaga pracy

Jeśli nie przechodzi LCP, nie zaczynaj od CLS. Jeśli CrUX jest zielony, ale sprzedaż cierpi przez powolny formularz, sprawdź konkretną interakcję, nawet gdy ogólna ocena wygląda dobrze. Raport jest wsparciem decyzji, a nie listą poleceń do mechanicznego wykonania.

3. Znajdź przyczynę w Lighthouse

Otwórz sekcje diagnostyczne i odfiltruj wskazówki związane z problemem. Szacowana oszczędność transferu lub czasu jest przybliżeniem w warunkach testu. Nie sumuj wszystkich wartości, bo audyty często opisują nakładające się problemy.

4. Sprawdź element lub interakcję ręcznie

Raport może wskazać element LCP, nieużywany JavaScript albo przesunięcia układu. Otwórz stronę na małym ekranie, użyj panelu Performance i potwierdź zachowanie. Szczególnie INP wymaga nagrania realnej interakcji, której zwykłe ładowanie Lighthouse nie wykonuje.

5. Nadaj poprawkom priorytet biznesowy

Najpierw poprawiaj problemy na stronach, które mają ruch i realizują ważne zadanie: ofertę, kontakt, rezerwację lub zakup. Oszczędzenie 400 ms na formularzu używanym codziennie może być warte więcej niż dojście z 96 do 100 na mało czytanym regulaminie.

Priorytety napraw według metryki

Gdy problemem jest LCP

Najpierw wskaż element LCP i rozbij czas na odpowiedź serwera, opóźnienie odkrycia zasobu, pobieranie i renderowanie.

Przy wysokim TTFB sprawdź cache, backend, bazę danych, CDN i region hostingu.
Gdy obraz hero jest odkrywany późno, umieść go w HTML, rozważ preload i fetchpriority="high".
Nie używaj loading="lazy" dla obrazu LCP. Lazy loading zostaw dla treści poniżej pierwszego ekranu.
Dopasuj rozdzielczość przez srcset, skompresuj plik i użyj odpowiedniego formatu.
Ogranicz CSS i JavaScript blokujące pierwszy render. Nie chowaj gotowej treści do końca animacji.

Osobna instrukcja dlaczego strona ładuje się wolno pomaga rozdzielić problem serwera, zasobu i kodu.

Gdy problemem jest INP

Nagraj powolne kliknięcie, dotknięcie albo wpisywanie. Następnie znajdź długie zadania na głównym wątku.

uprość funkcje obsługi zdarzeń,
dziel długą pracę na mniejsze porcje, aby przeglądarka mogła odmalować ekran,
ładuj kod tylko na podstronach, które go potrzebują,
ogranicz koszt czatów, reklam, trackerów i innych skryptów zewnętrznych,
unikaj wymuszanych przeliczeń układu i zmniejsz zbyt duży DOM,
pokaż od razu stan ładowania, jeśli operacja trwa dłużej.

TBT może naprowadzić na ciężki JavaScript, ale naprawę potwierdź pomiarem interakcji, nie samym wzrostem punktacji.

Gdy problemem jest CLS

Odtwórz przesunięcie i ustal, który element zmienia pozycję.

podawaj wymiary albo aspect-ratio dla obrazów, filmów i ramek,
rezerwuj miejsce na mapy, reklamy, formularze i widgety,
nie wstawiaj komunikatów nad czytany tekst bez działania użytkownika,
dobierz font zastępczy o zbliżonych metrykach i ładuj potrzebny krój odpowiednio wcześnie,
animuj transform oraz opacity, zamiast właściwości przebudowujących układ.

Sama instalacja wtyczki cache nie naprawi CLS, jeśli baner zgody po załadowaniu wpycha stronę w dół.

Pomiar przed i po wdrożeniu

Pojedynczy zielony test po zmianie jest zbyt słabym dowodem. Ustal prosty protokół:

Wybierz reprezentatywne adresy: stronę główną, ofertę, popularny artykuł i formularz.
Zapisz CrUX przed zmianą: urządzenie, URL lub origin, datę, LCP, INP i CLS.
Uruchom 3–5 testów Lighthouse w tych samych warunkach i zapisz medianę oraz główne diagnozy.
Wdróż jedną grupę zmian, na przykład obrazy LCP, zamiast przebudowywać wszystko naraz.
Powtórz testy laboratoryjne. Sprawdź też funkcjonalność, dostępność i konwersję.
Jeśli masz RUM, obserwuj nowe wizyty od chwili wdrożenia.
Monitoruj CrUX przez kolejne dni. Pełne 28-dniowe okno po zmianie nie zawiera już wizyt sprzed wdrożenia, ale raport może reagować wcześniej i stopniowo.

Nie przypisuj zmian pozycji wyłącznie wydajności. W tym samym czasie mogą zmienić się treści konkurencji, linki, sezonowość i systemy Google. Zapis wdrożeń i adnotacje w analityce pomagają odróżnić korelację od przyczyny.

WordPress, statyczny HTML i mit gwarantowanych 99 punktów

Technologia wpływa na liczbę miejsc, w których może pojawić się problem, ale nie gwarantuje wyniku. WordPress z lekkim motywem, cache i rozsądną liczbą dodatków może działać bardzo dobrze. Strona statyczna może być wolna, jeśli pobiera ogromny film, ciężkie fonty i kilka pakietów JavaScript.

Statyczne generowanie zwykle upraszcza drogę do szybkiego HTML-a, bo serwer nie musi składać każdej podstrony przy żądaniu. To przewaga architektoniczna, nie certyfikat 99/100. Wybór platformy powinien uwzględniać sposób edycji, potrzebne funkcje i koszt utrzymania. Pomaga w tym uczciwe porównanie WordPressa i strony statycznej.

Migracja ma sens, gdy obecna platforma stale utrudnia utrzymanie, rozwój albo wydajność. Nie warto przebudowywać strony tylko po to, by zmienić kolor jednego testu. Najpierw audyt, potem decyzja między optymalizacją a migracją z WordPressa. Nowa strona internetowa powinna mieć budżet wydajności i monitoring od początku, niezależnie od technologii.

Co zrobić teraz

Zacznij od najważniejszego szablonu i zapisz punkt wyjścia. Sprawdź CrUX, wykonaj kilka powtarzalnych testów, znajdź konkretną przyczynę i wdroż jedną grupę zmian. Potem zmierz ponownie. Taki proces daje więcej niż przypadkowe odhaczanie wszystkich sugestii w nadziei na 100 punktów.

Najczęstsze pytania

Czy wynik PageSpeed jest czynnikiem rankingowym Google?

Nie należy traktować wyniku Performance 0–100 jako bezpośredniego czynnika rankingowego. To ocena laboratoryjna Lighthouse. Google wykorzystuje Core Web Vitals w systemach rankingowych, ale nie ma jednego sygnału page experience, a dobry wynik nie gwarantuje wysokiej pozycji.

Jaki wynik PageSpeed jest dobry?

Lighthouse oznacza wynik Performance 90–100 kolorem zielonym, 50–89 pomarańczowym, a 0–49 czerwonym. Te zakresy pomagają czytać test laboratoryjny, lecz nie są progami rankingu. Ważniejsze jest usunięcie problemów odczuwanych przez użytkowników i uzyskanie dobrych danych Core Web Vitals.

Czym różnią się Lighthouse i CrUX?

Lighthouse symuluje pojedyncze ładowanie strony w kontrolowanych warunkach i służy do diagnozy. CrUX agreguje kwalifikujące się wizyty rzeczywistych użytkowników Chrome z ostatnich 28 dni. Wyniki mogą się różnić, ponieważ odpowiadają na inne pytania.

Czy PageSpeed Insights mierzy Core Web Vitals?

PageSpeed Insights pokazuje Core Web Vitals z danych terenowych CrUX, jeśli dostępna jest wystarczająca próbka dla adresu lub originu. Niżej prezentuje oddzielny test Lighthouse. Wynik 0–100 z Lighthouse nie jest oceną Core Web Vitals.

Co poprawić najpierw w raporcie PageSpeed Insights?

Najpierw sprawdź, czy dane terenowe dotyczą badanego URL-a czy całego originu i która metryka Core Web Vitals nie przechodzi. Potem użyj diagnostyki Lighthouse do znalezienia konkretnego elementu LCP, przesunięcia CLS albo pracy JavaScript związanej z wolną interakcją.

Kiedy zobaczę efekt optymalizacji?

Lighthouse może pokazać zmianę zaraz po wdrożeniu. W CrUX efekt pojawia się stopniowo, ponieważ raport obejmuje kroczące 28 dni wizyt. Nie ma oficjalnego terminu ani gwarancji zmiany pozycji; ranking zależy od wielu sygnałów, przede wszystkim od trafności i jakości treści.

PageSpeed jako ranking factor 2026, co liczy Google