PageSpeed jako ranking factor 2026, ile naprawdę wpływa na pozycję w 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 (waga ~10 % w lokalnym SEO), 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, bounce rate idzie w górę, 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

Dane Google z 2024:

• 1 sekunda opóźnienia → -20% konwersji mobile
• 3 sekundy vs 1 sekunda ładowania → +32% wyższa rezygnacja (bounce rate)
• Strony z PageSpeed 90+ mobile mają średnio 30% wyższe pozycje rankingowe niż strony 50-70 punktów
• 5 sekund vs 1 sekunda ładowania → 4× mniej zapytań kontaktowych

Konkret: jeśli generujesz 100 zapytań / miesiąc ze strony, a strona ładuje się 4 sekundy zamiast 1 sekundy, tracisz 60 zapytań co miesiąc. Co rocznie. Permanentnie.

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 konwersję (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. 70% 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 hostowane na Cloudflare Pages / Vercel / Netlify są darmowe i szybsze niż większość premium hostingów.

„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 2 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
• SEO lokalne 2026, kompletny przewodnik

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ń.