Wolny sklep WooCommerce - 7 najczęstszych przyczyn i ile kosztują Cię w sprzedaży

Klikasz w kategorię i czekasz. Klient też czeka, tylko krócej, bo po trzech sekundach wraca do wyników wyszukiwania i wchodzi do konkurencji. Ty widzisz wolno ładującą się stronę. W raportach widzisz spadek konwersji i nie łączysz jednego z drugim.

Hostingodawca mówi, że to wtyczki. Agencja mówi, że to hosting. Ktoś na forum radzi zmienić platformę. Każdy ma inną diagnozę, bo nikt nie zmierzył. Ten wpis jest po to, żeby zmierzyć: najpierw pokażę, jak w kilkadziesiąt minut zawęzić problem samodzielnie, potem przejdę przez siedem przyczyn od najczęstszej, a na końcu policzymy, ile ta zwłoka kosztuje i kiedy naprawdę potrzebujesz nowego sklepu, a kiedy to przesada.

Krótka odpowiedź (dla niecierpliwych)

Wolny WooCommerce prawie nigdy nie jest winą samego WooCommerce. W praktyce odpowiada za to jedna z siedmiu rzeczy: hosting, nieoptymalizowane obrazy, ciężki motyw z page builderem, nadmiar wtyczek, brak cache albo cache skonfigurowany źle, rozdęta baza danych i skrypty zewnętrzne. Kolejność ma znaczenie, bo część z nich naprawia się w kilka godzin, a część wymaga wymiany fundamentu.

Warto też od razu rozdzielić dwa problemy, które w rozmowach zlewają się w jeden: wolna strona dla klienta i wolny panel administracyjny. To zwykle inne przyczyny i inne naprawy. Ten wpis obejmuje oba.

Zanim zaczniesz zgadywać: 20 minut diagnostyki

Najgorsze, co możesz zrobić, to zadzwonić do wykonawcy z komunikatem "sklep działa wolno". Dostaniesz wtedy wycenę na wszystko, bo nikt nie wie, co jest zepsute. Trzy pomiary poniżej są darmowe i zajmują mniej niż pół godziny, a zmieniają rozmowę z licytacji w diagnozę.

Zmierz trzy różne adresy, nie tylko stronę główną. Wrzuć do PageSpeed Insights kolejno: stronę główną, kategorię z największą liczbą produktów i kartę produktu. Strona główna bywa najlepiej dopieszczona i najmniej reprezentatywna. Jeśli kategoria wypada dramatycznie gorzej niż strona główna, podejrzenie od razu pada na obrazy i zapytania do bazy danych.

Patrz na dane terenowe, nie tylko na wynik laboratoryjny. PageSpeed Insights pokazuje dwie rzeczy: symulację na wzorcowym urządzeniu i dane od realnych użytkowników twojej strony z ostatnich tygodni. To drugie jest prawdą o tym, co widzą twoi klienci na swoich telefonach i łączach. Wynik laboratoryjny bywa znacznie bardziej optymistyczny.

Zmierz osobno panel. Ile trwa otwarcie listy zamówień? A listy produktów? Jeśli front działa znośnie, a panel się wlecze, to niemal na pewno baza danych albo wtyczki, a nie moc serwera pod ruch klientów.

Patrząc na wyniki, skup się na trzech wskaźnikach, które Google zebrał pod nazwą Core Web Vitals: LCP mówi, kiedy pojawia się główna treść strony (dobry wynik to 2,5 sekundy lub mniej), INP mierzy, jak szybko strona reaguje na kliknięcie (dobry wynik to 200 milisekund lub mniej), a CLS pokazuje, czy układ nie skacze pod palcem w trakcie ładowania (dobry wynik to 0,1 lub mniej).

Jedno zastrzeżenie, zanim ruszysz dalej: wynik PageSpeed nie jest celem. Celem jest realny czas, w jakim klient dochodzi do zakupu. Sto punktów w sklepie, który nie sprzedaje, jest wartością zerową.

Przyczyna 1: hosting, który nie udźwignie sklepu

Sklep to nie blog. Zwykłą stronę można w całości podać z pamięci podręcznej, ale koszyk, konto klienta i checkout muszą się przeliczać na żywo, przy każdym wejściu, dla każdego użytkownika osobno. Dlatego moc procesora i pamięć serwera mają w WooCommerce realne znaczenie, którego nie widać przy zwykłej wizytówce.

