Wróć na blog
wydajność core web vitals seo optymalizacja

Dlaczego Twoja strona ładuje się 8 sekund (i ile Cię to kosztuje)

Wolna strona to realne straty: więcej odrzuceń, mniej konwersji i gorsze SEO. Wyjaśniam przyczyny, Core Web Vitals po ludzku i szybkie wygrane.

Franciszek Sikora

Wchodzisz na własną stronę z telefonu, w 4G, poza biurem. Klikasz i… czekasz. Raz, dwa, trzy sekundy. Pasek ciągle się kręci. Jeśli to nie Twoja strona, dawno byś już wyszedł — i dokładnie to robią Twoi potencjalni klienci. W tym wpisie pokazuję, ile naprawdę kosztuje Cię wolna strona, skąd się bierze te magiczne „8 sekund” i co możesz z tym zrobić, nawet jeśli nie jesteś programistą.

Najpierw twarde liczby — ile kosztuje czekanie

Szybkość strony to nie jest „miły dodatek”. To pieniądze. Im dłużej trwa ładowanie, tym więcej osób porzuca stronę, zanim cokolwiek zobaczy.

Czas ładowania a odsetek użytkowników, którzy porzucają stronę

Wniosek jest brutalnie prosty: każda dodatkowa sekunda to wymierny ubytek odwiedzających. Przy ładowaniu na poziomie 3 sekund tracisz mniej więcej co trzeciego użytkownika. Przy 5 sekundach — niemal połowę. Przy 8 sekundach rozmawiamy już o stronie, która głównie odbija ludzi.

To przekłada się na trzy konkretne obszary:

ObszarCo się dzieje, gdy strona jest wolna
Współczynnik odrzuceńLudzie wychodzą przed pierwszą interakcją. Im wolniej, tym wyższy bounce.
KonwersjaMniej zapytań, mniej zakupów, mniej wypełnionych formularzy. Wolna strona = mniejszy utarg.
SEOGoogle używa szybkości jako sygnału rankingowego. Wolniej = niżej w wynikach = mniej ruchu.

Innymi słowy: wolna strona kosztuje Cię dwa razy. Raz, bo część ludzi w ogóle do niej nie dotrze (gorszy ranking). Drugi raz, bo ci, którzy dotrą, uciekną przed konwersją.

Core Web Vitals po ludzku

Google nie ocenia szybkości „na oko”. Ma trzy konkretne metryki — Core Web Vitals — i to one decydują o tym, czy Twoja strona jest „wystarczająco szybka”. Brzmią groźnie, ale po ludzku znaczą rzeczy bardzo intuicyjne.

LCP — Largest Contentful Paint

„Kiedy pojawia się najważniejsza rzecz na ekranie?” Zwykle to duże zdjęcie w nagłówku albo główny tytuł. LCP mierzy, ile czasu mija, zanim użytkownik zobaczy ten największy element.

  • Dobrze: poniżej 2,5 sekundy
  • Do poprawy: 2,5–4 sekundy
  • Źle: powyżej 4 sekund

INP — Interaction to Next Paint

„Jak szybko strona reaguje, gdy w nią kliknę?” Klikasz przycisk, rozwijasz menu — i czekasz, aż coś się stanie. INP mierzy to opóźnienie. Wysoki INP to ta irytująca strona, która „myśli”, zanim zareaguje.

  • Dobrze: poniżej 200 ms
  • Do poprawy: 200–500 ms
  • Źle: powyżej 500 ms

CLS — Cumulative Layout Shift

„Czy treść skacze mi pod palcami?” Zaczynasz czytać, a tu nagle doładowała się reklama albo obrazek i cały tekst przeskoczył w dół. Klikasz nie tam, gdzie chciałeś. CLS mierzy tę „skoczność” układu.

  • Dobrze: poniżej 0,1
  • Do poprawy: 0,1–0,25
  • Źle: powyżej 0,25

Jak to zapamiętać

LCP = jak szybko widać. INP = jak szybko reaguje. CLS = jak bardzo skacze. Trzy proste pytania, na które dobra strona odpowiada: szybko, szybko i wcale.

Skąd się bierze te 8 sekund — typowe przyczyny

Wolna strona to prawie nigdy jeden wielki problem. To zwykle kilka małych grzechów, które się sumują. Oto najczęstsi winowajcy, w kolejności od najgroźniejszych.

1. Ciężkie obrazy

To zdecydowanie numer jeden. Zdjęcie 4000 px szerokości wrzucone prosto z aparatu do kontenera, który ma 600 px, potrafi ważyć 5 MB zamiast 80 KB. Przeglądarka i tak musi pobrać cały plik. To temat na osobny wpis — i taki mam: obrazki, które zabijają stronę.

2. Za dużo wtyczek i skryptów

Każda wtyczka, każdy widget czatu, każdy piksel śledzący to dodatkowy kod do pobrania i wykonania. Pięć narzędzi analitycznych, trzy wtyczki do „szybkości” i slider z animacjami potrafią obciążyć stronę bardziej niż cała jej treść.

