Dlaczego Twoja strona ładuje się jak ślimak wybierający się na wakacje i jak to naprawić

Twoja strona wczytuje się 4 sekundy. Użytkownik czeka 3 i zamyka kartę. Trafił do konkurencji.

Nie dlatego, że oferta jest słaba. Nie dlatego, że treść nudna. Dlatego, że ktoś wybrał złą metodę budowania zanim strona w ogóle powstała. Albo nie zadbał o optymalizację po starcie. Albo oba naraz.

Szybkość strony wpływa na trzy rzeczy: ile osób zostaje i kupuje, jak wysoko Google ją rankuje i ile płacisz za hosting. To nie są oddzielne problemy. Jak przyspieszyć stronę to nie jedna decyzja. To system kilku kroków, które da się przejść po kolei.

Najpierw zmierz: jak sprawdzić szybkość strony

Negative Space / Pexels

Zanim cokolwiek poprawisz, zmierz co masz. Google PageSpeed Insights jest bezpłatny i działa w przeglądarce. Wklej adres strony, kliknij Analizuj, czekaj 30 sekund. Dostaniesz wynik od 0 do 100 i konkretną listę problemów w kolejności ważności. Wynik poniżej 50 oznacza poważny problem (i minę, którą warto zobaczyć samemu, zanim pokaże ją klientowi).

PageSpeed mierzy między innymi Core Web Vitals. To trzy metryki, które Google oficjalnie włącza do algorytmu rankingowego. LCP (Largest Contentful Paint) to czas do wyświetlenia głównego elementu strony, cel: poniżej 2,5 sekundy. CLS (Cumulative Layout Shift) sprawdza czy elementy nie przeskakują podczas ładowania. Baner, który przesuwa się o centymetr w trakcie renderowania, obniża wynik do zera. INP (Interaction to Next Paint) mierzy jak szybko strona reaguje na kliknięcia. Słaby wynik w Core Web Vitals bezpośrednio obniża pozycję w Google.

GTmetrix i Pingdom dają więcej danych technicznych: waterfall ładowania, który pokazuje co i kiedy się pobiera, TTFB (czas do pierwszego bajtu, czyli jak długo serwer myśli zanim w ogóle odpowie) i rozmiar każdego zasobu z osobna. Przydatne gdy PageSpeed wskazuje problem, ale nie jest jasne gdzie dokładnie leży.

Jeden szczegół, który pomija większość: mierz na wersji mobilnej, nie desktopowej. Google indeksuje strony w trybie mobile-first. Wynik na komputerze bywa 90, na telefonie 40. I to ten drugi Google bierze pod uwagę przy ustalaniu pozycji w wynikach wyszukiwania.

Fundamenty: jak budujesz stronę decyduje o wszystkim

Ahmet Cantürk / Pexels

Wyobraź sobie, że Twoja strona internetowa to książka. I są trzy księgarnie, w których możesz ją kupić. Ta sama książka, zupełnie inne doświadczenie.

Księgarnia pierwsza (SSG): wchodzisz, książka stoi na półce, bierzesz, płacisz, wychodzisz. Sprzedawca nie musi nic robić. Wcześniej ją tam położył. Google wchodzi do tej samej księgarni, widzi książkę, czyta okładkę i indeksuje. Wszystko gotowe zanim ktokolwiek zapytał.

Księgarnia druga (SSR): przy kasie stoi drukarka i bardzo sprawny pracownik. Zamawiasz, pracownik biegnie na zaplecze, wraca ze świeżym egzemplarzem wydrukowanym specjalnie dla Ciebie. Dostajesz zawsze aktualną wersję. Jeśli jednak 500 osób zamówi tę samą książkę jednocześnie, pracownik pada z wyczerpania (i rachunek za prąd rośnie proporcjonalnie do kolejki).

Księgarnia trzecia (CSR): dostajesz pustą okładkę, zestaw niezłożonych kartek i instrukcję obsługi drukarki. Drukarka jest u Ciebie w domu. Twój komputer musi pobrać plik, uruchomić maszynę i złożyć całość przed pierwszym słowem. Google przyszło, zobaczyło pustą okładkę, postało chwilę i wyszło. Nie zaindeksowało nic, bo nie było co.

SSG: strona gotowa zanim zapytasz

Wendelin Jacober / Pexels