Objawy są dość charakterystyczne: czas ładowania skacze w godzinach szczytu, panel działa wolniej po południu niż rano, import produktów albo eksport zamówień kończy się timeoutem.

Nie polecę ci konkretnego hostingu i nie zamierzam nikogo tu promować. Zamiast tego kryterium, które sprawdza się w praktyce: przy małym sklepie, kilkudziesięciu produktach i spokojnym ruchu dobry hosting współdzielony zwykle wystarcza. Przy rozbudowanym katalogu, ruchu z kampanii i realnym obciążeniu panelu przechodzi się na VPS albo serwer dedykowany, gdzie zasobów nie dzielisz z setką innych stron. Pytanie nie brzmi "który hosting jest najlepszy", tylko "czy mój obecny udźwignie to, czym mój sklep jest dzisiaj".

O co zapytać swojego obecnego hostingodawcę: jaka wersja PHP, jaki limit pamięci na proces, czy dyski to NVMe i czy dostępny jest cache obiektów, na przykład Redis. Cztery pytania, po których wiesz, czy stoisz na czymś sensownym.

I uczciwe zastrzeżenie: przeprowadzka na droższy hosting bywa plastrem na złamanie. Jeśli źródłem problemu jest sześćdziesiąt wtyczek, mocniejszy serwer tylko przesunie próg bólu o kilka miesięcy.

Przyczyna 2: obrazy prosto z aparatu

To statystycznie najczęstsza przyczyna w małych i średnich sklepach, a jednocześnie najtańsza w naprawie. Mechanizm jest prosty: zdjęcia produktowe idą do sklepu w oryginalnej rozdzielczości, po kilka megabajtów każde, a przeglądarka i tak wyświetla je w rozmiarze kilkuset pikseli. Przy dwudziestu czterech produktach na stronie kategorii robi się z tego wynik, w który trudno uwierzyć, dopóki się go nie zmierzy.

Widziałem sklep, w którym strona kategorii ważyła około 20 MB, a lista produktów blisko 35 MB. Prawie w całości zdjęcia. Na telefonie w zasięgu LTE to nie jest wolne ładowanie, to jest ekran, na który klient patrzy tak długo, że zdąży zmienić zdanie o zakupie.

Co to naprawia: właściwe rozmiary miniatur generowane przez sklep, nowoczesne formaty WebP lub AVIF, lazy loading dla wszystkiego poniżej pierwszego ekranu i priorytetowe ładowanie głównego obrazu. To ostatnie jest o tyle ważne, że wtyczki optymalizacyjne nagminnie nakładają lazy loading również na obraz LCP, czyli ten, na który Google czeka, żeby uznać stronę za załadowaną. Efekt bywa odwrotny od zamierzonego.

To jedyna sekcja tego wpisu, którą możesz wdrożyć sam, w jedno popołudnie, bez niczyjej pomocy. Zacznij od niej.

Przyczyna 3: motyw z page builderem

Uniwersalny motyw musi obsłużyć każdy scenariusz, jaki jego autor sobie wyobraził, więc ładuje kod na wypadek funkcji, których twój sklep nigdy nie użyje. Page builder dokłada do tego własny CSS i JavaScript na każdej podstronie, niezależnie od tego, czy dana podstrona faktycznie z niego korzysta.

Objaw jest charakterystyczny: strona wygląda na załadowaną, ale nie reaguje na kliknięcia. W pomiarach zobaczysz wysoki Total Blocking Time i słaby INP. Przeglądarka jest zajęta przetwarzaniem skryptów i nie ma czasu obsłużyć palca klienta.

Tego nie da się naprawić wtyczką optymalizacyjną. Można to co najwyżej zamaskować, a maskowanie ma krótkie nogi: przy pierwszej większej aktualizacji wraca punkt wyjścia.

Jak duża jest różnica, widać na twardych liczbach. Sklep Leaf No Trace przebudowałem na dedykowanym motywie, bez gotowego szablonu i bez page buildera. Wynik PageSpeed na mobile wzrósł z 75 na 100 punktów, a Total Blocking Time spadł ze 100 milisekund do zera. To nie jest efekt magii ani jednej wtyczki, tylko tego, że przeglądarka dostaje do przetworzenia wyłącznie kod, który jest do czegoś potrzebny.

