PageSpeed jako ranking factor 2026, co liczy Google

Część przewodnika: SEO lokalne 2026, kompletny przewodnik dla małej firmy →
Ten artykuł rozwija jeden z wątków pełnego przewodnika.

W skrócie: PageSpeed nie jest najmocniejszym ranking factor (Google traktuje go jako sygnał lekki, rozstrzygający między podobnie mocnymi stronami), ale w 2026 strona z LCP > 2,5 s nie pojawia się w top 10 dla konkurencyjnych zapytań.

• Cele 2026: LCP < 2,5 s, INP < 200 ms, CLS < 0,1
• Strona statyczna HTML: PageSpeed 99/100 out-of-the-box
• WordPress: wymaga optymalizacji (WP Rocket, Perfmatters, premium hosting), 1 200-3 000 zł/rok

Bardzo wolna strona praktycznie nie ma szans w lokalnym SEO. Google obniża pozycję, klient zamyka zakładkę zanim cokolwiek zobaczy, coraz więcej osób wychodzi od razu, ranking spada jeszcze niżej. Spirala śmierci, której najtańsza strona „za 200 zł” nigdy się nie pozbędzie.

Co dokładnie liczy się w 2026. Core Web Vitals

Google używa trzech głównych metryk Core Web Vitals jako bezpośredniego sygnału rankingowego:

LCP (Largest Contentful Paint)

Kiedy ładuje się największy widoczny element strony (zwykle banner / nagłówek hero / główne zdjęcie). Mierzy moment, w którym użytkownik widzi „znaczącą” treść.

Cel: < 2,5s Średnio: 2,5-4s Czerwone: > 4s

Co psuje LCP: za duże obrazy bez optymalizacji, brak fetchpriority="high" na banerze, blokujący CSS/JS, wolny serwer (TTFB > 600ms).

CLS (Cumulative Layout Shift)

Czy strona „skacze” podczas ładowania. Jeśli użytkownik zaczyna czytać tekst, a po sekundzie pojawia się banner i przesuwa cały content w dół, to CLS. Frustrujące, szczególnie na mobile (kliknąłeś w przycisk, on się przesunął, kliknąłeś coś innego).

Cel: < 0,1 Średnio: 0,1-0,25 Czerwone: > 0,25

Co psuje CLS: obrazy bez width i height, fonty zmieniające metryki tekstu po załadowaniu (FOUT/FOIT), reklamy ładujące się dynamicznie, popupy bez stałych wymiarów.

INP (Interaction to Next Paint)

Jak szybko strona reaguje na kliknięcie / dotyk / wpis w formularzu. Zastąpiło FID (First Input Delay) w marcu 2024. INP mierzy całą sesję, nie tylko pierwsze kliknięcie.

Cel: < 200ms Średnio: 200-500ms Czerwone: > 500ms

Co psuje INP: ciężki JavaScript blokujący główny wątek, długie task’i (>50ms), źle napisane event listenery, wolny renderer (głównie WordPress z 15 wtyczkami).

Plus uzupełniające metryki

• TTFB (Time to First Byte), czas od żądania do pierwszego bajtu odpowiedzi serwera. Cel: < 200ms. Wolny TTFB = wolny hosting albo wolny backend.
• FCP (First Contentful Paint), kiedy ładuje się pierwsza widoczna treść. Cel: < 1,8s.
• TBT (Total Blocking Time), łączny czas blokowania głównego wątku przez ciężki JS.
• Speed Index, wizualna szybkość ładowania.

Jak PageSpeed przekłada się na biznes, twarde dane

Dwa najczęściej cytowane badania:

• Google/SOASTA (badanie zachowań mobile, 2017): gdy czas ładowania rośnie z 1 do 3 sekund, prawdopodobieństwo, że użytkownik od razu wyjdzie ze strony, rośnie o 32%. Ponad połowa (53%) użytkowników mobile porzuca stronę ładującą się dłużej niż 3 sekundy.
• Google/Deloitte, raport „Milliseconds Make Millions” (2020): poprawa szybkości mobile o zaledwie 0,1 sekundy dała średnio +8,4% konwersji w retailu i +10,1% w travel, a na stronach lead-gen poprawiła bounce rate o 8,3%.

Konkret: wolna strona nie zabija ruchu, zabija konwersję z ruchu, który już masz. Ci sami odwiedzający, mniej zapytań.

Ładowanie 1 s poziom bazowy

Ładowanie 3 s +32% bounce

