Wolna strona zabija sprzedaż – ile tracisz każdego dnia?

Trzy sekundy. Tyle czasu daje Ci przeciętny użytkownik mobilny, zanim zamknie kartę i pójdzie do konkurencji. Jeśli prowadzisz sklep internetowy albo generujesz leady przez stronę, każda dziesiąta część sekundy przekłada się na pieniądze. Ten artykuł powstał w vollelabs – budujemy szybkie strony i sklepy, więc temat znamy od kuchni.

Co mówią dane: sekundy zamieniają się w straty

Zacznijmy od liczb, bo na nich najłatwiej oprzeć decyzję.

Według badania Google/SOASTA z 2017 roku (wciąż najczęściej cytowanego źródła w branży), gdy czas ładowania strony mobilnej rośnie z 1 do 3 sekund, prawdopodobieństwo odrzucenia (bounce) wzrasta o 32%. Przy 5 sekundach skok sięga już 90%.

Badanie „Milliseconds Make Millions" (Google / Deloitte / 55, 2019–2020) wykazało, że poprawa czasu ładowania o zaledwie 0,1 sekundy zwiększyła konwersje w e-commerce o 8,4%, a średnią wartość zamówienia o 9,2%.

Raport Portent z 2022 roku pokazał z kolei, że strona B2B ładująca się w 1 sekundę ma współczynnik konwersji 3× wyższy niż strona ładująca się w 5 sekund.

Przełóżmy to na przykład. Sklep z obrotem 500 000 zł miesięcznie i średnim czasem ładowania 4,5 s poprawia go do 2 s. Jeśli założymy nawet połowę efektu opisanego przez Deloitte (bo warunki każdego sklepu są inne), mówimy o kilkudziesięciu tysiącach złotych dodatkowego przychodu miesięcznie – bez ruszania budżetu reklamowego.

Vodafone: prosty test A/B, 8% więcej sprzedaży

Teoria to jedno. Zobaczmy, co się dzieje w praktyce.

Vodafone Italy przeprowadził test A/B, w którym jedyną różnicą między wariantami była optymalizacja Web Vitals. Poprawa LCP (Largest Contentful Paint) o 31% przełożyła się na 8% wzrost sprzedaży, 15% więcej leadów i 11% wzrost wskaźnika „koszyk / wizyta".

Co zrobili? Przenieśli renderowanie widgetu z klienta na serwer (server-side rendering), zredukowali render-blocking JavaScript i zoptymalizowali obrazy – m.in. zmniejszyli hero image i zastosowali media queries, żeby nie ładować grafik spoza widocznego ekranu.

Żadna z tych zmian nie wymagała przebudowy serwisu. To były poprawki na istniejącym kodzie.

Core Web Vitals – trzy metryki, które Google (i klienci) oceniają

Jeśli nie śledzisz jeszcze Core Web Vitals, czas zacząć. To zestaw trzech metryk, których Google używa do oceny szybkości ładowania, interaktywności i stabilności wizualnej strony: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) i Cumulative Layout Shift (CLS).

• LCP – ile czasu mija do wyrenderowania największego elementu widocznego na ekranie (np. zdjęcia produktu). Dobry wynik to poniżej 2,5 sekundy.
• INP – jak szybko strona reaguje na kliknięcia i tapnięcia. Cel: poniżej 200 ms.
• CLS – czy elementy „przeskakują" podczas ładowania. Cel: poniżej 0,1.

Według HTTP Archive Web Almanac 2024 tylko 43% stron mobilnych przechodzi pozytywnie wszystkie trzy metryki. To znaczy, że ponad połowa internetu wciąż nie spełnia standardów. Jeśli Twoja strona je spełnia – masz przewagę. Jeśli nie – oddajesz ją konkurencji.

Jak to sprawdzić samodzielnie: audyt w 15 minut

Nie musisz od razu dzwonić do agencji. Poniższe kroki zajmą kwadrans i pokażą, gdzie jesteś.

Krok 1: PageSpeed Insights

Wejdź na pagespeed.web.dev, wklej adres swojej strony i kliknij „Analizuj". Narzędzie oceni wydajność strony na urządzeniach mobilnych i desktopie, korzystając z danych laboratoryjnych (Lighthouse) i danych od prawdziwych użytkowników Chrome (CrUX).

Skup się na sekcji „Field Data" (dane terenowe) – to obraz tego, co naprawdę widzą Twoi klienci. Wynik „Lab" jest przydatny do debugowania, ale nie odzwierciedla warunków realnego ruchu.

Krok 2: Sprawdź raport Core Web Vitals w Search Console

Jeśli masz podłączony Google Search Console, otwórz zakładkę „Core Web Vitals". Zobaczysz podział swoich URL-i na trzy kategorie: Dobre, Wymaga poprawy, Słabe. Zacznij od tych oznaczonych na czerwono.

Krok 3: GTmetrix – waterfall request po request

Wejdź na gtmetrix.com i przetestuj tę samą stronę. GTmetrix pokaże Ci wykres „Waterfall" – chronologiczną listę wszystkich zasobów, które ładuje przeglądarka. Szukaj:

• plików JS i CSS blokujących renderowanie (oznaczone na pomarańczowo/czerwono),
• obrazów powyżej 200 KB (na mobilnym ekranie rzadko potrzebujesz więcej),
• zapytań do zewnętrznych domen (trackery, czaty, fonty) – każde dodaje opóźnienie.

Co możesz naprawić sam, a co wymaga developera

Krótkie wyjaśnienie dwóch pojęć z tabeli:

Lazy loading – technika, w której obrazy i elementy poza widocznym ekranem nie są ładowane od razu, lecz dopiero gdy użytkownik przewinie do nich stronę. Dzięki temu przeglądarka pobiera mniej danych na starcie, a LCP spada.

CDN (Content Delivery Network) – sieć serwerów rozmieszczonych geograficznie, które serwują statyczne pliki (grafiki, CSS, JS) z lokalizacji najbliższej użytkownikowi. Klient z Gdańska dostaje pliki z Europy, nie z USA.

Typowe „ciche złodzieje" prędkości

Na koniec – trzy rzeczy, które widujemy najczęściej podczas audytów w vollelabs i które regularnie spowalniają strony o 1–3 sekundy:

1. Nieskompresowane hero image o wadze 2–5 MB. Zamiana na WebP z odpowiednią kompresją zmniejsza rozmiar o 60–80% bez widocznej utraty jakości. Narzędzie: Squoosh od Google – działa w przeglądarce, nie wymaga instalacji.
2. Dziesięć skryptów marketingowych ładowanych synchronicznie w <head>. Piksel Facebooka, Google Tag Manager, chat, heatmapa, pop-up, ankieta… Każdy z nich walczy o zasoby przeglądarki zanim strona zdąży się wyrenderować. Rozwiązanie: ładuj je asynchronicznie lub – jeszcze lepiej – przez Google Tag Manager z trigerem „Window Loaded".
3. Fonty ładowane z zewnętrznego serwera bez font-display: swap. Efekt: użytkownik widzi pustą stronę przez 1–2 sekundy, bo przeglądarka czeka na plik czcionki. Dodanie jednej linijki CSS (font-display: swap;) sprawia, że tekst wyświetla się od razu w foncie zastępczym, a docelowy podmienia się po załadowaniu.