Przyczyna 4: nadmiar wtyczek

Nie chodzi o samą liczbę, tylko o to, ile z nich wykonuje kod na każdej podstronie. Wtyczka do formularza kontaktowego, która ładuje swoje skrypty na karcie produktu, to czysta strata. Wtyczka do galerii, która dokłada bibliotekę na stronie koszyka, też.

Typowi podejrzani: rozbudowane dodatki do sliderów i galerii, wielofunkcyjne pakiety "wszystko w jednym", dwie wtyczki robiące dokładnie to samo (klasyka: dwie wtyczki SEO albo dwa systemy cache jednocześnie) oraz wtyczki porzucone przez autorów, które od trzech lat nie dostały aktualizacji.

W sklepach, które przejmuję, zastaję zwykle około dwudziestu czterech aktywnych wtyczek. Po przebudowie zostaje ich dziewięć, może dziesięć, zależnie od tego, co sklep faktycznie ma robić. Celem nie jest niska liczba dla samej liczby. Celem jest to, żeby każda pozostała wtyczka miała powód, dla którego tam jest.

Część funkcji da się zastąpić kilkudziesięcioma liniami kodu w motywie. Bez wtyczki, bez jej aktualizacji przez najbliższe lata i bez ryzyka, że autor porzuci projekt. Czasem idzie się dalej: w projekcie wizualnego kreatora zamówień cała logika konfiguracji produktu, którą normalnie składa się z kilku wtyczek, jest jednym dedykowanym narzędziem.

Ważne, jak się to robi. Metoda "wyłączmy wszystko po kolei i zobaczmy" na żywym sklepie to proszenie się o utracone zamówienia. Audyt wtyczek robi się na środowisku testowym, tak jak każdą inną większą zmianę. Opisuję to szerzej na stronie procesu współpracy.

Przyczyna 5: brak cache albo cache skonfigurowany źle

Cache to gotowa wersja strony, podawana klientowi bez przeliczania jej od nowa. W blogu to sprawa prosta. W sklepie zaczyna być delikatna, bo koszyk, checkout i konto klienta muszą być z cache wyłączone. Inaczej klient zobaczy zawartość cudzego koszyka, a to nie jest błąd wydajności, tylko incydent bezpieczeństwa.

Dlatego samo "wrzucenie wtyczki cache" w sklepie bywa groźniejsze niż jej brak. Objawy źle skonfigurowanego cache znasz, jeśli je masz: klient dzwoni, że cena w koszyku jest inna niż na stronie produktu, albo że kupił coś, czego nie ma na stanie, bo stan magazynowy nie odświeżył się od wczoraj.

Trzy warstwy, o które warto zapytać wykonawcę albo hostingodawcę: cache stron dla podstron, które można podać gotowe, cache obiektów (Redis lub Memcached) dla powtarzalnych zapytań do bazy oraz CDN dla obrazów i plików statycznych. Każda z nich rozwiązuje inny problem i żadna nie zastępuje pozostałych.

Przyczyna 6: baza danych, która puchnie

Baza sklepu rośnie sama, nawet jeśli nic z nią nie robisz. Rewizje wpisów i produktów, wygasłe transienty, logi wtyczek, dane pozostawione przez wtyczki odinstalowane dwa lata temu, sesje, porzucone koszyki, rozdęta tabela opcji ładowana przy każdym żądaniu.

Objaw jest inny niż przy pozostałych przyczynach i dlatego łatwo go pomylić: front działa znośnie, a panel administracyjny się wlecze. Lista zamówień otwiera się kilkanaście sekund, wyszukiwanie zamówienia trwa wieczność, filtrowanie produktów wywala timeout. To niemal zawsze baza, nie serwer.

Osobna sprawa dotyczy tego, jak WooCommerce trzyma zamówienia. Od wersji 8.2 domyślnym rozwiązaniem dla nowych instalacji jest High-Performance Order Storage, czyli dedykowane tabele na zamówienia zamiast trzymania ich razem z resztą treści. Według oficjalnej zapowiedzi WooCommerce przekłada się to na kilkukrotnie szybsze tworzenie zamówień i wyraźnie szybsze ich wyszukiwanie. Starsze sklepy często wciąż działają na dawnym modelu i przy dużej liczbie zamówień to jest różnica, którą czuć codziennie przy obsłudze.