Dane Google/SOASTA (2017): wzrost czasu ładowania z 1 s do 3 s zwiększa prawdopodobieństwo porzucenia strony o 32%. Strata jest stała, miesiąc po miesiącu.

Druga warstwa: Google obniża ranking strony, której Core Web Vitals są w „poor” przez 28 dni z rzędu. To znaczy, że spadek ruchu z PageSpeed nie tylko bierze się z odbijania klientów, algorytm wprost nie pokazuje Twojej strony, bo wie, że użytkownik nie da rady się załadować.

Czemu strony statyczne wygrywają natywnie

Strony statyczne (HTML/CSS bez WordPressa, bez frameworków JS jak React czy Vue) ładują się natywnie szybko, bo:

• Brak bazy danych → brak czasu na zapytania SQL
• Brak PHP → brak czasu na generowanie strony po stronie serwera (gotowy plik HTML)
• Brak wtyczek → brak ekstra JS i CSS
• Mały rozmiar → pełna strona w 50-100 KB (vs 2-5 MB typowy WordPress)
• CDN-friendly → statyczny cache działa idealnie, każdy użytkownik dostaje stronę z najbliższego serwera

Efekt: strona ładuje się w 0,5-1 sekundę na mobile, PageSpeed 99/100 standardowo, Core Web Vitals wszystkie w „good”.

Strony Lokal360 są pisane w czystym HTML/CSS dokładnie z tego powodu. PageSpeed 99/100 mobile i desktop standardowo, bez optymalizacji. Generowanie strony przez Astro (statyczny generator), serwowanie przez CDN, brak runtime JavaScript poza minimalnymi event handlerami.

Porównanie ze średnią stroną WordPressową:

Metryka	WordPress (motyw + 10 wtyczek)	Strona statyczna
LCP mobile	3,5-6s	0,8-1,2s
CLS	0,15-0,4	0,02-0,05
INP	300-800ms	50-120ms
TTFB	400-1500ms	50-150ms
Rozmiar strony	2-5 MB	80-200 KB
PageSpeed mobile	30-65	95-100

Więcej: WordPress vs strona statyczna 2026.

Co zrobić, jeśli masz wolną stronę, plan działania

Krok 1, pomiar

1. PageSpeed Insights (pagespeed.web.dev), wpisz URL, sprawdź wynik mobile + desktop, czytaj sekcję „Diagnostyka”
2. Search Console → „Core Web Vitals”, zobacz, ile URL-i jest oznaczonych jako „Poor”, „Needs improvement”, „Good”
3. WebPageTest.org, szczegółowe profilowanie z różnych lokalizacji
4. Chrome DevTools → Lighthouse (wbudowany audit Core Web Vitals)

Krok 2, diagnoza problemu

Jeśli LCP > 2,5s:

• Sprawdź rozmiar głównego obrazu/baneru (WebP zamiast JPEG, lazy loading wszystkich poniżej fold)
• Dodaj fetchpriority="high" na hero image
• Sprawdź TTFB, jeśli > 600ms, problem jest w hostingu
• Inline’uj critical CSS, defer reszty

Jeśli CLS > 0,1:

• Wszystkie obrazy MUSZĄ mieć width i height (lub aspect-ratio w CSS)
• Fonty z font-display: swap + preload
• Reklamy / popupy zarezerwuj miejsce z góry (CSS min-height)

Jeśli INP > 200ms:

• Audyt JavaScript, usuń niepotrzebne wtyczki (WordPress)
• Code splitting, ładuj JS tylko potrzebny dla danej strony
• Defer / async dla nieprorytetowych skryptów
• Web Workers dla ciężkich obliczeń

Krok 3, decyzja: optymalizować czy migrować

Sytuacja	Rekomendacja
WordPress, PageSpeed 60-80, < 5 wtyczek	Optymalizacja warta zachodu (1-2 dni, 500-1500 zł)
WordPress, PageSpeed < 50, 10+ wtyczek	Migracja na statyczną tańsza i lepsza długoterminowo
Stara strona własna w surowym HTML	Audit kodu, zwykle tania optymalizacja wystarczy
Strona zbudowana na React/Next bez SSR	Wymagana migracja na SSR/SSG, bez tego się nie da
Sklep Shopify / WooCommerce	Optymalizacja motywu + obrazów (Shopify ma natywnie OK PageSpeed)

Krok 4, wdrożenie i mierzenie

Po wdrożeniu zmian:

