PageSpeed 100 na 100 w 2026: jak i po co

„Mamy 38 punktów na mobile" – najczęstsze zdanie, z jakim klienci przychodzą do mnie po audycie SEO. PageSpeed nie jest „modnym wskaźnikiem", lecz realnym czynnikiem rankingowym od 2021 roku. W tym artykule – czym są Core Web Vitals, realistyczny plan, jak rozpędzić stronę z 40 do 90+ w tydzień, i dlaczego dążenie do 100/100 nie jest konieczne.

Po co w ogóle przyspieszać stronę

Trzy pragmatyczne powody – bez ideologii „bo Google tak kazał".

• Czynnik SEO. Google uwzględnia Core Web Vitals jako czynnik rankingowy od 2021. Przy konkurencyjnych frazach szybka strona wyprzedza wolną, przy pozostałych równych warunkach.
• Konwersja. Każda +1 sekunda ładowania zmniejsza konwersję o 5-7%. W e-commerce więcej. Bezpośrednie straty pieniędzy.
• Koszt reklamy. Google Ads daje rabat na CPC dla szybkich landingów i odwrotnie karze wolne. Budżet – realnie wpływa.

Core Web Vitals: LCP, INP, CLS

To trzy metryki, które Google mierzy u rzeczywistych użytkowników poprzez Chrome (dane CrUX). Od 2021 są częścią algorytmu rankingowego.

LCP (Largest Contentful Paint)

Jak szybko pojawia się największy element na pierwszym ekranie – zwykle główny obraz lub duży nagłówek. Dobrze: < 2.5s. Źle: > 4s.

Główni winowajcy słabego LCP: ciężkie obrazki hero bez `fetchpriority="high"`, brak `preload`, wolny serwer (TTFB), blokujące skrypty w head.

INP (Interaction to Next Paint)

Zastąpił FID w 2024. Mierzy, jak szybko strona reaguje na kliknięcie/dotknięcie/naciśnięcie klawisza. Dobrze: < 200ms. Źle: > 500ms.

Główni winowajcy słabego INP: ciężki JS na main thread, synchroniczne event handlery, długie łańcuchy `setTimeout`. To „nowoczesny" ból głowy: nawet jeśli strona szybko się załadowała, może „przyklejać się" przy kliknięciu z powodu kiepskiego JS.

CLS (Cumulative Layout Shift)

Suma „skoków" układu podczas ładowania. Gdy baner u góry się doładował – i cały tekst przesunął się w dół = słaby CLS. Dobrze: < 0.1. Źle: > 0.25.

Główni winowajcy: obrazy bez podanej width/height, fonty zmieniające rozmiar przy doładowaniu, bloki reklamowe, dynamicznie wstawiane elementy.

7 głównych czynników prędkości

To podstawowa checklista. W 90% przypadków właśnie te punkty dają 70-90% przyrostu PageSpeed.

• Obrazki w WebP/AVIF + lazy load. 80% „ciężaru" stron to obrazy. Konwersja PNG/JPG do WebP daje -40-60% na rozmiarze. AVIF jest jeszcze lepszy, ale wsparcie jest nieco gorsze.
• Minifikacja i kompresja (Brotli). CSS/JS powinny być zminifikowane. Serwer powinien serwować z Brotli (lub przynajmniej gzip). Cloudflare robi to automatycznie.
• Usuń nieużywany CSS/JS. Każdy `bootstrap.css` lub `jquery.js`, jeśli używany jest w mniej niż 30% – usunąć. PurgeCSS + tree-shaking w bundlerze.
• Fonty z font-display: swap. Bez tego użytkownik widzi biały ekran, dopóki font ładuje się 1-2 sekundy. Ze swap – najpierw systemowy font, potem podmieniany.
• Preload głównego hero-image + preconnect do CDN. `` zmniejsza LCP o 0.5-1.5 sekundy.
• CDN (Cloudflare). Jeśli strona jest hostowana w Polsce, a klienci z USA – bez CDN strona ładuje się 3-5 sekund tylko ze względu na geografię. Cloudflare za darmo rozwiązuje ten problem.
• HTTP/2 lub HTTP/3. Nowoczesny protokół z multipleksowaniem. Włącza się jedną opcją w hostingu lub Cloudflare. Bez niego przeglądarka pobiera pliki sekwencyjnie zamiast równolegle.

