Strona ładująca się 3 sekundy na urządzeniu mobilnym traci około 53% odwiedzających z telefonu, zanim zdążą zobaczyć jakikolwiek produkt (dane Google dotyczące progów porzuceń na urządzeniach mobilnych).
Spośród tych, którzy zostają, każda dodatkowa sekunda ładowania wiąże się ze spadkiem konwersji o około 7% (dane z badań Akamai, Google i Portent). Dla sklepu generującego 10 000 € miesięcznie oznacza to 700 € utraconego przychodu za każdą dodatkową sekundę ładowania strony.
Żaden inny typ strony internetowej nie traci tyle na słabej wydajności i nie zyskuje tyle po jej poprawie co sklep e-commerce.
Liczby stojące za szybkością
Związek między prędkością ładowania a przychodami był szeroko badany. Wyniki są spójne niezależnie od branży i okresu:
| Badanie / źródło | Wynik |
|---|---|
| Google / Deloitte (2019) | Poprawa o 0,1 sekundy zwiększa współczynnik konwersji na urządzeniach mobilnych o 8% |
| Amazon (badanie wewnętrzne) | Każde 100 ms opóźnienia to 1% utraty przychodów |
| Walmart (badanie wewnętrzne) | Poprawa o 1 sekundę przekłada się na wzrost konwersji o 2% |
| Portent (2019) | Strony ładujące się w 1 sekundę konwertują 3 razy lepiej niż te ładujące się w 5 sekund |
To nie są wyniki z wyjątkowych warunków. Pochodzą z dużych zbiorów rzeczywistych danych obejmujących miliony transakcji. Kierunek jest zawsze ten sam: szybciej oznacza więcej przychodów.
Dlaczego m-commerce rządzi się innymi prawami
Ponad 70% ruchu w sklepach e-commerce pochodzi już z urządzeń mobilnych. Mimo to konwersja na telefonach wynosi około 2%, podczas gdy na komputerach stacjonarnych sięga 4%. Ta różnica, przekładająca się na miliardy w nierealizowanych przychodach całej branży, wynika głównie z prędkości i użyteczności na urządzeniach mobilnych.
Połączenia mobilne nie są jednorodne. Zasięg 4G jest nierówny, szczególnie na obszarach wiejskich. Tańsze smartfony z Androidem, stanowiące znaczną część rynku, mają wolniejsze procesory, które nie radzą sobie ze stronami intensywnie korzystającymi z JavaScript. Strona produktu, która działa bez zarzutu na nowym iPhonie w centrum miasta, może być praktycznie bezużyteczna dla sporej części rzeczywistych klientów.
Model interakcji jest tu odmienny. Nawigacja kciukiem, małe obszary dotykowe i formularze zamówień zaprojektowane z myślą o komputerze tworzą dodatkowe tarcia. Gdy nakładają się one na wolno ładującą się stronę, wskaźnik porzuceń rośnie bardzo szybko.
- Ponad 70% ruchu w e-commerce pochodzi z urządzeń mobilnych, ale konwersja na telefonach jest około dwukrotnie niższa niż na komputerach
- Połączenia 4G znacznie różnią się jakością w zależności od lokalizacji i klasy urządzenia
- Tańsze smartfony to duża część rzeczywistych użytkowników, nie tylko przypadki brzegowe
- Tarcia przy finalizacji zamówienia na telefonie są zwielokrotnione, gdy strona reaguje wolno
Core Web Vitals i ich znaczenie dla sklepu
Google mierzy wydajność stron za pomocą zestawu wskaźników zwanych Core Web Vitals. Każdy z nich bezpośrednio odzwierciedla doświadczenie klientów podczas zakupów:
| Wskaźnik | Co mierzy | Znaczenie dla e-commerce | Dobry | Wymaga poprawy | Słaby |
|---|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Czas do wyświetlenia głównej treści strony | Główne zdjęcie produktu lub baner promocyjny | Poniżej 2,5 s | 2,5 s do 4 s | Powyżej 4 s |
| INP (Interaction to Next Paint) | Szybkość reakcji strony na kliknięcia i dotknięcia | Przycisk dodaj do koszyka, filtry, zmiana ilości | Poniżej 200 ms | 200 ms do 500 ms | Powyżej 500 ms |
| CLS (Cumulative Layout Shift) | Stopień przesunięć elementów podczas ładowania | Przesuwanie się listy produktów w trakcie wczytywania zdjęć | Poniżej 0,1 | 0,1 do 0,25 | Powyżej 0,25 |
Strony z zielonymi wynikami we wszystkich trzech Core Web Vitals otrzymują wyższe pozycje w wynikach wyszukiwania Google. Strony, które nie spełniają norm, są przesuwane w dół. Wolny sklep ponosi zatem podwójną karę: mniejszą widoczność organiczną oraz niższy współczynnik konwersji z ruchu, który mimo wszystko dociera.
Słaby wynik INP w sklepie e-commerce jest szczególnie kosztowny. Gdy klient dotyka przycisku "Dodaj do koszyka" i przez pół sekundy nic się nie dzieje, wiele osób kliknie ponownie lub uzna stronę za zepsutą i ją opuści.
WooCommerce i problem wtyczek
WooCommerce obsługuje znaczną część sklepów e-commerce i jednocześnie jest jedną z platform z największymi wyzwaniami wydajnościowymi przy skali. Typowy działający sklep WooCommerce uruchamia 50-80 wtyczek, z których każda dodaje żądania HTTP, czas wykonania JavaScript i narzut CSS.
Konsekwencje na poziomie strony:
- Strony produktów przenoszą zazwyczaj 4-8 MB danych przy pierwszym załadowaniu
- Standardowa strona produktu WooCommerce może wyzwalać ponad 100 zapytań do bazy danych
- Paczki JavaScript z wielu wtyczek często blokują renderowanie
- Skrypty zewnętrzne (recenzje, czat na żywo, analityka) wydłużają łańcuch zapytań
- LCP WooCommerce na urządzeniach mobilnych wynosi typowo 4-6 sekund w audytach webvise; wyniki zależą od motywu i zestawu wtyczek.
Zakres 4-6 sekund LCP zdecydowanie mieści się w kategorii "słaby" według skali Google i przekracza próg porzucenia dla większości użytkowników mobilnych. Wtyczki do cache'owania łagodzą objaw, ale nie zmieniają architektury, która go powoduje.
Problem zapytań do bazy danych ma charakter strukturalny. WooCommerce generuje strony produktów dynamicznie przy każdym żądaniu, pobierając przy każdym ładowaniu dane produktu, reguły cenowe, stan magazynu, produkty powiązane i stan koszyka. Przy ponad 100 zapytaniach na ładowanie strony nawet szybki hosting osiąga swój sufit.
Jak wygląda zoptymalizowany stos e-commerce
Architektura headless commerce rozdziela frontend, czyli to, co klienci widzą i z czym wchodzą w interakcję, od backendu odpowiedzialnego za produkty, magazyn i zamówienia. Frontend jest budowany w Next.js i prerenderowany w czasie kompilacji. Backend (Shopify, BigCommerce lub WooCommerce w trybie headless) obsługuje transakcje przez API.
Różnica wydajnościowa ma charakter strukturalny, nie kosmetyczny:
- Strony produktów Static/ISR: prerenderowane w czasie kompilacji i serwowane bezpośrednio z węzłów CDN, bez PHP i zapytań do bazy danych przy ładowaniu
- Leniwe ładowanie zdjęć produktów: obrazy poza widocznym obszarem wczytują się dopiero gdy są potrzebne, w nowoczesnych formatach (WebP, AVIF) zmniejszających rozmiar pliku o 30-50% w stosunku do JPEG przy porównywalnej jakości (pomiary Cloudinary i Web.dev)
- Minimalny JavaScript: brak jQuery, brak pełnego Bootstrap, paczki po tree-shakingu zawierające wyłącznie kod potrzebny na danej stronie
- Incremental Static Regeneration: strony produktów aktualizują się automatycznie po zmianie stanu magazynu lub cen, bez pełnej rekompilacji
| Wskaźnik | WooCommerce (typowo) | Next.js Headless (typowo) |
|---|---|---|
| LCP (mobilne) | 4-6 sekund | Poniżej 1,5 sekundy |
| Czas do interaktywności | 6-10 sekund | Poniżej 2 sekund |
| Waga strony produktu | 4-8 MB | Poniżej 500 KB |
| Wynik Lighthouse (mobilne) | 25-45 | 90-98 |
Podane zakresy odzwierciedlają typowe wyniki z audytów webvise; rzeczywiste rezultaty zależą od motywu, zestawu wtyczek, wagi zdjęć i skryptów zewnętrznych.
Matematyka konwersji dla Państwa sklepu
Warto przeliczyć to dla własnego sklepu.
Schemat jest prosty:
- Należy wziąć aktualny miesięczny przychód
- Oszacować obecny współczynnik konwersji (zamówienia podzielone przez sesje)
- Zastosować oczekiwaną poprawę wynikającą ze wzrostu prędkości
- Obliczyć wynikający z tego wzrost przychodu
Przykładowy scenariusz: przebudowa pod kątem wydajności, która podnosi konwersję z 1,5% do 2,1% w sklepie osiągającym 15 000 €/miesiąc przy tym samym ruchu, przekłada się na około 6 000 € dodatkowego przychodu miesięcznie przy AOV 100 €. Rzeczywiste wyniki zależą od punktu startowego.
Nawet bardziej zachowawcza poprawa może w wymierny sposób skompensować koszt przebudowy; czas zwrotu inwestycji zależy od wolumenu ruchu i AOV.
Kalkulacja sprawdza się na każdym poziomie przychodów. Sklep generujący 5 000 €/miesiąc, który zyska 0,5 punktu procentowego konwersji, uzyska dodatkowe 1 667 € miesięcznie. Sklep generujący 50 000 €/miesiąc przy tej samej poprawie zyska 16 667 € miesięcznie.
Co zmierzyć w pierwszej kolejności
Przed wprowadzeniem jakichkolwiek zmian należy ustalić punkt wyjścia. Cztery narzędzia wystarczą do kompleksowej oceny:
- Google PageSpeed Insights: po podaniu adresu URL strony produktu (nie tylko strony głównej) otrzymuje się wynik od 0 do 100 na urządzeniach mobilnych. Wynik poniżej 50 wymaga pilnej reakcji. Wynik poniżej 30 oznacza, że klienci aktywnie opuszczają sklep z powodu prędkości.
- Google Search Console, sekcja Core Web Vitals: pokazuje dane rzeczywistych użytkowników, nie warunki laboratoryjne. Czerwone adresy URL to realne, bieżące straty przychodów.
- Lighthouse (Chrome DevTools): uruchamiany w trybie incognito na stronie produktu. Należy sprawdzić element LCP: czy to główne zdjęcie produktu? Czy ma atrybut lazy-load? Nie powinno go mieć.
- Karta Network (Chrome DevTools): po posortowaniu żądań według rozmiaru widać duże nieskompresowane obrazy, skrypty blokujące renderowanie i żądania zewnętrzne wydłużające czas ładowania.
Szczególną uwagę należy zwrócić na element LCP. Jeśli główne zdjęcie produktu ma włączone leniwe ładowanie, co jest powszechne w sklepach WooCommerce opartych na gotowych motywach, sama ta zmiana, polegająca na usunięciu atrybutu lazy-load z pierwszego widocznego obrazu, może natychmiastowo poprawić LCP o 1-2 sekundy.
Szybkie usprawnienia przed pełną przebudową
Jeśli pełna przebudowa nie jest aktualnie planowana, poniższe działania mogą poprawić wydajność w ramach istniejącej konfiguracji:
- Kompresja obrazów i konwersja do WebP: zamiana zdjęć produktów na format WebP może zmniejszyć wagę obrazów o 40-60%. Narzędzia takie jak Imagify lub ShortPixel robią to automatycznie.
- Usunięcie nieużywanych wtyczek: audyt wtyczek jest niezbędny. Każda zainstalowana wtyczka, nawet dezaktywowana, generuje narzut. Należy usunąć wszystko, co nie jest aktywnie potrzebne.
- Włączenie cache'owania stron: WP Rocket lub W3 Total Cache ogranicza koszt dynamicznego generowania stron. Nie naprawia architektury, ale zmniejsza jej wpływ na ponowne wizyty.
- Migracja hostingu: hosting współdzielony narzuca twardy sufit wydajności. Przejście na zarządzany hosting WordPress (Kinsta, WP Engine, Cloudways) zazwyczaj dodaje 10-20 punktów w Lighthouse.
- Odkładanie nieistotnego JavaScript: większość motywów ładuje wszystkie skrypty na każdej stronie. Odroczenie skryptów niepotrzebnych przy pierwszym ładowaniu skraca czas blokowania renderowania.
Takie zmiany przedłużają żywotność sklepu i mogą przesunąć wynik z 35 do 55 punktów, ale nie zmieniają strukturalnego sufitu. Sklep WooCommerce z pełnym zestawem wtyczek, dynamicznym generowaniem stron i współdzieloną bazą danych nie osiągnie 85 punktów na urządzeniach mobilnych, bez względu na ilość pracy konfiguracyjnej.
Dla sklepów generujących znaczące miesięczne przychody są to działania opóźniające nieuniknione. Trwałą poprawę zapewnia jedynie przebudowa strukturalna w architekturze headless.
Kiedy przebudowa pod kątem wydajności jest finansowo uzasadniona
Praktyczna zasada: jeśli sklep generuje ponad 5 000 €/miesiąc, a wynik PageSpeed na urządzeniach mobilnych jest poniżej 60, przebudowa pod kątem wydajności zazwyczaj zwraca się w ciągu 6 miesięcy przy tym poziomie ruchu. To heurystyka, nie gwarancja.
Przy 10 000 €/miesiąc i typowej poprawie współczynnika konwersji o 0,4-0,6 punktu procentowego po przebudowie, miesięczny wzrost przychodu wynosi 400-600 €. Koszt przebudowy 3 000-5 000 € (szczegóły w artykule o kosztach) zwraca się w ciągu 6-10 miesięcy, bez uwzględnienia wzrostu widoczności organicznej dzięki poprawie Core Web Vitals.
Sklepy osiągające ponad 20 000 €/miesiąc ze słabymi wynikami wydajnościowymi co miesiąc tracą realną szansę na wyższe konwersje. Czas zwrotu inwestycji wynosi w takich przypadkach często poniżej 3 miesięcy.
Aby dokładnie poznać sytuację swojego sklepu, można pobrać bezpłatny raport zdrowia strony pod adresem webvise.io/wp-health-report. Raport analizuje Core Web Vitals, wskazuje problemy z największym wpływem na wydajność i daje klarowny obraz tego, co zmieni przebudowa. Rejestracja nie jest wymagana.