Szybkość strony — czas odpowiedzi serwera, kompresja, rozmiar HTML i Core Web Vitals

Aktualizacja: 18.10.2026

Szybkość strony to dwie sprawy: jak szybko serwer w ogóle zaczyna odpowiadać i jak szybko przeglądarka potrafi z tej odpowiedzi zbudować użyteczną stronę. Wolna strona traci klientów, zanim się załaduje, a Google bierze doświadczenia użytkowników pod uwagę w rankingu — choć to jeden z wielu sygnałów, a nie przełącznik, który sam wypchnie stronę w górę lub w dół.

Co dokładnie wykrył audyt

Czas odpowiedzi serwera (TTFB) — informacja, bez oceny. Mierzymy czas do pierwszego bajtu odpowiedzi: od połączenia z serwerem (w tym DNS i szyfrowanie HTTPS) do chwili, gdy serwer zacznie wysyłać stronę. Pomiar robi nasz serwer w Polsce, kilka razy pod rząd, a pokazujemy medianę. Poniżej 0,8 s piszemy „szybko”, do 1,8 s „umiarkowanie”, powyżej „wolno” — to progi, które Google podaje dla TTFB. Traktuj to jako orientację: jeśli Twój serwer stoi np. w USA albo strona ma klientów głównie za granicą, wynik z Polski będzie inny niż u nich. Wiarygodniejszy obraz daje sekcja Google PageSpeed niżej w raporcie.
Kompresja Gzip/Brotli (do poprawy). Pytamy serwer o stronę, deklarując, że przyjmiemy wersję skompresowaną. Jeśli odpowiedź przychodzi bez kompresji, serwer przesyła kilka razy więcej danych, niż musi. Sprawdzamy sam dokument HTML — kompresji plików CSS i JS nie oceniamy, więc zielony wynik ich nie obejmuje. Gdy serwer przy tym drugim zapytaniu nie zwróci strony (np. ograniczy liczbę zapytań), nie oceniamy kompresji wcale.
Rozmiar kodu HTML (kosmetyka). Ostrzegamy, gdy sam dokument HTML (bez obrazków, CSS i skryptów ładowanych osobno) ma 400 KB lub więcej. To nie blokuje Google, ale wydłuża ładowanie, szczególnie na telefonie.
Przestarzały kod HTML (kosmetyka). Na stronie są znaczniki wycofane ze standardu HTML: <font>, <center>, <marquee>, <blink>, <big> lub <strike>. Przeglądarki zwykle nadal je wyświetlają, a Google nie karze za nie stron. To sygnał, że część szablonu albo treści pochodzi sprzed lat i warto ją uporządkować.

Core Web Vitals, czyli to, co naprawdę liczy Google

Google ocenia doświadczenie użytkownika trzema wskaźnikami Core Web Vitals:

LCP (Largest Contentful Paint) — kiedy pojawia się największy element w widoku, zwykle zdjęcie główne lub nagłówek. Dobrze: do 2,5 s.
INP (Interaction to Next Paint) — jak szybko strona reaguje na kliknięcie czy dotknięcie. Dobrze: do 200 ms.
CLS (Cumulative Layout Shift) — jak bardzo układ „skacze” w trakcie ładowania. Dobrze: do 0,1.

Google patrzy na 75. percentyl wizyt, osobno dla telefonów i komputerów. Najważniejsze rozróżnienie:

Dane z prawdziwych użytkowników — zbierane z przeglądarek Chrome (Chrome User Experience Report, CrUX) z ostatnich 28 dni. To one trafiają do raportu Core Web Vitals w Google Search Console i do sekcji „dane rzeczywistych użytkowników” w PageSpeed Insights. Mała strona może ich nie mieć wcale — wtedy PageSpeed pokazuje dane dla całej domeny albo nic.
Pomiar laboratoryjny — wynik 0–100 w PageSpeed Insights to jedno symulowane wczytanie strony na wolnym telefonie. Przydaje się do szukania przyczyn, ale skacze między pomiarami (sieć, reklamy, testy A/B po stronie serwisu). Wynik 62, a minutę później 71, to normalne. Nie oceniaj zmian po jednym teście — zrób kilka i patrz na tendencję.

Jak to wpływa na pozycje? Google pisze wprost, że Core Web Vitals są używane przez systemy rankingowe, ale zawsze stara się pokazać najtrafniejszą treść, nawet jeśli doświadczenie strony jest słabsze. Szybkość pomaga przede wszystkim wtedy, gdy kilka stron ma podobnie dobrą treść. Przyspieszenie strony nie gwarantuje wzrostu pozycji — za to niemal zawsze poprawia konwersję.

Jak sprawdzić samemu