Jedno ostrzeżenie: czyszczenie bazy robi się z kopią zapasową i ze świadomością, co się usuwa. Nie kliknięciem "optymalizuj" w losowej wtyczce, której autor też nie do końca wie, co tam jest.

Przyczyna 7: skrypty zewnętrzne, o których zapomniałeś

Piksele reklamowe, czat, mapa dojazdu, widget z opiniami, narzędzie do testów A/B, heatmapy. Każdy z nich dokłada zapytania do cudzych serwerów, na których wydajność nie masz żadnego wpływu. Twój sklep czeka, aż odpowie serwer firmy, z którą skończyłeś współpracę pół roku temu.

Bardzo częsty przypadek: sklep ma dwa systemy analityki, bo drugi wdrażała agencja, i trzy piksele po kampaniach, których nikt nie wyłączył. Nikt tego nie liczy, bo każdy z osobna wygląda niewinnie.

Co robić: inwentaryzacja wszystkiego, co ładuje się z zewnątrz, odroczenie tego, co nie jest potrzebne od pierwszej sekundy, i usunięcie tego, z czego faktycznie nikt nie korzysta. To jedyna przyczyna z tej listy, którą właściciel sklepu wygenerował sam i którą sam może cofnąć w jedno popołudnie.

Ile kosztuje Cię jedna sekunda

Tu robi się konkretnie, bo dopóki mówimy o punktach PageSpeed, rozmawiamy o abstrakcji. Zamieńmy ją na pieniądze.

Po polskim internecie krąży kilka liczb na ten temat i większość z nich podaje się bez źródła. Dlatego oprę się na jednym badaniu, które ma opisaną metodologię: Milliseconds Make Millions, analiza Deloitte Digital przeprowadzona na danych mobilnych 37 marek z branż retail, travel, luxury i lead generation przez cztery tygodnie. Wynik dla handlu detalicznego: poprawa czasu ładowania o zaledwie 0,1 sekundy wiązała się ze wzrostem konwersji o 8,4 procent i średniej wartości koszyka o 9,2 procent.

Zwróć uwagę na skalę. Nie mówimy o sekundzie, tylko o jednej dziesiątej sekundy. Jeśli twój sklep ładuje się dwie sekundy dłużej, niż powinien, jesteś dwadzieścia takich kroków od stawki, o której mowa w badaniu.

Przelicz to na swoje liczby, w trzech krokach:

1. Weź swój średni miesięczny przychód ze sklepu.
2. Policz, ile wynosi 8 procent tej kwoty.
3. Pomnóż przez dwanaście.

Przy sklepie robiącym 80 tysięcy złotych miesięcznie mówimy o kwocie rzędu 76 tysięcy złotych rocznie. To szacunek kierunkowy, nie obietnica, i traktuj go dokładnie tak: jako rząd wielkości, który pokazuje, czy w ogóle warto się tym zajmować.

Jest jeszcze druga oś kosztu, o której pisze się rzadziej. Wolny sklep podnosi koszt kampanii płatnych, bo za ten sam budżet kupujesz tyle samo kliknięć, ale mniej sprzedaży. Płacisz za ruch, który odbija się od ekranu ładowania. W kampaniach mobilnych, gdzie jest dziś większość ruchu, ta różnica jest najbardziej dotkliwa.

I uczciwe zastrzeżenie na koniec tej sekcji: szybkość jest warunkiem koniecznym, nie wystarczającym. Szybki sklep ze złą kartą produktu, niejasną dostawą i checkoutem na pięć kroków dalej nie sprzeda. Optymalizacja wydajności usuwa przeszkodę, nie tworzy popytu.

Optymalizacja czy nowy sklep? Jak podjąć decyzję

To pytanie, z którym trafia do mnie większość osób szukających frazy "wolny WooCommerce". Odpowiedź nie brzmi automatycznie "przebuduj".

Wystarczy optymalizacja, jeśli motyw jest lekki i przyzwoicie napisany, problem sprowadza się do obrazów, cache, hostingu i kilku wtyczek, a poza szybkością nie masz do sklepu innych zastrzeżeń. To scenariusz na godziny pracy, nie na miesiące.