SSG (Static Site Generation) działa tak: budujesz stronę raz i gotowe. Każda podstrona to gotowy plik HTML czekający na serwerze. Serwer nie musi nic obliczać, nie musi pytać bazy danych, nie musi nawet myśleć (co jest dobre, bo myślący serwer kosztuje). Dostaje zapytanie, wysyła plik. Koniec.

Zalety są trzy: błyskawiczne ładowanie, świetne wyniki w Google i rachunek za hosting, który nie wywoła trudnych rozmów z księgowością.

Wada jest jedna: po zmianie treści strona musi być przebudowana. Jeśli masz sklep z 50 000 produktów ze zmiennymi cenami aktualizowanymi co godzinę, SSG nie jest dla Ciebie. Jeśli masz blog, stronę firmową lub portfolio aktualizowane raz na kilka dni, SSG to właściwa odpowiedź na większość pytań o szybkość.

SSR: zawsze aktualne, zawsze kosztujące

SSR (Server-Side Rendering) to drukarka przy ladzie. Każde wejście na stronę uruchamia serwer, który pobiera aktualne dane, składa HTML i wysyła go do przeglądarki. Strona jest zawsze świeża, bez przebudowywania po każdej zmianie.

Koszt: czas i pieniądze. Serwer wykonuje pracę przy każdym żądaniu. Przy 10 użytkownikach jednocześnie, żaden problem. Przy 10 000 jednocześnie serwer zaczyna się pocić, a Ty razem z nim, patrząc na fakturę za hosting.

SSR ma sens tam gdzie dane zmieniają się często i muszą być aktualne w momencie wyświetlenia: sklep internetowy z aktualnym stanem magazynu, panel użytkownika z jego danymi, wyniki wyszukiwania w czasie rzeczywistym.

CSR: interaktywność kosztem widoczności

panumas nikhomkhai / Pexels

CSR (Client-Side Rendering) to model, który brzmi sensownie do momentu, gdy zaczniesz myśleć o Google.

Serwer wysyła pustą stronę i plik JavaScript. Przeglądarka pobiera JavaScript (chwila), uruchamia go (chwila), JavaScript pobiera dane z API (chwila), dopiero wtedy buduje stronę widoczną dla użytkownika (kolejna chwila). Każda z tych chwil to kilkaset milisekund. Razem: biały ekran i kręcące się kółeczko, które użytkownik ogląda zastanawiając się, czy kliknął w link, czy w przypadkowe powietrze.

90% stron, które mogłyby być SSG, jest zbudowanych w CSR. I płacą za to w Google. Googlebot technicznie potrafi uruchamiać JavaScript. Robi to jednak z opóźnieniem, rzadziej i nie zawsze tam gdzie myślisz. SSG eliminuje ten problem całkowicie.

CSR ma sens dla aplikacji za loginem: panele użytkownika, dashboardy, narzędzia wewnętrzne. Miejsc, gdzie SEO nie gra roli, bo i tak nikt z zewnątrz tam nie trafia. Twój panel bankowy nie musi być w Google. Twoja strona firmowa musi.

Zdjęcia: największy pożeracz megabajtów

Neron Photos / Pexels

Zdjęcia to najczęstszy i najłatwiejszy do naprawienia powód wolnego ładowania. Typowe zdjęcie ze smartfona waży 4-8 MB. Zdjęcie na stronie internetowej powinno ważyć maksymalnie kilkaset kilobajtów, najlepiej poniżej 200 KB. Różnica między tymi dwoma liczbami to czas, który użytkownik spędza na wpatrywaniu się w biały ekran, zastanawiając się czy kliknął we właściwy link.

Format ma znaczenie. JPEG jest standardem dla zdjęć. WebP jest lżejszy o 25-35% i obsługiwany przez wszystkie nowoczesne przeglądarki (a za nienowoczesne przeglądarki w 2025 roku nikt nie powinien już odpowiadać). Konwersja zajmuje minuty. Narzędzie Squoosh.app robi to bezpłatnie, bez instalacji, w przeglądarce.

Rozmiar w pikselach to osobna kwestia. Kolumna treści ma zazwyczaj 800-1200 pikseli szerokości. Wgrywanie zdjęcia 4000x3000 pikseli jest jak drukowanie plakatu A0 żeby powiesić go na etykiecie. Przeglądarka i tak je zmniejszy do wyświetlenia, ale najpierw musi je w całości pobrać.