1. Powtórz pomiar PageSpeed Insights
2. Czekaj 28 dni. Search Console aktualizuje Core Web Vitals z rzeczywistych danych użytkowników
3. Sprawdzaj ranking dla swoich keywordów po 4-8 tygodniach
4. Mierz, ilu klientów się zgłasza (zapytania, telefony, rezerwacje), to ostateczny test

Najczęstsze mity o PageSpeed

„Najpierw treść, potem optymalizacja.” Nie. Wolna strona nie zostanie zindeksowana / dobrze rankowana niezależnie, jak dobry jest content. PageSpeed to fundament, nie cherry on top.

„90+ na desktopie wystarczy, mobile mniej ważne.” Odwrotnie. Większość ruchu lokalnego to mobile, Google indeksuje mobile-first, mobile PageSpeed jest ważniejszy.

„Hosting załatwi sprawę.” Hosting to 20% problemu. 80% to kod strony, obrazy, JavaScript. Najszybszy hosting nie naprawi wolnego WordPressa z 20 wtyczkami.

„Trzeba kupić premium hosting za 200 zł/mies.” Statyczne strony nie wymagają drogiego hostingu premium za 200 zł/mies. U mnie hosting statycznej strony to 100-250 zł rocznie, nie miesięcznie.

„WordPress można zoptymalizować do 99 PageSpeed.” Teoretycznie tak, w praktyce wymaga to: dedykowanego programisty, wycięcia 80% wtyczek, własnego motywu od zera, agresywnego cache. Koszt: 5-15 tys. zł i ryzyko, że kolejna aktualizacja WP coś popsuje. Migracja na statyczną od 1 499 zł i raz na zawsze.

Powiązane wpisy

• Core Web Vitals 2026, co nowego
• Dlaczego strona ładuje się wolno, 7 przyczyn
• WordPress vs strona statyczna 2026
• Mobile-first 2026 dla małej firmy
• Audyt SEO strony, checklist 2026
• 30-dniowy plan local SEO

Chcesz, żebym sprawdził Twoją stronę i powiedział, co jest wolne? Zostaw numer w formularzu, zrobię bezpłatny test PageSpeed + Core Web Vitals + dam konkretne rekomendacje. W 24h, bez zobowiązań.

Często zadawane pytania

Czy PageSpeed jest oficjalnym ranking factor?

Tak, od 2021 (Page Experience Update). W 2026 jeszcze bardziej liczą się Core Web Vitals: LCP, CLS i INP (które zastąpiło FID w 2024). Wolna strona z czerwonymi metrykami spada w wynikach.

Jaki PageSpeed wystarcza dla małej firmy?

Mobile: minimum 80, dobrze 90+. Desktop: minimum 90, dobrze 95+. Strony statyczne (HTML/CSS) bez WordPressa dają standardowo 99/100 mobile bez optymalizacji.

Co najmocniej spowalnia stronę WordPressową?

Wtyczki (każda dodaje JS i CSS), motywy ładujące tonami niepotrzebnego kodu, niezoptymalizowane obrazy, brak cache. Standardowy WordPress + motyw + 10 wtyczek to typowo 30-60 PageSpeed mobile.

Czy każda sekunda opóźnienia coś kosztuje?

Tak. Wg badania Google/SOASTA (2017) wzrost czasu ładowania z 1 do 3 sekund zwiększa prawdopodobieństwo porzucenia strony o 32%, a raport Google/Deloitte Milliseconds Make Millions (2020) pokazał, że poprawa szybkości mobile o 0,1 sekundy dała średnio +8,4% konwersji w retailu. Wolna strona kosztuje realne zapytania z ruchu, który już masz.

Czy mogę naprawić Core Web Vitals bez przerabiania całej strony?

Częściowo. Optymalizacja obrazów (WebP, lazy loading), instalacja cache, audyt wtyczek mogą podnieść PageSpeed o 20-30 punktów. Pełne 90+ wymaga zwykle zmiany motywu albo migracji na statyczny stack. Dla małej firmy migracja jest często tańsza i daje 99/100 natywnie.

Jak długo czeka się na efekt poprawy PageSpeed w Google?

Core Web Vitals są aktualizowane co 28 dni z danych rzeczywistych użytkowników (CrUX dataset). Po poprawie strony pełen efekt rankingowy jest widoczny w 28-56 dni. Dane PageSpeed Insights (lab data) zmieniają się natychmiast po każdej zmianie strony.