Potrzebna jest przebudowa, jeśli fundamentem jest ciężki motyw z page builderem, funkcje sklepu trzymają się na łańcuchu wtyczek, każda aktualizacja psuje układ strony, a twoja lista życzeń i tak wykracza poza samą szybkość. Wtedy optymalizacja jest wydatkiem, który za rok trzeba ponieść jeszcze raz. Warto przy tym pamiętać, że przebudowa bywa dźwignią, a nie tylko kosztem: w sklepie Swiss Smile Beauty według danych klienta przychody wzrosły 6-krotnie w ciągu pół roku po wdrożeniu. Na taki wynik pracuje więcej czynników niż sama szybkość, ale sprawny sklep pozwolił ten wzrost obsłużyć. Jak przeprowadzić taką zmianę bez utraty pozycji i danych, opisuję we wpisie o przebudowie sklepu bez utraty SEO, a o tym, z czego składa się cena nowego sklepu, piszę w ile kosztuje sklep WooCommerce.

Między tymi opcjami jest trzecia, o której mało kto mówi wprost: audyt wydajności. Płatna diagnoza, która kończy się listą przyczyn ustawionych według wpływu na wynik, wraz z wyceną naprawy każdej z nich osobno. Sens jest taki, że wiesz, co kupujesz, zanim to kupisz, i możesz zdecydować, że robisz tylko trzy pierwsze pozycje z listy.

Ile to kosztuje: audyt to około 1500 złotych i jest to kwota stała, bo zakres pracy jest z góry znany. Naprawa zaczyna się od 500 złotych i zależy od tego, co audyt wykaże. Nie podaję górnej granicy, bo różnica między "obrazy do przerobienia" a "motyw do wymiany" to różnica między jednym dniem a projektem. Audyt i naprawa rozliczane są osobno, a to, czy naprawę zlecisz mnie, jest twoją decyzją. Raport jest twój niezależnie od niej.

Jeśli okaże się, że twój sklep da się naprawić optymalizacją, powiem to wprost, zamiast wyceniać nowy sklep. To nie jest uprzejmość, tylko rachunek: sklep naprawiony za ułamek ceny przebudowy wraca do mnie za dwa lata z większym projektem.

Umów bezpłatną konsultację - trzydzieści minut rozmowy o twoim sklepie, po której wiesz, w którym z trzech scenariuszy jesteś.

Czego nie robić

Zanim zaczniesz naprawiać, pięć rzeczy, które w moim doświadczeniu pogarszają sytuację częściej, niż pomagają:

• Trzy wtyczki optymalizacyjne naraz. Konflikty, podwójna minifikacja i checkout, który przestaje działać na jednej metodzie płatności. Jedna wtyczka, dobrze skonfigurowana, robi więcej niż trzy walczące ze sobą.
• Agresywne łączenie i odraczanie JavaScriptu bez testu ścieżki zakupowej. Najczęstszy skutek: koszyk albo wybór dostawy przestaje działać, a nikt tego nie zauważa przez tydzień, bo strona ładuje się przecież szybciej.
• Optymalizowanie pod wynik w narzędziu zamiast pod klienta. Można wyciągnąć wysoki wynik w teście i mieć sklep, który realnym użytkownikom nadal ładuje się wolno.
• Zmiana platformy jako pierwsza reakcja. Migracja na inny system nie usunie czterdziestu wtyczek ani zdjęć po 5 MB. Przeniesie je gdzie indziej, przy okazji kosztując cię pozycje w Google. Jeśli zastanawiasz się nad tym krokiem z powodu wydajności, przeczytaj najpierw czy WordPress ma jeszcze sens.
• Wprowadzanie zmian na produkcji w sezonie. Optymalizację robi się na środowisku testowym i wdraża w spokojnym tygodniu, nie w listopadzie.

Podsumowanie

Wolny sklep WooCommerce prawie zawsze da się sprowadzić do jednej lub dwóch z siedmiu przyczyn opisanych wyżej, a wskazanie ich zajmuje kilkadziesiąt minut, nie tygodnie. Część naprawia się tanio i od razu: obrazy, cache, skrypty zewnętrzne. Część dotyczy fundamentu i wtedy uczciwa odpowiedź brzmi "to nie jest optymalizacja, to jest przebudowa".

Zacznij od pomiaru, nie od zakupu. A jeśli chcesz przejść przez wyniki z kimś, kto robi to na co dzień, umów bezpłatną konsultację - ustalimy, w którym scenariuszu jest twój sklep i ile realnie kosztuje jego naprawa.