Page Speed – czym jest, dlaczego Google go mierzy i jak go poprawić

Każdy z nas pamięta moment, gdy strona ładowała się zbyt długo i po prostu ją zamknął. Nie czekał. Nie sprawdzał, czy może za sekundę będzie lepiej. Po prostu odszedł. To dokładnie ten moment, który Google stara się przewidzieć i wyeliminować — bo wie, że wolna strona to zły użytkownik, a zły użytkownik to sygnał, że strona nie zasługuje na wysoką pozycję.

Page speed — szybkość ładowania strony — przestało być kwestią techniczną dla developerów. W 2026 roku to jeden z mierzalnych czynników rankingowych, wskaźnik jakości UX i — co coraz ważniejsze — warunek cytowania przez modele AI. Sklep, który ładuje się cztery sekundy, traci nie tylko pozycje w Google. Traci klientów, konwersje i zaufanie — zanim cokolwiek zdążą przeczytać.

Dlaczego szybkość strony wpływa na pozycje w Google

Google oficjalnie potwierdziło page speed jako czynnik rankingowy w 2010 roku dla desktopa i w 2018 roku dla mobile — w ramach aktualizacji “Speed Update”. Ale mechanizm jest głębszy niż prosty sygnał techniczny.

Google zbiera dane o zachowaniu użytkowników na stronach przez Chrome — największą przeglądarkę na świecie. Wie więc, jak szybko strona ładuje się dla realnych użytkowników, jak długo zostają, jak często wychodzą od razu po wejściu. Wolna strona generuje wysoki bounce rate i krótkie sesje — a to sygnał, że użytkownik nie znalazł tego, czego szukał, albo nie miał cierpliwości, żeby poczekać. Oba warianty są złe w oczach algorytmu.

W 2026 roku page speed ma jeszcze jeden wymiar: szybkie, stabilne i responsywne strony są częściej uwzględniane jako źródła przez modele AI — ChatGPT, Perplexity, Google Gemini. Strony wolne, niestabilne lub generujące błędy mogą być pomijane w odpowiedziach generatywnych, nawet jeśli ich treść jest merytorycznie doskonała.

Core Web Vitals — jak Google mierzy szybkość

Google nie mierzy page speed jako jednej liczby. Mierzy go przez pryzmat Core Web Vitals — trzech wskaźników, które opisują, jak strona czuje się w użyciu, nie tylko jak szybko technicznie się ładuje.

LCP — Largest Contentful Paint

LCP mierzy, jak szybko na ekranie pojawia się największy element widoczny bez scrollowania — najczęściej główne zdjęcie, nagłówek hero lub baner. To moment, w którym użytkownik widzi, że strona w ogóle istnieje i coś mu pokazuje.

Dobry wynik LCP: poniżej 2,5 sekundy. Wynik między 2,5 a 4 sekundy wymaga poprawy. Powyżej 4 sekund — strona jest oceniana jako słaba.

Najczęstsze przyczyny złego LCP: nieskompresowane obrazki w hero sekcji, wolny serwer (wysoki TTFB), renderujące się blokująco skrypty JavaScript i CSS, ładowanie dużych filmów w tle nad zawartością strony.

INP — Interaction to Next Paint

INP zastąpił w 2024 roku wskaźnik FID i mierzy coś innego niż ładowanie — mierzy jak szybko strona reaguje na działanie użytkownika: kliknięcie, dotknięcie, wpisanie tekstu. To responsywność, nie prędkość ładowania.

Dobry wynik INP: poniżej 200 ms. 200–500 ms wymaga poprawy. Powyżej 500 ms to słaby wynik.

Wysoki INP to często efekt zbyt dużej ilości JavaScript wykonującego się na stronie — pluginy, śledzenie, czaty, widgety. Każdy dodatkowy skrypt, który musi się wykonać, zanim strona odpowie na kliknięcie, podnosi INP.

CLS — Cumulative Layout Shift

CLS mierzy niestabilność wizualną strony podczas ładowania — czyli jak bardzo elementy strony przeskakują, przemieszczają się i reorganizują, zanim strona się w pełni załaduje. Każdy, kto próbował kliknąć przycisk i nagle kliknął reklamę, bo ta pojawiła się ułamek sekundy wcześniej, doświadczył wysokiego CLS.

Dobry wynik CLS: poniżej 0,1. 0,1–0,25 wymaga poprawy. Powyżej 0,25 to słaby wynik.

Najczęstsze przyczyny: obrazki bez zdefiniowanych wymiarów (przeglądarka nie wie, ile miejsca zarezerwować), reklamy wstrzykiwane dynamicznie, fonty zamieniane podczas ładowania, elementy dodawane do strony po załadowaniu głównej treści.

TTFB — wskaźnik, o którym często się zapomina

Przed Core Web Vitals istnieje jeszcze jeden wskaźnik, który Google mierzy i ocenia: TTFB — Time to First Byte. To czas między wysłaniem przez przeglądarkę zapytania do serwera a otrzymaniem pierwszego bajtu odpowiedzi. W uproszczeniu: jak szybko serwer reaguje.

