Klientki uciekały po trzech sekundach. Sklep tracił 47 procent obrotu na ładowaniu strony

Diagnoza — czemu sklep ładuje się 9 sekund

Pierwsza wizyta zdalna (sklep jest w Bytomiu, my w Katowicach — wszystko da się zdiagnozować przez TeamViewer). Pani J. pokazuje swój sklep, otwarty w 2023. Strona główna ładuje się i ładuje. Patrzymy z boku — minęło już 7 sekund, a nadal puste tło z fragmentem nagłówka.

Pomiar Google PageSpeed Insights. Wyniki na mobile:

• Performance: 22 ze 100 (czerwony)
• First Contentful Paint: 4,8 sekundy
• Largest Contentful Paint: 9,4 sekundy
• Total Blocking Time: 1 200 ms
• Cumulative Layout Shift: 0,42 (bardzo wysoki, strona „skacze” przy ładowaniu)

Na desktopie nieco lepiej — performance 41, LCP 5,6 sekundy. Ale 70 procent ruchu w sklepie z artykułami dla niemowląt to mobile (mamy z telefonu w wózku albo na kanapie). Czyli mobile to nasz front problemu.

Drugi pomiar — Hotjar. Patrzymy na heatmap i nagrania sesji użytkowników. Z 100 wejść w sklep:

• 74 osoby zamknęły kartę zanim strona w pełni się załadowała (bounce rate 76%)
• 14 osób przeglądnęło 1–2 strony i poszły
• 10 osób dodało coś do koszyka
• 6 osób kupiło (konwersja 0,6%)

Branża e-commerce ma średnią konwersję 1,2–2 procent. 0,6 to słabo, ale nie katastrofa — katastrofą jest bounce 76 procent. Ten bounce to wprost konsekwencja czasu ładowania.

Cztery decyzje techniczne na cztery dni

Po przeanalizowaniu sklepu (jakie wtyczki, jaki motyw, jaka baza danych, jaki hosting) przedstawiamy pani J. cztery główne kierunki:

• Migracja na hosting LiteSpeed. Aktualny hosting to dhosting Eco (taryfa 15 zł/mc). Współdzielony Apache, mało zasobów, brak własnego cache. Migracja na dhosting Premium LiteSpeed (45 zł/mc) — różnica w wydajności jest jak z BMW na Skodę z 1995.
• Pełna konfiguracja plugin LiteSpeed Cache. Sam motor LiteSpeed na hostingu to dopiero połowa sukcesu — trzeba jeszcze skonfigurować plugin, który robi 90 procent optymalizacji.
• Optymalizacja obrazków — WebP plus lazy loading. W sklepie pani J. każdy produkt ma 4–6 zdjęć, średnio 280 KB. To są pliki JPG zoptymalizowane na siłę, ale wciąż za duże. WebP zmniejsza rozmiar o 60–70 procent przy tej samej jakości wizualnej.
• Deduplikacja katalogu SKU. Sklep ma 2 800 produktów. Sprawdzamy — 860 z nich to duplikaty wariantów (różne kolory tej samej śpioszki opublikowane jako osobne produkty zamiast wariantów). To obciąża bazę danych i powoduje, że Google ciężko interpretuje katalog.

Migracja na hosting LiteSpeed

Dzień 1 — sobota. Migracja sklepu z jednego konta hostingu na drugie. Cała operacja na stage, sklep produkcyjny pracuje normalnie. Klonowanie WordPress, baza danych 348 MB, wszystkie zdjęcia produktów (4,8 GB). Konfiguracja PHP 8.3 i MariaDB 10.6 na nowym serwerze. Test sklepu na tymczasowej domenie stage.[domena-sklepu].

Dzień 2 — niedziela rano. Migracja DNS. Krytyczne 4 godziny — propagacja DNS w Polsce trwa zazwyczaj 1–3 godziny. Sklep w trakcie tych 4 godzin może działać niestabilnie (niektórzy klienci widzą stary, niektórzy nowy). Wybieramy niedzielę rano 7:00, bo to godziny najniższego ruchu (z heatmap widzimy że e-commerce ma 5–10 odwiedzin/h o tej porze). O 11:00 propagacja jest pełna, wszyscy widzą nowy serwer.

WebP, lazy loading, Critical CSS — w praktyce

Dzień 2 popołudnie i dzień 3 — pełna konfiguracja LiteSpeed Cache plus WebP. To są szczegóły techniczne, ale je wymieniam, żebyś jako klient wiedział co konkretnie kosztuje 4 990 zł, gdy ci ktoś oferuje optymalizację sklepu.