PageSpeed Insights (pagespeed.web.dev) — wpisz adres, sprawdź najpierw kartę „Komórka”. Na górze są dane prawdziwych użytkowników (jeśli Google je ma), niżej wynik laboratoryjny i lista konkretnych zaleceń.
Google Search Console → raport Core Web Vitals — pokazuje grupy adresów z problemem (np. „LCP: dłuższe niż 2,5 s”) dla całej witryny, nie tylko dla jednej strony.
Kompresja i TTFB w przeglądarce — naciśnij F12, zakładka Network (Sieć), odśwież stronę i kliknij pierwszą pozycję (sam adres strony). W Response Headers szukaj content-encoding: gzip, br lub zstd. W zakładce Timing pozycja „Waiting for server response” to w przybliżeniu czas odpowiedzi serwera.
Rozmiar HTML — w tej samej zakładce Network kolumna Size przy pierwszym wierszu. Druga wartość (po najechaniu lub w szczegółach) to rozmiar po rozpakowaniu.
Przestarzałe znaczniki — Ctrl+U (Mac: Cmd+Option+U), potem Ctrl+F i szukaj <font, <center, <marquee.

Co najczęściej spowalnia stronę

Brak cache stron — WordPress czy PrestaShop składają każdą stronę od nowa z bazy danych przy każdej wizycie. To główna przyczyna wysokiego TTFB.
Słaby lub przeładowany hosting i stara wersja PHP.
Ciężkie obrazy — zdjęcia 4000 px wyświetlane w okienku 600 px, brak formatu WebP/AVIF.
Za dużo wtyczek, aplikacji i skryptów zewnętrznych — czaty, piksele reklamowe, widżety opinii, mapy. To zwykle one psują INP.
Ciężki HTML — buildery stron (Elementor, Divi, WPBakery) generują wiele zagnieżdżonych bloków; ikony wklejane jako kod SVG w każdym miejscu; duże bloki JSON w kodzie (np. całe dane produktów i wariantów wstawiane przez motyw sklepu); długie menu „mega menu” powtórzone w wersji mobilnej i desktopowej.

Jak naprawić

Kompresja na serwerze

Na większości hostingów kompresja jest włączona domyślnie — jeśli audyt jej nie widzi, zapytaj najpierw hostingodawcę. Ręcznie:

Apache (moduł mod_deflate), w pliku .htaccess:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/javascript application/json application/xml image/svg+xml
</IfModule>

nginx, w konfiguracji serwera:

gzip on;
gzip_types text/css text/plain text/xml application/javascript application/json application/xml image/svg+xml;

HTML (text/html) nginx kompresuje zawsze, gdy gzip on. Brotli na nginx wymaga dodatkowego modułu — to zadanie dla administratora serwera.

Cloudflare kompresuje odpowiedzi automatycznie (Gzip, Brotli lub Zstandard), jeśli ruch idzie przez jego proxy (pomarańczowa chmurka przy rekordzie DNS).

WordPress i WooCommerce

Cache stron. Jeśli hosting działa na LiteSpeed lub OpenLiteSpeed, zainstaluj LiteSpeed Cache — jego cache stron działa tylko na takim serwerze (albo przez CDN QUIC.cloud), za to jest darmowy. Na innych serwerach sprawdzi się WP Rocket (płatny); na Apache dopisuje on też reguły kompresji do .htaccess. Nie instaluj dwóch wtyczek cache naraz.
Wersja PHP. Sprawdź w Narzędzia → Zdrowie witryny → Informacje → Serwer. Jeśli to wersja starsza niż zalecana przez WordPress, podnieś ją w panelu hostingu (po kopii zapasowej i na wersji testowej, jeśli ją masz).
Obrazy. WordPress przyjmuje WebP, a od wersji 6.5 także AVIF. Wtyczki optymalizujące (np. funkcja optymalizacji obrazów w LiteSpeed Cache) przerabiają bibliotekę mediów automatycznie. Leniwe ładowanie (lazy-load) WordPress dodaje sam — ale zdjęcie na samej górze strony nie powinno być ładowane leniwie, bo to pogarsza LCP.
Wtyczki i skrypty. Wyłącz po kolei wtyczki, których nie potrzebujesz, i sprawdź w PageSpeed, które skrypty zewnętrzne ważą najwięcej. W WooCommerce typowo ciąży koszyk odświeżany na każdej stronie, filtry produktów i widżety opinii.
Ciężki HTML z buildera. W Elementorze włącz funkcje wydajności w Elementor → Ustawienia → Funkcje (zoptymalizowany DOM, ładowanie zasobów na żądanie) i uprość najcięższe sekcje. Ikony wklejane jako SVG zamień na plik obrazka albo jeden zestaw ikon.
Przestarzałe znaczniki zwykle siedzą w starych wpisach (wklejonych z Worda lub starego edytora) albo w widżetach tekstowych. Zamień <font> i <center> na zwykły tekst sformatowany w edytorze bloków; jeśli są w szablonie — to praca dla programisty.

