WooCommerce we Frampolu i okolicach: kiedy ma sens, a kiedy lepiej zostać na PrestaShop

Decyzję podejmuje się przed wyborem szablonu. W praktyce pytanie nie brzmi „co jest lepsze”, tylko „ile będzie kosztować utrzymanie tego wyboru przez trzy lata”.

Trzy profile, w których WooCommerce wygrywa:

• Sklep do ~500 SKU — jeden magazyn, jedna strefa wysyłki, prosta struktura kategorii. WooCommerce plus 6–10 wtyczek (płatności, kurier, faktury, RODO) obsłuży to bez dotykania rdzenia.
• Firma usługowa z kilkoma produktami (5–30 pozycji): montaż, druk, wypożyczalnia. Sklep jest dodatkiem do strony firmowej — trzymanie dwóch systemów to podwójny hosting i podwójne aktualizacje.
• B2B z cennikami po zalogowaniu: rola „hurtownik”, ukryte ceny dla gości, minimalna wartość zamówienia, odroczone płatności. W WooCommerce robią to wtyczki do ról i cen dynamicznych, bez pisania logiki od zera.

Dwa profile, w których PrestaShop bywa lepszy:

• Katalog 5000+ SKU z wariantami — masowa edycja cen, kombinacje i import są w rdzeniu. W WooCommerce warianty i meta-dane potrafią stać się wąskim gardłem bazy.
• Zaawansowana logika cenowa i grupy klientów — kilkanaście grup z rabatami kaskadowymi, ceny zależne od ilości, regionu i kontrahenta. Wtedy zwykle taniej zostać na PrestaShop niż przekładać to na kilka wtyczek WooCommerce. Jeśli rozważasz ten kierunek, opiszemy go osobno w materiale o wdrożeniach i migracjach PrestaShop Frampol: organizacja.

Kontekst lokalny. Klienci z Biłgoraja, Zamościa, Janowa Lubelskiego i Szczebrzeszyna kupują inaczej niż klient z Warszawy: częściej wybierają pobranie i punkt odbioru niż przedpłatę online. W praktyce oznacza to włączone pobranie z limitem kwotowym, moduł punktów odbioru i odbiór osobisty jako osobną metodę dostawy — nie jako opcję w strefie wysyłki. Przy pobraniu prowizja operatora jest wyższa, więc warto policzyć marżę na koszyku 80–150 zł, zanim uznamy ten kanał za oczywisty.

Wydajność na tym samym VPS. Przy identycznym serwerze i katalogu 500–1500 SKU oba systemy z włączonym cache stron dają zbliżony czas odpowiedzi na stronach kategorii. Różnice pojawiają się w miejscach, których nie da się cache’ować: koszyk, checkout, filtrowanie po wariantach. PrestaShop z cache’em Smarty i APC lepiej znosi katalogi 5000+ SKU, WooCommerce z Redis i cache na reverse proxy wygrywa przy małym katalogu i dużej liczbie odsłon treści. Nie da się tego rozstrzygnąć tabelką — trzeba zmierzyć TTFB i LCP na obu instalacjach na tym samym hostingu. Lokalne przykłady klientów z okolic opisujemy też przy okazji wdrożeń WooCommerce w Szczebrzeszynie.

Audyt przed wdrożeniem: 12 rzeczy, które trzeba sprawdzić, zanim ruszy projekt

Audyt nie jest formalnością — to lista, po której wiadomo, czy projekt zamknie się w budżecie. Poniższe punkty da się odklikać i sprawdzić w panelu, bez wiary na słowo.

