Rozwój i optymalizacja WooCommerce. Fundament, nie wtyczki.
Rozwijam i optymalizuję działające sklepy WooCommerce w trzech obszarach: przyspieszam wolne (efekt mierzę w Core Web Vitals przed i po), naprawiam awarie, gdy sklep nie działa, i rozbudowuję sprzedaż o funkcje B2B. Wchodzę w kod, cache i bazę danych, zamiast doklejać kolejną wtyczkę. 8 lat na produkcji, konkretna wycena na piśmie.
Jedna strona, trzy problemy, jedne ręce.
Przyspieszanie
Wolny sklep traci koszyki na telefonie i przepłaca za reklamę. Wchodzę w kod, cache, bazę danych i obrazy - efekt w Core Web Vitals mierzę przed i po, nie „na oko".
Awaryjna naprawa
Sklep nie działa: biały ekran, checkout nie przyjmuje płatności, ślady włamania, konflikt po aktualizacji. Wchodzę w logi, ustalam przyczynę i naprawiam - bez zgadywania.
Rozbudowa o funkcje B2B
WooCommerce da się rozbudować pod sprzedaż firmową: cenniki per grupa klientów, ceny widoczne po zalogowaniu, minimalne ilości zamówień, limity kredytowe. Rozbudowuję istniejący sklep, nie stawiam nowego obok.
Dlaczego sklep WooCommerce wolno działa?
Zanim kupisz kolejną wtyczkę „do przyspieszania", sprawdź, co naprawdę dławi sklepy Woo. Optymalizacja WooCommerce zaczyna się od diagnozy, nie od dokładania kolejnych dodatków - a w diagnozach niemal zawsze wracają te same wąskie gardła:
Wolny TTFB i brak cache z głową
Na tanim hostingu sklep czeka ponad sekundę, zanim serwer w ogóle odpowie. A „włączyć cache" w WooCommerce nie wystarczy - koszyk, checkout i „Moje konto" muszą być z niego wyłączone, inaczej klienci zobaczą cudze koszyki. Dlatego wiele sklepów trzyma cache wyłączony w ogóle - i pełznie.
Cart fragments na każdej podstronie
Mechanizm odświeżający minikoszyk odpytuje serwer na każdej podstronie - także na blogu, gdzie nikt nic nie kupuje. Potrafi dokładać setki milisekund do każdego wejścia. Da się go ładować warunkowo, tylko tam, gdzie jest potrzebny.
Rozdęta baza danych
WooCommerce odkłada w bazie dane tymczasowe (transients) i zadania w tle (Action Scheduler). Gdy nikt tego nie czyści, tabele puchną do setek tysięcy wierszy i sklep zwalnia „sam z siebie", choć nic się w nim nie zmieniło.
Ciężki motyw i nadmiar wtyczek
Uniwersalny motyw „do wszystkiego" i kilkadziesiąt aktywnych wtyczek dokładają swoje skrypty, style i zapytania na każdej podstronie - nawet tam, gdzie nic nie robią. Sklep przegrywa Core Web Vitals na starcie.
Nieprzeskalowane obrazy
Zdjęcie produktu w 4000 px wyświetlane w kafelku 300 px to najczęstszy pojedynczy zabójca LCP. Konwersja do WebP/AVIF, poprawne wymiary i lazy loading potrafią ściąć wagę najcięższego elementu strony o rząd wielkości.
Co z tym robię: page cache z wyjątkami dla koszyka i checkoutu, Redis Object Cache i OPcache, lekki front (WebP/AVIF, lazy loading, warunkowe ładowanie skryptów wtyczek), porządek w bazie (transients, Action Scheduler, HPOS). Najprostszy test, czy Twój sklep jest za wolny: PageSpeed Insights na mobile - jeśli LCP przekracza 2,5 s, tracisz koszyki i przepłacasz za reklamę.
Sklep nie działa? Najpierw diagnoza, potem naprawa.
Zgłoszenie trafia prosto do mnie i od razu biorę je na warsztat. Naprawa WooCommerce zaczyna się u mnie od logów i kodu: ustalam realną przyczynę i usuwam ją, zamiast gasić objawy kolejną wtyczką. Najczęstsze zgłoszenia:
Biały ekran / błąd krytyczny
Fatal error po aktualizacji motywu albo wtyczki. Często nie działa nawet panel administracyjny - trzeba wejść przez FTP albo bezpośrednio do bazy.
Checkout i płatności nie działają
Zamówienia się nie zapisują, płatność wraca błędem albo klient w ogóle nie widzi przycisku „Kup". Najdroższa awaria - boli wprost w przychodzie.
Sklep zhakowany
Obce skrypty, dziwne przekierowania, ostrzeżenie w Google albo mail od hostingu o złośliwym kodzie. Trzeba wyczyścić, zamknąć furtkę i sprawdzić, co jeszcze ucierpiało.
Konflikt po aktualizacji
Aktualizacja rdzenia WordPressa, WooCommerce albo wtyczki psuje coś, co wcześniej działało. Motyw się rozjeżdża, funkcja znika, sklep zaczyna rzucać błędami.
Sklep pada pod ruchem
Błędy 500 albo 504 w najgorszym możliwym momencie - przy kampanii albo wyprzedaży. Serwer, baza albo zapytania nie nadążają za ruchem.
Proces jest zawsze ten sam: diagnoza w logach i bazie, kopia zapasowa przed każdą ingerencją, naprawa z testem checkoutu i płatności, a na koniec zabezpieczenie, żeby ta sama awaria się nie powtórzyła. Jeśli chcesz spać spokojnie na stałe, po naprawie proponuję stałe wsparcie z monitoringiem.
Rozbudowa o sprzedaż B2B - na istniejącym sklepie.
WooCommerce z domyślnym ustawieniem to jeden cennik dla wszystkich i płatność z góry. Sprzedaż firmowa wymaga czterech dodatkowych warstw - wdrażam je na Twoim sklepie, bez budowy platformy od zera:
Role klientów i cenniki grupowe
Ceny zależą od przypisanej roli albo grupy: hurtownik, dystrybutor, klient detaliczny. Ten sam sklep, inne widełki dla każdego segmentu - bez utrzymywania dwóch osobnych sklepów.
Ceny widoczne po zalogowaniu
Dopóki klient się nie zaloguje, nie widzi cen ani przycisku „Dodaj do koszyka" - tylko formularz o dostęp. Standard w B2B, żeby cennik nie leżał jawnie w Google dla konkurencji.
Minimalne ilości zamówień (MOQ)
Zamówienie od określonej liczby sztuk albo pełnego opakowania zbiorczego - wymuszone na poziomie produktu lub kategorii, nie do obejścia w koszyku.
Limity kredytowe i odroczona płatność
Stali klienci kupują na fakturę z terminem płatności i przypisanym limitem kredytowym, zamiast płacić z góry przy każdym zamówieniu jak w zwykłym Woo.
Uczciwie o dowodach: funkcje B2B na WooCommerce to kompetencja zbudowana na 30+ wdrożeniach Woo od roku 2018 i na backendzie o skali operatorów iGaming - moduły finansowe i panele o wysokich wymaganiach bezpieczeństwa (praca pod NDA). Pokazuję to jako background, nie jako gotowy katalog case'ów - bez zmyślonych realizacji.
Zanim się odezwiesz - sprawdź sam.
Trzy teksty, dzięki którym sam zdiagnozujesz, na czym stoisz:
Realna realizacja, realne liczby.
Złota-Faza - audyt wydajności podbity z 38 na 100, Speed Index z 4,5 s do 0,3 s. To strona firmowa, nie sklep, ale mechanika była ta sama, na której pracuję w sklepach: ciężkie obrazy, balast motywu i front dławiący Core Web Vitals. Większość interwencji ratunkowych idzie pod NDA - klient chce ciszy, nie rozgłosu.
„Krystian raczej mało gadał, więcej robił. Wycenił, dał termin, dowiózł. Strona stoi, Google ją widzi, klienci trafiają." Michał Wacławik · Złota-Faza · Instalacje Elektryczne
Zanim napiszesz.
Wycena jest indywidualna, na piśmie - bez cennika „od X zł". Zakres dobieram do problemu: inaczej wygląda konflikt jednej wtyczki, a inaczej czyszczenie zhakowanej bazy. Przyspieszenie istniejącego sklepu to zwykle ułamek ceny budowy sklepu od nowa, bo nie ruszam całej struktury, tylko wąskie gardła.
Najprościej: PageSpeed Insights na mobile - jeśli LCP przekracza 2,5 s, a wynik jest w czerwieni, tracisz koszyki i płacisz drożej za reklamę. Diagnozę robię waterfallem i Query Monitorem, żeby znaleźć realne wąskie gardło, a nie objaw.
Od diagnozy: sprawdzam log błędów serwera, log WordPressa i WooCommerce, historię ostatnich zmian (aktualizacje, nowe wtyczki) oraz bazę danych. W większości przypadków przyczyna jest widoczna, zanim zacznę cokolwiek naprawiać - nie zgaduję metodą prób i błędów. Przed każdą ingerencją robię kopię zapasową.
Zwykle nie - pracuję na kopii stagingowej albo naprawiam usterkę bez zamykania sklepu na klientów. Krótki tryb konserwacji zdarza się tylko przy poważniejszych przypadkach (czyszczenie po włamaniu, naprawa bazy) i zawsze uprzedzam o tym wprost, zanim to zrobię.
Tak - to najczęstszy scenariusz. Nie budujemy nowej platformy, tylko rozbudowujemy istniejący sklep o role klientów, cenniki grupowe, ukryte ceny, MOQ i limity kredytowe. Produkty, zamówienia i klienci zostają na miejscu, a klient detaliczny i firmowy kupują w tym samym sklepie.
Sklep z czasem zwalnia z powrotem: aktualizacje, nowe wtyczki, rosnąca baza. W cenie masz 30 dni opieki po wdrożeniu, a na dłużej - stały support z monitoringiem, który pilnuje wydajności, zanim znowu zrobi się czerwono.
Sklep zwalnia albo się sypie?
Opisz projekt w kilku zdaniach - wracam osobiście z zakresem, konkretną kwotą i terminem.