Dobry TTFB: poniżej 500 ms. 500–1800 ms wymaga poprawy. Powyżej 1800 ms to zły wynik.

Wysoki TTFB to często problem z hostingiem — zbyt wolny serwer, brak cache’owania na poziomie serwera, przepełniona baza danych lub zła konfiguracja PHP. Jest to punkt, od którego każda optymalizacja page speed powinna się zaczynać — bo jeśli serwer odpowiada wolno, żadna optymalizacja frontendu nie nadrobi tego opóźnienia.

Narzędzia do mierzenia page speed

Zanim zaczniesz cokolwiek optymalizować, musisz wiedzieć, co konkretnie jest problemem. Kilka narzędzi, które w połączeniu dają pełny obraz:

• Google PageSpeed Insights — podstawowe narzędzie, dostępne bezpłatnie pod adresem pagespeed.web.dev. Pokazuje Core Web Vitals bazując na realnych danych z Chrome (tzw. field data) oraz wynik laboratoryjny. Kluczowe: patrz najpierw na field data, nie na score. Score to liczba syntetyczna — field data to rzeczywiste doświadczenie użytkowników.
• Google Search Console — raport Core Web Vitals — pokazuje dane dla wszystkich podstron serwisu na podstawie realnego ruchu. Nie musisz testować każdej strony osobno — GSC wskaże, które URL-e mają problemy z LCP, CLS lub INP grupowo.
• GTmetrix — narzędzie, które pokazuje kaskadę ładowania strony (waterfall chart). Widzisz kolejno każdy element pobierany przez przeglądarkę i wiesz, który konkretnie plik lub skrypt spowalnia ładowanie.
• WebPageTest — zaawansowane narzędzie do testowania strony z różnych lokalizacji geograficznych i różnych typów połączeń. Szczególnie przydatne, gdy chcesz sprawdzić, jak strona działa dla użytkowników w innym kraju.
• Chrome DevTools — panel w przeglądarce dostępny pod F12, zakładka Performance. Dla developerów najbardziej szczegółowe źródło informacji o tym, co dzieje się podczas ładowania strony.
  

  Jak poprawić page speed — od największego do najmniejszego wpływu

Nie wszystkie optymalizacje są równe. Poniżej działania uszeregowane według realnego wpływu na szybkość — od tych, które robią największą różnicę, do tych, które są ważne, ale dodatkowe.

Hosting i infrastruktura serwera

To jest fundament, od którego zależy wszystko inne. Wolny serwer to problem, którego nie naprawisz żadną optymalizacją frontendu. Dobry hosting dla sklepu e-commerce w 2026 roku to: VPS lub dedykowany serwer (hosting współdzielony to za mało dla sklepów z ruchem), PHP 8.x, serwer baz danych MySQL z optymalizacją zapytań, serwer-side caching (Redis lub Memcached) i GZIP lub Brotli compression aktywne domyślnie.

Zmiana hostingu z taniego na szybki może przynieść redukcję TTFB o 50–70% bez żadnej innej zmiany na stronie.

CDN — Content Delivery Network

CDN to sieć serwerów rozlokowanych na całym świecie, które przechowują statyczne zasoby Twojej strony (obrazki, CSS, JavaScript) i serwują je użytkownikowi z serwera geograficznie najbliższego. Użytkownik w Gdańsku dostaje pliki z serwera w Warszawie, nie z serwera w USA, na którym stoi Twój hosting.

Dla sklepów działających na rynku polskim lub europejskim CDN redukuje czas ładowania statycznych zasobów o 30–60%. Popularne CDN to Cloudflare (ma bezpłatny plan), BunnyCDN, Fastly.

Optymalizacja obrazków

To najczęstszy i najłatwiejszy do naprawienia problem w sklepach e-commerce. Nieoptymalne obrazki potrafią odpowiadać za 60–80% rozmiaru strony.

Konkretne działania: konwersja obrazków do formatu WebP lub AVIF (przy tej samej jakości wizualnej plik jest o 30–50% mniejszy niż JPG), kompresja stratna dla zdjęć produktowych (jakość 75–85% jest nieodróżnialna dla oka, ale plik jest wielokrotnie mniejszy), definicja wymiarów width i height dla każdego obrazka (eliminuje CLS), lazy loading dla obrazków poniżej linii fold (przeglądarka ładuje je dopiero gdy użytkownik scrolluje w ich kierunku), responsywne obrazki z atrybutem srcset (serwujesz mniejszy plik na mobile, większy na desktop).

JavaScript — mniej znaczy szybciej

JavaScript to główna przyczyna wysokiego INP i długiego Total Blocking Time. Każdy skrypt musi być pobrany, sparsowany i wykonany przez przeglądarkę — a w tym czasie strona nie reaguje na interakcje użytkownika.

Praktyczne działania: audyt pluginów i usuwanie nieużywanych (szczególnie w WordPressie i WooCommerce), odkładanie nieistotnych skryptów na po załadowaniu strony (defer i async), ograniczenie skryptów śledzenia do niezbędnego minimum, lazy loading dla widget czatu, map i innych zewnętrznych elementów.