Jeden zoptymalizowany baner to często 1-2 sekundy szybszego ładowania. Bez żadnych zmian w kodzie, bez deweloperów, bez budżetu. Co jest lekko upokarzające dla każdego, kto spędził tydzień optymalizując JavaScript, podczas gdy problemem był banner z wakacji w jakości 4K.

Lazy loading: ładuj tylko to, co widać

Bez lazy loadingu przeglądarka pobiera wszystkie zdjęcia na stronie naraz, przy wejściu, niezależnie od tego czy użytkownik je kiedykolwiek zobaczy. To jak pakowanie całej szafy na jednodniowy wyjazd. Na wszelki wypadek.

Lazy loading zmienia zasadę: przeglądarka pobiera tylko to, co jest aktualnie widoczne na ekranie. Zdjęcia na dole strony czekają w kolejce dopóki użytkownik tam nie dotrze. Strona z galerią 20 zdjęć zaczyna ładować 3-4, reszta wchodzi stopniowo. Czas do pierwszego wyświetlenia treści skraca się kilkukrotnie.

Większość nowoczesnych frameworków implementuje lazy loading domyślnie. Na WordPressie wystarczy atrybut loading="lazy" w tagu obrazka albo wtyczka. Na starszych stronach kilka linii JavaScript. To jedna z tych zmian, które działają natychmiast i nie wymagają tłumaczenia klientowi dlaczego strona jest teraz szybsza.

Cache przeglądarki: nie rób dwa razy tej samej pracy

Cache przeglądarki działa jak dobra pamięć: przy pierwszej wizycie przeglądarka zapisuje logo, czcionki, arkusze CSS i pliki JavaScript na dysku użytkownika. Przy kolejnej wizycie pyta dysk, nie serwer. Zero ruchu sieciowego dla wszystkiego co się nie zmieniło.

Dla użytkownika, który wraca na stronę: natychmiastowe ładowanie elementów statycznych. Dla serwera: mniej żądań, mniej pracy, mniejszy rachunek. Dla Google: krótszy czas ładowania przy wielokrotnych indeksowaniach, a Google indeksuje częściej strony które odpowiadają szybko (mechanizm nagradzania, który działa jak odwrotność kolejki w urzędzie).

Cache konfiguruje się przez nagłówki HTTP po stronie serwera. Na WordPressie robią to wtyczki: WP Rocket, LiteSpeed Cache, W3 Total Cache. Warto zapytać czy jest włączony. Na tańszych hostingach często nie jest. Nikt tego nie wymaga, więc nikt tego nie ustawia, więc Twój serwer wykonuje tę samą pracę przy każdej wizycie jak pracownik, który nie słyszał o copy-paste.

CDN: bliżej użytkownika, szybciej w przeglądarce

Twoja strona jest wgrana na serwer w Warszawie. Bez CDN, użytkownik z Krakowa pobiera ją z Warszawy. Użytkownik z Londynu pobiera ją z Warszawy. Użytkownik z Sydney pobiera ją z Warszawy, a każdy pakiet danych odbywa trasę w obie strony jakby poczta zdecydowała, że wszystkie listy muszą przejść przez centralę, niezależnie od tego skąd i dokąd jadą.

CDN (Content Delivery Network) rozstawia kopie Twojej strony na serwerach na całym świecie. Cloudflare ma punkty w kilkuset miastach. Czas podróży danych ze 200 ms spada do 15 ms. Dla użytkownika: strona ładuje się szybciej. Dla Google: niższy TTFB to jeden z sygnałów rankingowych. Robot też mierzy, zanim stronę zobaczy.

Cloudflare w wersji darmowej działa dla większości małych i średnich stron. Za darmo. Przy słowie CDN brzmi to jak pomyłka, ale nie jest. Konfiguracja sprowadza się do zmiany serwerów DNS i kilku kliknięć w panelu. Godzina roboty, efekt trwały.

Minifikacja i kompresja: kod na odchudzaniu

Plik CSS wychodzi spod rąk dewelopera jak wypracowanie z komentarzami na marginesie: spacje, opisy, nazwy zmiennych w stylu "kolor-naglowka-sekcji-o-nas-na-stronie-glownej". Przeglądarka tego nie czyta. Rozumie kod po usunięciu wszystkiego zbędnego równie dobrze, tylko szybciej.

Minifikacja usuwa wszystko zbędne. Plik 150 KB po minifikacji może ważyć 90 KB. Do tego Gzip lub Brotli kompresuje dane podczas transferu, jak próżniowe pakowanie walizki przed lotem: ta sama zawartość, trzy razy mniej miejsca. Przeglądarka odbiera spakowany plik, rozpakowuje lokalnie.