1. Liczba produktów i SKU. Eksport z obecnego sklepu do CSV — nie z arkusza, który „ktoś prowadzi”.
2. Warianty. Ile kombinacji przypada na produkt i czy ceny wariantów są uzupełnione.
3. Kategorie i URL-e. Liczba kategorii, głębokość, czy adresy zawierają ID czy słowa.
4. Zdjęcia. Liczba plików i łączny rozmiar w GB — katalog 2000 produktów po 5 zdjęć to 10000 plików i często 10–20 GB.
5. Domena i historia SEO. Search Console: raport pokrycia, lista 404, strony kanibalizujące się w wynikach. Robi się to przed migracją, bo po przeniesieniu dane się mieszają.
6. Właściciel domeny, hostingu i konta Google. Sprawdź w WHOIS i w panelu rejestratora, na czyj e-mail i nazwisko są konta. To najczęstszy problem przy zmianie wykonawcy.
7. Poczta na domenie. Rekordy SPF, DKIM, DMARC i lista skrzynek — migracja DNS bez tego skończy się trafianiem maili do spamu.
8. Mapa integracji z nazwami systemów. Nie „płatności”, a np. Przelewy24 i PayU; nie „magazyn”, a Subiekt lub Wapro Mag.
9. Pomiar wydajności przed. PageSpeed Insights i Lighthouse na stronie głównej, kategorii i produkcie — zapisz wyniki z datą jako punkt odniesienia.
10. Zakres w umowie. rozdzielenie na: wdrożenie, migrację treści, integracje, szkolenie. Wszystko poza tym to dodatek godzinowy — stawka i limit godzin muszą być w umowie.
11. Dostępy i kopie zapasowe. Osobne konto administratora dla wykonawcy, środowisko testowe, harmonogram backupów bazy i plików.
12. Plan 301. Tabela stary URL → nowy URL dla produktów i kategorii, gotowa przed przełączeniem DNS.

Kolejność ma znaczenie: punkty 1–4 określają nakład pracy, 5–7 ratują ruch i pocztę, 8–10 chronią budżet, 11–12 pozwalają wrócić do stanu sprzed wdrożenia. Niezależnie od tego, czy szkolimy klienta, czy przejmujemy projekt po kimś innym, kolejność kroków wygląda tak samo — podobnie rozpisujemy ją dla zespołów z okolic w materiale o organizacji wdrożenia WooCommerce w Zamościu.

Hosting i serwer pod WooCommerce: gdzie traci się najwięcej wydajności

Najwięcej wydajności traci się nie na wtyczkach, a na konfiguracji PHP i bazy. Kolejność diagnozy: PHP → OPcache → baza → object cache → cache stron → CDN. Naprawianie tego od końca to strata pieniędzy.

Minimum, które musi spełniać hosting:

• PHP 8.2 lub nowszy, OPcache włączony, opcache.memory_consumption 128–256 MB.
• MySQL 8.0 lub MariaDB 10.6+, silnik InnoDB, innodb_buffer_pool_size na poziomie 50–70% dostępnego RAM.
• Object cache: Redis lub Memcached. Bez tego każde wejście na stronę odtwarza zapytania WooCommerce od zera.
• PHP-FPM zamiast mod_php, HTTP/2, kompresja Brotli lub Gzip.

Dlaczego hosting współdzielony za 15 zł/mies. zabija koszyk. Taki plan ma zwykle limiter CPU (1 rdzeń, 20–25% dostępnego czasu, 1–2 równoległe procesy PHP). Strona główna wczyta się szybko z cache, ale przy 30 jednoczesnych użytkownikach procesy wchodzą w limit: dodanie do koszyka i checkout zaczynają trwać 8–15 s albo kończą się błędem 508 lub timeoutem. Klient traci sesję koszyka i wychodzi. To nie kwestia wtyczki — to kwestia limitu.

VPS czy hosting managed. Przy ok. 1000 sesjach miesięcznie (kilkadziesiąt dziennie, szczyt 3–5 osób jednocześnie) wystarczy dobry managed: płacisz za pilnowanie PHP, backupów i aktualizacji. Przy ok. 10000 sesjach miesięcznie (około 330 dziennie, szczyt 20–40 jednocześnie) VPS z 4 vCPU i 8 GB RAM plus własna konfiguracja wychodzi taniej niż managed z porównywalnymi limitami.

PHP-FPM: pm.max_children licz z RAM. Wzór: dostępny RAM dla PHP podzielony przez średnie zużycie procesu. 4 GB RAM, 2,5 GB dla PHP, proces ok. 80 MB → około 30 procesów. Do tego memory_limit 256–512 MB, max_execution_time 60–120 s, pm.max_requests 500–1000. Import katalogu uruchamiaj z CLI, nie przez panel WWW — inaczej zjadasz procesy potrzebne do obsługi klientów.