W PrestaShop i WooCommerce szczególnie uważaj na: pluginy do sliderów, które ładują duże biblioteki JS nawet na stronach, gdzie slidera nie ma, pluginy do popupów, wtyczki A/B testów, i nakładające się pluginy do cache’owania, które wchodzą sobie w drogę.

Cache — nie generuj strony od zera przy każdym wejściu

Cache to mechanizm przechowywania gotowej wersji strony, żeby serwer nie musiał generować jej od zera przy każdym zapytaniu. Dla sklepów e-commerce konfiguracja cache jest subtelniejsza niż dla blogów — strony z cenami, dostępnością produktów i koszykiem nie mogą być cache’owane globalnie. Ale strony kategorii, artykuły blogowe i strony statyczne — owszem.

Cache po stronie serwera (Redis, Varnish) jest znacznie efektywniejszy niż cache po stronie pluginu. Dla WordPressa popularne rozwiązania to WP Rocket, W3 Total Cache. Dla PrestaShop — wbudowany cache Smarty z konfiguracją Redis lub Memcached.

Czcionki — mały detal, duży wpływ na CLS

Google Fonts ładowane z zewnętrznego serwera to klasyczna przyczyna dwóch problemów: dodatkowego zapytania DNS (spowalnia ładowanie) i skoku layoutu podczas zamiany fontu systemowego na załadowany (podnosi CLS).

Rozwiązanie: hostuj czcionki lokalnie na własnym serwerze zamiast ładować je z Google Fonts. Użyj font-display: optional lub font-display: swap z preloadem, żeby przeglądarka wiedziała, jak obsłużyć moment zanim font się załaduje. Ogranicz liczbę wariantów fontów do tych rzeczywiście używanych — każdy dodatkowy plik czcionki to kolejne zapytanie.

Page speed na mobile — dlaczego jest ważniejszy niż desktop

Google indeksuje strony w trybie Mobile First — co oznacza, że wersja mobilna Twojej strony jest traktowana jako podstawowa, a desktop jako wtórna. Core Web Vitals są mierzone przede wszystkim na mobile. Ranking jest ustalany na podstawie mobile.

Tymczasem większość testów, które właściciele sklepów robią, dotyczy desktopa. Wchodzą na PageSpeed Insights, widzą wynik 85 dla desktop i są zadowoleni. Wynik dla mobile: 42. To jest częsty, kosztowny błąd. Zawsze testuj mobile jako priorytet, nie jako informację dodatkową.

Dobry wynik PageSpeed dla mobile to 90+. Wynik 50–89 wymaga poprawy. Poniżej 50 to słaby wynik, który Google bezpośrednio przekłada na gorsze pozycje.

Page speed a konwersja — liczby, które przekonują

SEO to jeden powód do dbania o szybkość strony. Konwersja to drugi — i w wielu przypadkach ważniejszy z perspektywy przychodów.

Badania Google i Deloitte pokazują, że 0,1 sekundy poprawy czasu ładowania zwiększa konwersję o 8% w handlu detalicznym. Amazon szacował, że każde 100 ms opóźnienia kosztuje ich 1% sprzedaży. Walmart zanotował wzrost konwersji o 2% dla każdej sekundy skróconej.

Dla sklepu e-commerce z miesięczną sprzedażą 100 000 zł — nawet 1–2% wzrost konwersji po optymalizacji speed to 1 000–2 000 zł miesięcznie z tej samej liczby wejść. Inwestycja w page speed zwraca się z obu stron: lepsza pozycja w Google przynosi więcej ruchu, lepsza konwersja zamienia więcej tego ruchu w sprzedaż.

Jak wygląda dobry wynik w 2026 roku

Orientacyjne benchmarki, do których warto dążyć:

LCP poniżej 2,5 sekundy to “dobry” wynik. INP poniżej 200 ms to “dobry” wynik. CLS poniżej 0,1 to “dobry” wynik. TTFB poniżej 500 ms. PageSpeed Score 90+ dla mobile i desktop. Czas do pełnego załadowania strony poniżej 2 sekund.

Ważna uwaga: nie warto gonić za idealnym wynikiem 100, kosztem funkcjonalności sklepu. Sklep, który osiąga 95 punktów, ale usuwa kluczowe skrypty śledzące i traci dane analityczne — robi złą wymianę. Cel to “dobry” we wszystkich Core Web Vitals i score powyżej 90 — nie perfekcja za wszelką cenę.

Page speed to nie projekt, to proces

Ostatnia rzecz, którą warto zapamiętać: optymalizacja szybkości strony to nie jednorazowa akcja. Każda aktualizacja sklepu, nowy plugin, nowe zdjęcia, nowy element na stronie głównej — to potencjalne pogorszenie wyników.

Warto wbudować monitoring page speed w regularne procesy: sprawdzanie Core Web Vitals w GSC raz w miesiącu, test PageSpeed Insights po każdym większym wdrożeniu, alerty w Google Search Console, gdy wyniki się pogarszają. Sklep, który mierzył speed rok temu i więcej nie sprawdzał, nie wie, w jakim stanie jest dziś. A rynek i algorytm nie czekają.