• LiteSpeed Page Cache — włączony dla wszystkich logged-out użytkowników. Wyłączony dla logged-in (właściciel, magazynier). TTL 12 godzin dla stron produktów, 1 godzina dla strony głównej, brak cache dla koszyka i checkout.
• Image Optimization — masowa konwersja wszystkich JPG i PNG do WebP. 3 200 zdjęć produktów przekonwertowanych w ciągu 4 godzin. Z 4,8 GB zdjęć zostało 1,4 GB. Plus lazy loading — zdjęcia poniżej fold ładują się tylko gdy klient do nich doscrolluje.
• Critical CSS — wstrzykiwany inline w pierwsze 2 KB pierwszego załadowania. Cała reszta CSS ładowana asynchronicznie. To rozwiązuje problem FCP (First Contentful Paint) — strona pokazuje się natychmiast, nawet jeśli nie jest jeszcze w pełni gotowa.
• JS Defer — wszystkie skrypty JavaScript ładowane z atrybutem defer, czyli nie blokują renderowania.
• Database cleanup — usuwamy 6 nieużywanych pluginów, czyszczenie post revisions (z 12 400 wersji do 2 wersji per post), usunięcie spam komentarzy. Baza zmniejsza się z 348 MB do 78 MB.
• Cloudflare Free — dodanie CDN z page rules. Globalna sieć dostarcza zdjęcia z najbliższego serwera. Dla klientek z Wrocławia czy Gdańska zdjęcie nie idzie z Warszawy (hosting) tylko z Wrocławia (Cloudflare).

2800 do 1940 SKU — deduplikacja katalogu

Dzień 4 — najmniej technika, najwięcej rozmowy z panią J.. Sprawdzamy katalog. Przykład: śpioszka „Malinowa” w pięciu rozmiarach (50, 56, 62, 68, 74) była opublikowana jako 5 osobnych produktów. To 4 duplikaty (powinien być 1 produkt z 5 wariantami rozmiaru).

Pani J. zrobiła to świadomie, na początku gdy uczyła się WooCommerce, bo nie chciała komplikować pierwszych wdrożeń. Po 18 miesiącach uzbierało się 860 takich duplikatów. Konsekwencje:

• Baza danych większa o 31 procent (każdy produkt to oddzielny rekord)
• Google traktował to jako „cienki content” — 5 stron o tym samym produkcie różniących się tylko rozmiarem to dla algorytmu Pandy słabej jakości
• Klientki musiały klikać 5 razy żeby przejść między rozmiarami, zamiast użyć dropdownu

Konsolidacja zajmuje 6 godzin. Skrypt PHP łączy duplikaty w warianty, przenosi zdjęcia, łączy historię zamówień. 2 800 produktów staje się 1 940 unikalnych produktów. Każdy ma teraz dropdown z rozmiarami zamiast osobnej karty.

Sześć tygodni później — wzrost o 47 procent

Po wdrożeniu czekamy 6 tygodni i robimy pomiary. Wyniki:

• PageSpeed Mobile: z 22 na 92. PageSpeed Desktop: z 41 na 96.
• Czas ładowania (LCP): z 9,4 sekundy na 1,4 sekundy. Spadek o 85 procent.
• Bounce rate: z 76 procent na 41 procent. Klientki nie uciekają.
• Konwersja: z 0,6 procent na 1,7 procent. Każdy 60 klient kupuje zamiast co 170.
• Sprzedaż miesięczna: z 21 000 zł na 30 800 zł. Wzrost o 47 procent w pierwszym pełnym miesiącu po wdrożeniu.
• Hosting: koszt wzrósł z 15 zł na 45 zł/mc (30 zł różnicy), ale jako bonus — baza danych zmniejszona o 78 procent, więc backupy są szybsze i tańsze.

Sklep WooCommerce nie jest sam w sobie wolny. Wolne jest 90 procent sklepów na shared hostingu z domyślną konfiguracją WordPressa. To nie wina platformy — to wina braku optymalizacji. Sklepy które idą na LiteSpeed plus poprawnie skonfigurowany cache plus WebP plus deduplikacja katalogu — działają tak samo szybko jak Allegro czy Zalando. Mała firma może mieć infrastrukturę dużej firmy za 45 zł/miesiąc.

W GZM obsługujemy aktualnie 7 sklepów WooCommerce — od pani J. z artykułami dziecięcymi przez sklep z drogeriami i hurtownię tekstyliów po sklep z elektroniką samochodową w Mysłowicach. Optymalizacja PageSpeed to nasza specjalność i najczęstszy projekt z którego zaczynają współpracę klienci e-commerce. Średni efekt: x2 do x3 konwersji w 6–12 tygodni.