Prędkość zabija: ile naprawdę kosztuje wolna strona

Czas ładowania to liczba przychodowa. Nie metryka techniczna — liczba przychodowa. Amazon raportował, że każde 100 ms dodatkowego opóźnienia kosztuje 1% sprzedaży. Własne dane Google pokazują, że współczynnik odrzuceń rośnie o 32%, gdy czas ładowania wydłuża się z 1 s do 3 s.

Twoja strona prawdopodobnie jest wolna w sposób, którego dotąd nie zmierzyłeś.

Realne liczby

Largest Contentful Paint (LCP) to metryka, która najsilniej koreluje z konwersją. Progi Google:

• Dobrze: poniżej 2,5 s.
• Wymaga poprawy: 2,5 s – 4 s.
• Słabo: powyżej 4 s.

Większość firmowych serwisów, które audytujemy, ląduje w przedziale 3–6 s. Różnica między 6 s a 2 s to nie jest sukces designu — to wzrost współczynnika konwersji widoczny w przychodzie.

Gdzie ucieka czas

Obrazy — niezoptymalizowane obrazy są najczęstszym sprawcą. Hero o rozmiarze 4 MB serwowane użytkownikom mobilnym to 4 MB podatku od każdego pierwszego wrażenia.

Skrypty trzecich stron — analityka, widgety czatu, piksele reklamowe. Każdy z nich blokuje renderowanie. Typowa strona marketingowa ładuje od 8 do 12 zewnętrznych skryptów.

Zasoby blokujące renderowanie — CSS i JS ładowane w head dokumentu, które blokują przeglądarce możliwość narysowania czegokolwiek.

Czas odpowiedzi serwera (TTFB) — jeśli serwer odpowiada po 800 ms, żadna optymalizacja frontu nie zamknie tej luki.

Renderowanie po stronie klienta — SPA, które wysyłają pustą stronę HTML, a następnie hydratują, są z definicji wolne na pierwszym załadowaniu.

Stack naprawczy

Dla większości serwisów najsilniejsze dźwignie usprawnień w kolejności:

1. Przeniesienie na runtime CDN-edge — Vercel, Cloudflare Pages albo podobne. TTFB poniżej 100 ms globalnie.
2. Zoptymalizowane obrazy — next/image lub Cloudflare Image Resizing. WebP, właściwe wymiary, lazy loading.
3. Odroczenie niekrytycznych skryptów — analityka i widgety czatu ładowane po momencie, w którym strona staje się interaktywna.
4. Eliminacja CSS blokującego renderowanie — inline krytycznego CSS, reszta odraczana.
5. Przejście na renderowanie po stronie serwera — wstępnie wyrenderowany HTML, by użytkownik widział treść natychmiast.

Jak mierzyć poprawnie

Nie testuj wydajności z biura na szybkiej maszynie. Stosuj:

• WebPageTest z mobilnym połączeniem 4G throttled.
• Lighthouse CI w pipeline buildowym, aby wyłapać regresje.
• Core Web Vitals w Google Search Console dla danych z realnych użytkowników.

Cel jest jeden: być widocznie szybkim na średniej klasy telefonie z Androidem, w zatłoczonej sieci mobilnej. Wszystko inne to optymalizowanie pod publiczność, która i tak by tego nie zauważyła.