Shopify

Shopify sam dba o serwer, kompresję i CDN — na TTFB i kompresję masz mały wpływ. Twoja część to motyw i aplikacje:

Podsumowanie Core Web Vitals z prawdziwych wizyt widzisz w Sklep online → Motywy, pełne raporty w Analityka → Raporty (wyszukaj raporty wydajności).
Aplikacje — usuń te, które nie zarabiają. Uwaga: odinstalowanie aplikacji nie zawsze usuwa jej kod z motywu; poproś twórcę aplikacji o instrukcję pełnego usunięcia.
Motyw — motywy Online Store 2.0 i Horizon od Shopify są zoptymalizowane. Ogranicz liczbę sekcji na stronie, animacje i karuzele.
Obrazy — wgrywaj w rozmiarze zbliżonym do wyświetlanego. CDN Shopify sam dobiera format (często WebP) i zmniejsza zdjęcia.
Duży HTML w Shopify to często dane wszystkich wariantów produktu wstawiane przez motyw albo aplikacje — przy setkach wariantów warto o tym porozmawiać z twórcą motywu.

PrestaShop

W Zaawansowane → Wydajność (Advanced Parameters → Performance): w sekcji Smarty ustaw Nigdy nie kompiluj plików szablonów i włącz Cache (na sklepie produkcyjnym); w sekcji CCC (Combine, Compress, Cache) włącz inteligentny cache dla CSS i JavaScript oraz optymalizację Apache (dopisuje reguły kompresji do .htaccess).
Po każdej zmianie kliknij Wyczyść pamięć podręczną i sprawdź sklep — CCC potrafi zepsuć układ przy źle napisanych modułach. Wtedy wyłącz go i szukaj winnego modułu.
Wyłącz nieużywane moduły; dużo pomaga też moduł cache stron (pełnej strony) i nowsza wersja PHP na hostingu.

Shoper

Shoper to sklep w abonamencie: serwer, cache i kompresja są po stronie dostawcy, a kodu HTML nie zmienisz dowolnie. Realny wpływ masz na:

Obrazy — w szablonie Storefront zdjęcia produktów są zamieniane na WebP automatycznie. W starszym szablonie włącz to w Wygląd i treści → Wygląd sklepu → Edycja szablonu graficznego → Galeria produktu, zmieniając format zdjęć produktów na WebP. Banery na stronie głównej przygotuj w rozmiarze, w jakim się wyświetlają.
Aplikacje i skrypty — każda doinstalowana aplikacja i każdy wklejony kod śledzący (piksele, czaty) dokłada pracy przeglądarce. Usuń zbędne.
Treść — opisy produktów wklejone z Worda bywają źródłem przestarzałych znaczników i zbędnego kodu. Wklejaj jako czysty tekst.

Jeśli TTFB jest stale wysoki, zgłoś to do pomocy technicznej Shopera.

Hosting i CDN

Gdy TTFB jest wysoki mimo cache, problemem jest zwykle serwer: przeładowany hosting współdzielony albo serwer daleko od klientów. CDN (np. Cloudflare) skraca drogę do plików statycznych, a z cache całych stron — także do HTML. Zmiana hostingu to często najskuteczniejszy pojedynczy krok przy stronach na tanim pakiecie.

Jak sprawdzić, że naprawione

Kompresja i TTFB — od razu: nagłówek content-encoding w F12 i ponowny audyt. Pamiętaj, żeby wyczyścić cache (wtyczki, serwera, Cloudflare).
Wynik laboratoryjny PageSpeed — od razu, ale zrób kilka pomiarów i porównuj tendencję, nie pojedynczą liczbę.
Dane prawdziwych użytkowników — powoli. CrUX liczy ostatnie 28 dni, więc poprawa w PageSpeed i w GSC wychodzi stopniowo w ciągu około miesiąca. W raporcie Core Web Vitals w GSC kliknij Rozpocznij śledzenie przy naprawionym problemie — Google obserwuje adresy przez 28 dni. To nie przyspiesza indeksowania ani nie zmienia pozycji od ręki.

Czy i kiedy zmieni się widoczność w Google — tego nikt uczciwie nie obieca. Szybkość jest jednym z sygnałów; treść i trafność odpowiedzi na zapytanie ważą więcej.

Kiedy warto poprosić o pomoc

Gdy cache, obrazy i porządek we wtyczkach nie wystarczają, a słabe LCP lub INP wynika z motywu, buildera czy skryptów, których nie da się po prostu wyłączyć, potrzebna jest praca w kodzie szablonu albo zmiana hostingu. IF.PL zajmuje się SEO i budową stron WWW — możemy przejrzeć wyniki PageSpeed i wskazać, co da największą poprawę przy rozsądnym nakładzie. Warto też zajrzeć do artykułu o podstawach technicznych i aktualizacji WordPressa.