Tygodniowy plan optymalizacji

Realistyczny harmonogram rozpędzenia strony z 40-50 punktów Mobile do 90+:

1. Audytdzień 1
2. Obrazkidzień 2-3
3. CSS/JSdzień 4
4. CDN/HTTPdzień 5
5. Finiszdzień 6-7

Dzień 1 – audyt. Przepuszczenie przez PageSpeed Insights + Lighthouse w DevTools. Zapisujesz aktualne LCP/INP/CLS, TBT, rozmiar strony. To punkt bazowy dla pomiarów. Równolegle – WebPageTest do analizy waterfall.

Dzień 2-3 – obrazki. Wszystkie JPG/PNG konwertujesz do WebP (masowo przez `cwebp` CLI lub Squoosh.app). Dodajesz atrybuty `width`/`height` do wszystkich `` (walka z CLS). Obrazek hero – z `fetchpriority="high"` i preload w ``. Pozostałe – `loading="lazy"`.

Dzień 4 – CSS/JS. Minifikacja (jeśli jeszcze nie zrobiona). Usunięcie nieużywanego CSS przez PurgeCSS. Skrypty, które nie są potrzebne na pierwszym ekranie – z `defer`. Analityka i liczniki – asynchronicznie lub po `DOMContentLoaded`.

Dzień 5 – CDN i HTTP/3. Podłączasz Cloudflare (jeśli jeszcze nie ma) – za darmo, 5 minut. Włączasz Brotli, HTTP/3, Auto Minify, Rocket Loader (ostrożnie – może łamać JS). Konfigurujesz cache rules dla statyki (1 rok dla assets z hashem w nazwie).

Dzień 6-7 – finisz. Ponowne przepuszczenie przez PageSpeed. Punktowe poprawki pozostałych problemów: third-party skrypty w iframe, fonty z font-display, usunięcie zbędnych preconnect. Końcowy pomiar. Jeśli 90+ Mobile – cel osiągnięty.

7 typowych błędów

Widziałem te grabie regularnie – u klientów po poprzednim wykonawcy lub po samodzielnych próbach.

1. Optymalizować Desktop, zapomnieć o Mobile. Mobile-first indexing od 2019. Google ranguje na podstawie wersji mobilnej. Desktop 95 + Mobile 45 = jest rankowany jak 45.
2. Testować tylko w Lighthouse, nie patrzeć na field-data. Lighthouse to dane laboratoryjne. Search Console pokazuje realne CWV u rzeczywistych użytkowników. Mogą się różnić.
3. „Pomaga plugin WP-Optimize, instalujemy". Wtyczki optymalizujące często konfliktują, robią rzeczy nieprzewidywalne. Lepiej jedna porządnie skonfigurowana niż trzy „pomagające" sobie nawzajem.
4. Lazy load obrazka hero. Największy błąd. Lazy load dla obrazka powyżej fold = zwiększenie LCP. Lazy load – tylko dla obrazków poniżej pierwszego ekranu.
5. Ciężkie fonty bez preload i font-display. Font 800 z obsługą 5 języków = 200KB. Bez font-display: swap – biały ekran 1-2 sekundy. Z preload – LCP się skraca.
6. Third-party skrypty w head. Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... w head synchronicznie – TBT (Total Blocking Time) jedzie do czerwonej strefy. Przenieś do footera lub asynchronicznie.
7. Ignorować Server-Side performance. TTFB (Time to First Byte) – często problem po stronie serwera: wolny PHP, niezoptymalizowane zapytania SQL, brak cache na serwerze. Optymalizacja samego klienta nie pomoże, jeśli serwer sam odpowiada przez 2 sekundy.

Częste pytania