Cache i CDN. Na poziomie reverse proxy (Varnish, Cloudflare, nginx fastcgi_cache) cache’uj: strony kategorii, karty produktów, bloga, strony statyczne. Nigdy: /cart, /checkout, /my-account, strony dla zalogowanych i podsumowanie koszyka w nagłówku. Efekt mierz na TTFB i LCP — zestaw wskaźników opisuje dokumentacja Web Vitals, którą warto traktować jak listę kontrolną, a nie cel sam w sobie. Ten sam zestaw ustawień stosujemy w projektach takich jak wdrożenia i optymalizacja WooCommerce w Józefowie.

Optymalizacja szybkości WooCommerce: 7 miejsc, w których traci się najwięcej czasu

Zanim ktokolwiek dotknie szablonu, ustal punkt odniesienia. Progi, do których warto dążyć: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — liczone w 75. percentylu realnych wejść, a nie w jednym teście na szybkim laptopie. Definicje i sposób pomiaru opisuje dokumentacja web.dev o Core Web Vitals.

1. Tabela wp_options. Autoload dociąga opcje przy każdym żądaniu, także tym, które nie potrzebuje ich wcale. Sprawdź SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';. Powyżej 1 MB zaczyna boleć. Najcięższe wpisy wyciągniesz przez ORDER BY LENGTH(option_value) DESC LIMIT 20. Typowi sprawcy: opcje po wtyczkach usuniętych rok temu i wpisy _transient_. Usuń sieroty, wyłącz autoload tam, gdzie opcja jest potrzebna wyłącznie w panelu.

2. Zapytania do bazy. Strona kategorii z 24 produktami powinna zamknąć się w 60–80 zapytaniach. Query Monitor pokaże, kto generuje resztę — zwykle trzy wtyczki robiące to samo. 3. wp_postmeta i HPOS. Sortowanie czy filtrowanie po meta_value skanuje tabelę bez indeksu. Włącz HPOS w WooCommerce → Ustawienia → Zaawansowane → Funkcje i sprawdź raport zgodności wtyczek: zamówienia przenoszą się do wp_wc_orders, a lista zamówień w panelu przestaje dławić się na postmeta.

4. Transients i Action Scheduler. Wejdź w WooCommerce → Stan → Zaplanowane akcje. Kilka tysięcy zadań po terminie oznacza, że WP-Cron nie wyrabia — podmień go na cron systemowy co minutę i wyczyść zakończone zadania.

5. Obrazy. WebP lub AVIF, lazy loading tylko poniżej pierwszego ekranu, zdjęcie hero z fetchpriority="high" i bez loading="lazy". 6. Skrypty. defer dla większości, async tylko dla niezależnych narzędzi analitycznych. 7. CSS. Nieużywane arkusze szablonu i wtyczek to często 200–400 kB.

Pomiar „przed i po”: zrzut z Lighthouse, raport z hostingu (liczba zapytań MySQL, użycie CPU) i ten sam test na tym samym urządzeniu. Bez tego nie ma czego rozliczać.

Wtyczka czy własny moduł? Kryteria, których nie znajdziesz w cenniku

Wtyczka premium kosztuje nie tylko abonament. Każda dokłada zapytania do bazy, swoje hooki i ryzyko konfliktu po aktualizacji WordPressa albo WooCommerce. Prosta zasada: policz, ile funkcji danego pluginu realnie wykorzystujesz. Jeśli z 20 funkcji używasz trzech, płacisz za 17 zbędnych — i to one generują obciążenie.

Kiedy własny moduł wygrywa: nietypowa logika cenowa (rabat liczony od całego koszyka, a nie od pozycji), integracja z wewnętrznym ERP pisanym na zamówienie, specyficzne zasady wysyłki (własna kalkulacja palet, strefy, progi), a także sytuacja, gdy klient już dwa razy płacił za customizację cudzej wtyczki i przy trzeciej aktualizacji nadal traci funkcję. W takich przypadkach 60–120 godzin pracy programisty zwraca się zwykle w rok–dwa, bo znika abonament i znika walka z aktualizacjami.