Nowoczesne narzędzia budowania stron (Webpack, Vite, Parcel) minifikują automatycznie przy wersji produkcyjnej. Na WordPressie robią to wtyczki cachujące. Warto sprawdzić czy jest włączone. PageSpeed wskazuje brak minifikacji jako jeden z pierwszych problemów i ma rację.

Zasoby blokujące renderowanie: kolejka, która zatrzymuje wszystko

Przeglądarka buduje stronę od góry do dołu. Gdy natrafi na plik JavaScript lub arkusz CSS w nagłówku, zatrzymuje się. Pobiera plik, przetwarza go, dopiero potem rusza dalej. To jak malarz, który zatrzymuje się w połowie ściany, żeby przeczytać instrukcję obsługi pędzla. Przy każdym pociągnięciu.

Trzy podejścia do rozwiązania: przenieść skrypty na koniec strony (ładują się po treści), oznaczyć je atrybutem async lub defer (ładują się równolegle, nie blokując), albo scalić wiele małych plików w jeden (mniej żądań do serwera). Wszystkie trzy działają. Żadne nie wymaga przepisania strony od zera, co agencje często proponują jako pierwsze rozwiązanie, bo przepisanie strony kosztuje, a dodanie defer do jednego tagu script nie.

Google PageSpeed prawie zawsze wskazuje zasoby blokujące renderowanie w pierwszej trójce problemów. Jeśli widzisz to w raporcie, masz konkretne zadanie i konkretne miejsce do naprawy.

Hosting: podłoga pod wszystkimi optymalizacjami

panumas nikhomkhai / Pexels

Hosting to podłoga, od której zależy sufit. Możesz zrobić wszystko co powyżej: zoptymalizować zdjęcia, wdrożyć CDN, skonfigurować cache, minifikować kod. I nadal mieć wolną stronę, jeśli serwer jest przeciążony. Optymalizacja na złym hostingu to jak wycieranie podłogi podczas powodzi.

Tani współdzielony hosting działa jak jeden apartament podzielony przez 200 lokatorów. Jeden z nich uruchamia skrypt, który żre zasoby. Wszystkie strony na serwerze zwalniają. Inny wgrywa 50 GB plików i każdy odczuwa to przez godzinę. Płacisz mało, bo dzielisz się wszystkim, łącznie z cudzymi problemami.

TTFB (Time To First Byte) to czas, który upływa od wysłania zapytania do odebrania pierwszego bajtu odpowiedzi. Powinien wynosić poniżej 200 ms. Jeśli PageSpeed lub GTmetrix pokazuje TTFB na poziomie 1-2 sekund, problem leży w hostingu, nie w zdjęciach ani kodzie. Żadna ilość skompresowanych plików nie poprawi TTFB 1500 ms do akceptowalnego poziomu.

Serwery VPS i hosting zarządzany (Kinsta, WP Engine dla WordPressa; Vercel, Netlify dla aplikacji Next.js) kosztują więcej, ale serwer nie jest współdzielony z setką innych stron. Zmiana hostingu to operacja jednorazowa i często pierwsza, która faktycznie cokolwiek zmienia w wynikach PageSpeed.

Co możesz zrobić sam, a co oddaj specjaliście

Część optymalizacji możesz zrobić samodzielnie: skompresować zdjęcia w Squoosh, sprawdzić wynik PageSpeed, włączyć CDN przez Cloudflare, zainstalować wtyczkę cache na WordPressie. Efekt widoczny w ciągu godziny, bez dewelopera, bez budżetu. Co jest albo zachęcające, albo frustrujące, w zależności od tego ile zapłaciłeś agencji za optymalizację.

Część wymaga dewelopera albo świadomego wyboru na etapie projektowania strony: wybór architektury (SSG, SSR czy CSR), konfiguracja minifikacji i kompresji po stronie serwera, eliminacja zasobów blokujących renderowanie, optymalizacja bazy danych. Tu nie ma skrótów i nie ma wtyczki, która to załatwi.

Najdroższy błąd to zlecenie strony najtańszej agencji, a potem płacenie za optymalizację rok później. Zapytaj o wynik PageSpeed i architekturę renderowania przed podpisaniem umowy. Agencja, która nie wie co to TTFB, prawdopodobnie nie wie też co robi z Twoim hostingiem. Nie po tym jak Google zdążyło Cię zignorować.