3. Render-blocking CSS i JS

Niektóre pliki CSS i JavaScript blokują rysowanie strony, dopóki się nie wczytają. Przeglądarka stoi i czeka z pustym ekranem, zamiast pokazać choć tekst. To częsta przyczyna wysokiego LCP.

4. Brak cache

Bez cache serwer buduje całą stronę od zera przy każdym wejściu — odpytuje bazę, składa HTML, renderuje. Z cache gotowa strona leży przygotowana i serwuje się błyskawicznie. Różnica bywa kilkukrotna.

5. Słaby hosting

Najtańszy współdzielony hosting, na którym siedzi 500 innych stron walczących o ten sam procesor, po prostu odpowiada wolno. Czasem najszybszą optymalizacją jest zmiana serwera.

6. Brak CDN

Jeśli serwer stoi w Niemczech, a użytkownik jest w Australii, dane fizycznie muszą przebyć pół świata. CDN trzyma kopie Twojej strony bliżej użytkownika. Dla WordPressa najprostszą drogą jest darmowy Cloudflare — pokazuję to krok po kroku w Cloudflare przed WordPressem za darmo.

Oś czasu ładowania zasobów z zaznaczonym momentem LCP

Na osi czasu powyżej widać dobrze, jak to działa: zasoby pobierają się jeden po drugim, a render-blocking CSS i JS odsuwają moment, w którym użytkownik w ogóle cokolwiek zobaczy (LCP). Każdy „klocek” na tej osi to potencjalne miejsce do skrócenia.

Jak to zmierzyć (zanim zaczniesz cokolwiek poprawiać)

Nie optymalizuj „na czuja”. Najpierw zmierz, żeby wiedzieć, gdzie naprawdę boli. Dwa darmowe narzędzia wystarczą na start.

  • PageSpeed Insights (pagespeed.web.dev) — wklejasz adres, dostajesz ocenę osobno dla telefonu i komputera oraz konkretne podpowiedzi.
  • Lighthouse — wbudowany w przeglądarkę Chrome (zakładka „Lighthouse” w narzędziach deweloperskich). Działa też offline, na stronie lokalnej.

Warto rozumieć jedną ważną różnicę:

Rodzaj danychCo to jest
Dane laboratoryjne (lab)Pojedynczy test w kontrolowanych warunkach. Powtarzalny, ale „sterylny”.
Dane terenowe (field)Pomiary od prawdziwych użytkowników Twojej strony przez ostatnie 28 dni.

Wynik w teście potrafi być piękny, a realni użytkownicy i tak narzekają na wolność — bo wchodzą ze słabszych telefonów i gorszego łącza. Dlatego nie patrz wyłącznie na okrągłą liczbę. Rozwijam ten wątek w Lighthouse 100/100 — czy warto i jak to ugryźć.

Szybkie wygrane — od czego zacząć dziś

Jeśli chcesz odczuwalnego efektu bez przebudowy całej strony, zacznij od tych pięciu rzeczy. To zwykle 80% efektu przy 20% wysiłku.

  1. Skompresuj i przeskaluj obrazy. Zwykle największa pojedyncza wygrana. WebP/AVIF zamiast ciężkich JPEG/PNG.
  2. Włącz cache. Na WordPressie wtyczka cache lub cache serwera (np. LiteSpeed) potrafi zdziałać cuda jednym kliknięciem.
  3. Postaw Cloudflare przed stroną. Darmowy CDN, cache i kompresja — szczegóły w osobnym wpisie.
  4. Wytnij zbędne wtyczki i skrypty. Każdy widget, którego nie używasz, to czysty narzut. Mniej znaczy szybciej.
  5. Dodaj loading="lazy" do obrazów poniżej ekranu. Niech ładują się dopiero, gdy użytkownik do nich dojdzie.

Uwaga na wtyczki do szybkości

Instalowanie pięciu wtyczek przyspieszających naraz potrafi spowolnić stronę bardziej, niż było na początku — bo się nawzajem gryzą i dublują. Lepiej jedna, dobrze skonfigurowana, niż arsenał włączony „na wszystko”.

Podsumowanie

Osiem sekund ładowania to nie pech ani „taki internet”. To suma konkretnych, naprawialnych przyczyn — ciężkich obrazów, nadmiaru skryptów, braku cache i słabego hostingu. A każda z tych sekund kosztuje Cię realnie: w odrzuceniach, w konwersji i w pozycji w Google.

Dobra wiadomość jest taka, że większość z tego da się naprawić szybciej, niż myślisz — i bardzo często bez przebudowy całej strony. Zacznij od pomiaru, weź się za obrazy i cache, postaw Cloudflare. Resztę dołożysz warstwami.

Chcesz, żebym sprawdził, co spowalnia akurat Twoją stronę, i powiedział wprost, co da największy efekt? Napisz do mnie — przejrzę ją i podeślę konkretną listę.