Kiedy wtyczka jest lepsza: bramki płatności (oficjalne wtyczki Przelewy24, PayU, tpay czy Autopay przechodzą audyty i aktualizacje bezpieczeństwa za ciebie), koszyki porzucone, obsługa zgód RODO i regulaminów, fakturowanie. Pisanie własnej bramki oznacza wzięcie na siebie odpowiedzialności za bezpieczeństwo transakcji — tego nie warto robić bez powodu.

Utrzymanie własnego kodu trzeba wpisać w umowę: kto aktualizuje moduł po zmianie wersji WooCommerce, w jakim czasie reaguje na błąd (np. SLA 24 h w dni robocze) i gdzie leży repozytorium. Kod powinien być w Gitcie klienta, z dokumentacją, żeby zmiana wykonawcy nie oznaczała przepisywania od zera. Jeśli rozważasz alternatywę dla WooCommerce, zobacz, jak wyglądają wdrożenia i migracje PrestaShop we Frampolu — w części projektów to prostsza droga.

Integracje: płatności, InPost, DPD, DHL i ERP bez blokowania wdrożenia

Kolejność podłączania integracji ma znaczenie, bo każda następna zależy od poprzedniej. Sprawdzona sekwencja: płatności → kurierzy i etykiety → ERP → faktury i KSeF → monitoring. Podłączanie ERP przed zamknięciem płatności kończy się testami na danych, które za tydzień się zmienią.

Płatności. W umowie z Przelewami24, PayU, tpay albo Autopay sprawdź trzy rzeczy poza samą prowizją: czas wypłaty środków (T+1 czy T+7), stawkę dla BLIK-a i kart osobno oraz koszt i procedurę chargebacku. Zapytaj o piaskownicę — bez niej nie przetestujesz scenariusza nieudanej płatności.

Kurierzy. InPost Paczkomaty działa przez ShipX API, DPD i DHL mają własne API. Kluczowe jest mapowanie statusów przesyłek na statusy zamówienia i generowanie etykiet bez wychodzenia z panelu sklepu. Numer przesyłki powinien trafiać do maila automatycznie — inaczej obsługa przepisuje go ręcznie przy każdym zamówieniu.

ERP. Najpierw decyzja o kierunku przepływu: sklep jest źródłem prawdy dla zamówień, a ERP dla stanów magazynowych — albo odwrotnie. Synchronizacja co 5–15 minut przez cron wystarcza w większości sklepów; przy dużym ruchu lepsze są webhooki. Konflikty stanów rozwiązuj rezerwacją w ERP, a nie nadpisywaniem liczby sztuk w obie strony.

KSeF. Wystawianie faktur trzeba zaplanować w integracji już teraz: albo sklep wystawia fakturę i sam wysyła ją do KSeF, albo przekazuje dane do systemu księgowego. Terminy obowiązywania sprawdź w aktualnym komunikacie Ministerstwa Finansów.

Testy i monitoring. Przejdź na piaskownicy pełne scenariusze: zwrot, anulacja, brak potwierdzenia płatności. Na produkcji ustaw alert, gdy etykieta się nie wygeneruje albo webhook płatności nie dojdzie w ciągu 10 minut. Bez tego dowiesz się o awarii od klienta. Podobną kolejność stosujemy przy organizacji wdrożenia WooCommerce w Zamościu i okolicznych firmach.

Migracja na WooCommerce z PrestaShop, Shopera lub sklepu na zamówienie

Migracja z PrestaShop, Shopera albo sklepu pisanego na zamówienie to w większości praca na danych, nie na szablonie. Kolejność: eksport, mapowanie starych adresów, test na kopii, przełączenie, monitoring.

Co eksportujemy. Produkty, warianty, kategorie, klientów, zamówienia z historią, stany magazynowe i zdjęcia w oryginalnej rozdzielczości. Z PrestaShop najprościej przez SQL lub moduł eksportu — struktura tabel jest opisana w dokumentacji PrestaShop dla deweloperów. Z Shopera przez API. Sklep na zamówienie: proś o dump bazy albo pliki CSV, nie o zrzuty ekranu z panelu.

• Klienci: e-mail, adresy, zgody marketingowe z datą i źródłem. Hasła i tak trzeba zresetować przy zmianie systemu.
• Zamówienia: statusy, kwoty, numery faktur, historia płatności — to dane księgowe, nie dodatek.
• Zdjęcia: pliki źródłowe, nie miniaturki; zachowaj nazwy plików.

Mapowanie URL i przekierowania 301. Wyciągnij stare adresy z sitemapy, Search Console i crawla (np. Screaming Frog). Reguła: jeden stary adres = jeden nowy, bez łańcuchów 301 → 301 → 200 — łańcuch marnuje budżet crawlowania. Po migracji wgraj dane strukturalne produktu (Product, Offer) i sprawdź je walidatorem.

Czego nie przenosić. Cache, logi, tabele _transient_* w wp_options, nieużywane wtyczki i stare motywy. To one generują połowę problemów po starcie: konflikty, wolne zapytania, błędy 500.

Test i okno przełączenia. Kopia staging z pełnym indeksem i sprawdzeniem 404 w Search Console. TTL domeny obniżony 24 h wcześniej, certyfikat SSL wystawiony przed zmianą DNS, tryb serwisowy wyłączony po weryfikacji. Pierwsze 24 h to monitoring błędów 5xx; po tygodniu — aktualizacja sitemapy i ponowne sprawdzenie danych strukturalnych.

Ile realnie kosztuje wdrożenie i optymalizacja WooCommerce — widełki godzinowe

Pytanie „ile kosztuje sklep w WooCommerce” nie ma sensu — odpowiedź brzmi „od 3 do 60 tys. zł” i obie liczby są prawdziwe. Właściwe pytanie to: ile godzin zajmie mój zakres i jaka jest stawka za godzinę.

Widełki dla sklepu z 1000 produktów, bez integracji z ERP i WMS:

Punkt „1000 produktów = 6–12 h” zakłada czyste dane: SKU, ceny, VAT, waga, kategoria, zdjęcia. Jeśli ceny są w trzech formatach, warianty wpisane w opis, a połowa kategorii nie istnieje — czas się podwaja.

Stawki godzinowe w regionie lubelskim mieszczą się zwykle w przedziale 90–180 zł netto. W tej cenie powinien siedzieć kod, testy, krótka dokumentacja wdrożenia i okres wsparcia powdrożeniowego — jego brak to najczęściej pomijany punkt tanich wycen.

Wycena godzinowa jest bezpieczniejsza dla klienta niż stała kwota „za sklep”: przy stałej kwocie każda zmiana zakresu kończy się albo dopłatą, albo skróceniem prac — zwykle kosztem testów. Przy rozliczeniu godzinowym widzisz, na co poszło 120 h. Tak samo rozliczamy wdrożenia WooCommerce w Józefowie: najpierw audyt, potem liczba godzin.

Kiedy wdrożenie nie ma sensu finansowo: 20 produktów, 200 sesji miesięcznie i zamówienie raz na dwa tygodnie. Taniej i mniej awaryjnie wyjdzie abonament w istniejącej platformie albo sprzedaż na marketplace.

Opieka po wdrożeniu: co powinno być w SLA i co sprawdzać co miesiąc

Wdrożenie kończy się w dniu przełączenia, a problemy zaczynają się tydzień później. Dlatego SLA jest ważniejsze niż sam wygląd sklepu.

Elementy SLA. Nie kupuj „wsparcia 24/7” bez liczb. W umowie muszą być cztery parametry: czas reakcji na awarię krytyczną, czas reakcji na zgłoszenie zwykłe, kanał zgłoszeń i godziny wsparcia. Awaria krytyczna to sklep niedostępny lub niedziałające płatności — reakcja w godzinę, nie „w ciągu dnia”. Weryfikacja jest prosta: wyślij testowe zgłoszenie poza godzinami pracy i zobacz, co się stanie.

Backupy. Codziennie, minimum baza i pliki, retencja 30 dni, kopia poza serwerem — nie w tym samym panelu i nie na tym samym dysku. Najważniejsze: raz na kwartał udokumentowany test odtworzenia na kopii staging. Backup, którego nikt nie próbował odtworzyć, nie jest backupem.

Aktualizacje. Harmonogram: drobne poprawki WordPressa automatycznie, duże wersje i wtyczki raz w miesiącu w ustalonym oknie, PHP po sprawdzeniu zgodności z WooCommerce. Przed każdą aktualizacją kopia i punkt wycofania — jeśli testy nie przejdą w 15 minut, wracasz do poprzedniej wersji.

Monitoring. Uptime co minutę, czas odpowiedzi, błędy PHP w logach, zużycie CPU i zajętość dysku. Alert, nie raport po fakcie: o sklepie, który stał 6 godzin, powinieneś wiedzieć po dwóch minutach, nie po telefonie od klienta.

Raport miesięczny. Jedna strona: co zmieniono, co wykryto, co zaplanowano, ile zgłoszeń i o jakim czasie reakcji.

Zmiany prawne. Omnibus — przy obniżce musisz pokazać najniższą cenę z 30 dni przed promocją; to logika w szablonie i w danych produktu, nie notka w regulaminie. RODO — polityka, cookies, rejestr czynności. Dostępność: wymogi europejskie (EAA) weszły w życie w 2025 r., ale stan wdrożenia w Polsce warto potwierdzić u prawnika, bo przepisy się zmieniały.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Liczba produktów i wariantów — Pobierz eksport z panelu i policz produkty proste oraz warianty osobno. To liczba pozycji do importu, a nie liczba kart produktów.
• Struktura kategorii i filtrów — Wypisz drzewo kategorii i sprawdź, czy pokrywa się z tym, jak klienci szukają produktów. Przy okazji ustal, które atrybuty mają być filtrami.
• Łączny rozmiar zdjęć w GB — Sprawdź rozmiar katalogu ze zdjęciami na serwerze lub w panelu. Katalog 20 GB wymaga innego podejścia do importu i backupu niż 1 GB.
• Historia SEO w Search Console — Przed jakąkolwiek migracją przejrzyj raport pokrycia, listę 404 i zapytania, które mają po dwie własne strony (kanibalizacja). Ustal, które adresy muszą zostać zachowane.
• Właściciel domeny i DNS — Zaloguj się sam do rejestratora i sprawdź, kiedy wygasa domena oraz kto figuruje jako właściciel i kontakt techniczny.
• Dostępy do hostingu i dane serwera — Ustal, czy masz panel i dane FTP/SSH. Sprawdź wersję PHP, silnik bazy danych i dostępność OPcache oraz Redis lub Memcached.
• Konta Google i analityka — Sprawdź, na jakim koncie jest Search Console, Analytics i Google Ads oraz czy masz do nich uprawnienia administracyjne, a nie tylko odczyt.
• Mapa integracji z nazwami systemów — Zapisz konkretne nazwy: bramka płatności, firmy kurierskie, program do faktur, magazyn lub ERP, system księgowy. Bez nazw nie da się tego wycenić.
• Lokalne kanały dostawy i płatności — Sprawdź, które punkty odbioru i firmy kurierskie realnie obsługują klientów z Biłgoraja, Zamościa, Janowa Lubelskiego i Szczebrzeszyna oraz czy pobranie ma być dostępne.
• Punkt odniesienia wydajności — Zmierz PageSpeed Insights i Lighthouse na stronie głównej, kategorii i karcie produktu. Zapisz wyniki z datą jako stan „przed”.
• Zakres w umowie i dodatki godzinowe — Wypisz, co jest w cenie, a co jest rozliczane za godziny: import danych, przekierowania, integracje, szkolenie, wsparcie po starcie.
• Koszt roczny licencji i aktualizacji — Zbierz ceny wtyczek premium i ustal, kto robi aktualizacje po zakończeniu projektu. Sprawdź, czy licencje są na Twoją firmę, czy na wykonawcę.
• Osoba odpowiedzialna za treści — Ustal z imienia, kto pisze opisy, kto robi i obrabia zdjęcia oraz kto akceptuje teksty. Ten etap najczęściej wydłuża projekt najbardziej.
• Plan testów i wersja awaryjna — Przed publikacją sprawdź koszyk, płatność, e-maile transakcyjne i wysyłkę na testowym zamówieniu. Ustal, jak wrócicie do poprzedniej wersji, jeśli coś pójdzie nie tak.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów