Jaki hosting wytrzyma sklep WooCommerce? Procesy PHP, RAM i baza danych

Sklep WooCommerce potrzebuje hostingu, który udźwignie zapytania niecachowalne: koszyk, kasa i konto klienta są generowane od zera przy każdym wejściu, więc liczy się liczba procesów PHP, RAM i wydajność bazy danych, a nie miejsce na dysku. Minimum techniczne WooCommerce to PHP 8.3 lub nowszy, MySQL 8.0 lub MariaDB 10.6, 256 MB RAM i HTTPS, ale realny próg dla działającego sklepu w 2026 roku to dyski NVMe, Redis jako object cache, około 30 procesów PHP i kopie zapasowe częstsze niż raz na dobę. Hosting współdzielony wystarcza tylko nowym sklepom o znikomym ruchu.

Dlaczego WooCommerce obciąża serwer inaczej niż zwykły WordPress

Blog czy strona firmowa na WordPressie to w praktyce generator plików statycznych. Wtyczka cache renderuje stronę raz, zapisuje ją jako HTML i serwuje tysiącom odwiedzających bez uruchamiania PHP i bez dotykania bazy. Dlatego zwykła wizytówka działa poprawnie nawet na najtańszym pakiecie: PHP prawie się nie uruchamia.

Sklep łamie ten model. WooCommerce z definicji tworzy strony, których nie wolno zacache'ować, bo są różne dla każdego użytkownika:

• Koszyk, bo zawiera produkty konkretnej osoby.
• Kasa (checkout), bo zawiera dane, tokeny płatności i wyliczoną wysyłkę.
• Moje konto, bo pokazuje zamówienia zalogowanego klienta.
• Panel administracyjny, gdzie obsługujesz zamówienia i magazyn.

Do tego dochodzą fragmenty koszyka wstrzykiwane na stronach produktów przez AJAX. Każde dodanie do koszyka to osobne zapytanie do admin-ajax.php, które przechodzi przez pełny bootstrap WordPressa. Klient klikający po pięciu produktach generuje pięć pełnych uruchomień PHP, nawet jeśli same strony produktów są cache'owane.

Pojedyncze wywołanie WooCommerce potrafi wykonać kilkaset zapytań SQL. Odpytuje tabele produktów, wariantów, atrybutów, stanów magazynowych, kuponów, stref wysyłki, podatków oraz metadanych zamówień. Dochodzi klasyczny problem tabeli wp_options: wtyczki zapisują tam dane z flagą autoload = yes, a WordPress ładuje je wszystkie przy każdym żądaniu. W sklepie po dwóch latach działania, z porzuconymi wtyczkami i wygasłymi transientami, autoload potrafi urosnąć do kilku megabajtów odczytywanych za każdym razem. To jedna z pierwszych rzeczy, które sprawdzamy, kiedy sklep "nagle zwolnił bez powodu".

Jaki hosting dla sklepu internetowego wybrać?

Wybierz hosting z gwarantowanymi zasobami: dyskiem NVMe, PHP 8.3 lub nowszym, bazą MySQL 8.0 albo MariaDB 10.6, obsługą Redisa i jasno podaną liczbą procesów PHP (minimum około 30 dla realnego sklepu). Miejsce na dysku i nielimitowane transfery nie mają tu żadnego znaczenia. Liczy się to, ile równoległych żądań PHP serwer obsłuży, zanim zacznie kolejkować.

Praktyczny problem polega na tym, że większość ofert opisuje parametry, które są nieistotne dla sklepu, a milczy o tych krytycznych. 500 GB przestrzeni brzmi imponująco, ale sklep z tysiącem produktów zajmuje kilka gigabajtów razem ze zdjęciami. Za to informacja o tym, ile procesów PHP dostajesz, bywa ukryta w regulaminie albo nie ma jej wcale. Parametry pod kątem samego e-commerce zebraliśmy na stronie hosting dla sklepu internetowego.

Czym są procesy PHP (PHP workers) i ile ich potrzebujesz?

Proces PHP (worker) wykonuje jedno żądanie w danym momencie. Jeśli masz 10 procesów, serwer przetwarza równolegle 10 niecachowalnych żądań. Jedenaste czeka w kolejce. Dla sklepu to najważniejszy parametr wydajnościowy, ważniejszy niż surowa moc procesora.

Przykład liczbowy. Załóżmy, że średnie żądanie WooCommerce zajmuje 400 ms. Jeden proces obsłuży więc 2,5 żądania na sekundę. Przy 10 procesach masz teoretyczny sufit 25 żądań PHP na sekundę, ale tylko wtedy, gdy nic nie zwalnia. Wystarczy, że bramka płatnicza odpowiada wolniej albo integracja z systemem magazynowym czeka 3 sekundy na API, a proces jest zablokowany na te 3 sekundy i nie robi nic innego. Trzy takie zapytania jednocześnie zjadają jedną trzecią przepustowości sklepu.

Objaw braku procesów jest charakterystyczny: strona główna i produkty otwierają się natychmiast (idą z cache), ale koszyk i checkout mielą po kilkanaście sekund albo zwracają błąd 504. Jeśli to widzisz w godzinach szczytu, nie pomoże żadna optymalizacja obrazków. Potrzebujesz więcej procesów albo szybszych odpowiedzi.

Trzydzieści procesów to rozsądny punkt startowy dla sklepu z realnym ruchem. Poniżej dziesięciu jesteś na łasce jednego bota indeksującego, który wejdzie na dwadzieścia stron naraz.

Ile RAM potrzebuje WooCommerce?

Formalne minimum WooCommerce to 256 MB RAM, ale to wartość dla samego PHP i dla instalacji, nie dla pracy. Praktyczny punkt startowy: około 1 GB na konto i 512 MB limitu na pojedynczy proces. Sklep z kilkoma tysiącami produktów, wtyczką do integracji z hurtownią i eksportem faktur potrzebuje realnie 2 do 4 GB, żeby nie zabijać importów w połowie.

RAM kończy się najczęściej nie na stronie klienta, tylko w zadaniach administracyjnych: import CSV z produktami, generowanie raportów sprzedaży, aktualizacja stanów magazynowych, regeneracja miniatur. Te operacje przewijają tysiące wierszy przez PHP i zżerają pamięć liniowo. Błąd "Allowed memory size exhausted" w środku importu 5000 produktów to klasyk.

Pamiętaj też, że RAM na serwerze dzieli się między procesy PHP, bazę danych i Redisa. Baza chce trzymać indeksy w pamięci (bufor InnoDB), bo inaczej sięga na dysk przy każdym zapytaniu. Jeśli sprzedawca hostingu podaje jedną liczbę RAM dla całego konta, ta liczba musi pokryć wszystkich trzech konsumentów naraz.

Wymagania techniczne w liczbach

NVMe, SSD czy HDD: czy dysk jeszcze robi różnicę?

Tak, i to bardziej niż w zwykłym WordPressie. Baza danych sklepu wykonuje mnóstwo losowych odczytów o małym rozmiarze, a to najgorszy możliwy scenariusz dla dysku talerzowego. NVMe daje w tym profilu obciążenia wielokrotnie niższe opóźnienia niż SATA SSD, a różnica względem HDD jest po prostu dyskwalifikująca.

Jeśli oferta w 2026 roku nie mówi wprost o NVMe, zakładaj, że to SATA SSD albo gorzej. Sklep na HDD wygląda dokładnie jak sklep bez procesów: pierwsza strona szybko, koszyk beznadziejnie, bo tam idą realne zapytania do bazy. U nas NVMe jest w każdym pakiecie, od 5 GB w Starcie po 100 GB w Pro.

Redis i object cache: co realnie zyskujesz

Cache stron nie działa na koszyku i kasie, ale object cache tak. Redis trzyma w pamięci wyniki powtarzalnych zapytań do bazy: opcje, transienty, metadane produktów, wyniki zapytań taksonomii. Dzięki temu żądanie, które normalnie odpytuje bazę 300 razy, robi to znacznie rzadziej, a reszta odpowiedzi wraca z pamięci.

Efekt widać właśnie tam, gdzie boli: w checkoucie, panelu administracyjnym i przy aktualizacjach koszyka przez AJAX. To nie jest gadżet, tylko standardowy element stosu sklepowego. Hosting, który nie oferuje Redisa albo memcached, z góry skazuje Twoją bazę na wykonywanie tej samej pracy w kółko.

Czy hosting współdzielony wystarczy dla sklepu?

Wystarczy dla sklepu nowego, z kilkudziesięcioma produktami i kilkoma zamówieniami dziennie, gdzie realny ruch to kilkanaście osób naraz w porywach. Powyżej tego poziomu współdzielenie zaczyna kosztować: zasoby dzielisz z setkami innych kont, a limity procesów są sztywne i zwykle niskie. Sezonowy szczyt sprzedaży zderzy się z nimi jako pierwszy.

Uczciwie o trzech modelach:

• Hosting współdzielony. Najtańszy, zerowa administracja, ale zasoby elastyczne w dół, nie w górę. Sąsiad z rozjechanym skryptem potrafi spowolnić Twój sklep. Dobry na start i na testy rynku.
• Hosting zarządzany. Zasoby przypisane do Ciebie, ktoś pilnuje aktualizacji i bezpieczeństwa. Płacisz za to, żeby nie być administratorem. Sensowny wybór dla sklepu, który zarabia, ale nie ma działu IT.
• VPS lub serwer dedykowany. Pełna kontrola i najlepszy stosunek mocy do ceny, pod warunkiem że masz kogoś, kto to skonfiguruje, zaktualizuje i obudzi się o trzeciej w nocy. Nieadministrowany VPS bez tej osoby jest gorszy niż porządny współdzielony, bo bezpieczeństwo staje się Twoim problemem.

Najczęstszy błąd: sklep, który zarabia realne pieniądze, siedzi na pakiecie kupionym trzy lata temu na bloga i nikt tego nie zweryfikował. Drugi najczęstszy: skok na nieadministrowany VPS dla wydajności, po czym rok bez aktualizacji i włamanie przez podatną wtyczkę.

Backup sklepu: raz dziennie to za rzadko

W blogu kopia dobowa jest w porządku, bo najgorsze co tracisz to jeden wpis. W sklepie między kopiami są zamówienia, płatności i zmiany stanów magazynowych. Awaria o 22:00 przy kopii z 3:00 rano oznacza dziewiętnaście godzin sprzedaży do odtworzenia ręcznie z maili i z panelu operatora płatności. To nie jest teoria, to typowy poniedziałek po nieudanej aktualizacji wtyczki.

Dlatego dla sklepu pytaj o trzy rzeczy naraz: częstotliwość kopii, retencję (ile dni wstecz można wrócić) i to, czy kopia jest wykonywana przed każdą aktualizacją. Ten trzeci punkt eliminuje najczęstszą przyczynę awarii sklepów, czyli aktualizację, która rozjeżdża szablon albo integrację płatności. Opisaliśmy to szerzej przy okazji tematu bezpiecznej aktualizacji WordPressa, bo procedura jest ważniejsza niż sama technologia. W Businesshost osobna kopia leci przed każdą aktualizacją, niezależnie od kopii dobowej, a w pakiecie Pro można odtworzyć stan nawet do 28 dni wstecz.

Sprawdź też, czy potrafisz odtworzyć kopię samodzielnie i jak długo to trwa. Backup, którego nikt nigdy nie przywrócił testowo, jest hipotezą, nie zabezpieczeniem.

Ile kosztuje hosting dla sklepu internetowego?

Sklep kosztuje więcej niż wizytówka, bo potrzebuje gwarantowanych zasobów, częstszych kopii i realnego wsparcia. Punkt odniesienia z naszego cennika: Start 39 zł netto miesięcznie (5 GB NVMe, kopia dobowa plus kopia przed każdą aktualizacją), Biznes 79 zł netto (25 GB NVMe, zarządzane aktualizacje, hardening i WAF, SLA 2 godziny), Pro 179 zł netto (100 GB NVMe, staging, SLA 1 godzina, optymalizacja WooCommerce).

Licząc koszt, porównuj go z tym, ile sklep zarabia w godzinę, a nie z ceną najtańszej oferty na rynku. Godzina niedostępności w szczycie sezonu kosztuje zwykle więcej niż roczna różnica między pakietami. Rozbiliśmy tę kalkulację na czynniki pierwsze w tekście o tym, ile kosztuje hosting dla firmy. Warto też z góry ustalić stronę formalną: fakturę VAT z polskim NIP i przewidywalny cykl rozliczeń, bo koszty hostingu wchodzą do kosztów firmy. Jeśli sklep dopiero się rozkręca i płynność bywa napięta, część firm w takiej sytuacji upłynnia niezapłacone faktury, zamiast czekać 60 dni na przelew od kontrahenta.

Jak sprawdzić hosting, zanim zapłacisz

Nie wierz deklaracjom marketingowym, sprawdź je. To zajmuje godzinę i oszczędza pół roku frustracji.

Zadaj wsparciu cztery konkretne pytania przed zakupem: ile dostanę procesów PHP, czy jest Redis, jaka jest wersja PHP i bazy, jak często robicie kopie i czy jest kopia przed aktualizacją. Jeśli wsparcie nie potrafi odpowiedzieć na pierwsze pytanie albo odsyła Cię do nielimitowanych zasobów, masz odpowiedź.

Potem przetestuj realnie. Postaw sklep na okresie próbnym (u nas 14 dni bez karty), zaimportuj swoje produkty i wykonaj kilka zamówień testowych. Zmierz czas odpowiedzi samego serwera (TTFB) na stronie koszyka i kasy, nie na stronie głównej, bo strona główna idzie z cache i zawsze wygląda dobrze. Włącz Query Monitor i zobacz, ile zapytań SQL generuje Twój checkout. Sprawdź rozmiar autoload w wp_options. Jeśli hosting oferuje migrację, wykorzystaj ją do testu: kopia sklepu na nowym serwerze obok starego to najuczciwsze porównanie, jakie istnieje.

Checklista przed wyborem hostingu pod WooCommerce

• PHP 8.3 lub nowszy, z włączonym OPcache.
• MySQL 8.0 lub MariaDB 10.6 i nowsze.
• Dyski NVMe, potwierdzone wprost w ofercie.
• Redis lub memcached dostępny jako object cache.
• Co najmniej około 30 procesów PHP, liczba podana konkretnie.
• Minimum 2 GB RAM na konto, 512 MB limitu na proces.
• Kopie zapasowe częściej niż raz dziennie, plus osobna kopia przed każdą aktualizacją.
• Retencja kopii co najmniej kilkanaście dni i możliwość samodzielnego odtworzenia.
• Środowisko staging do testowania aktualizacji.
• SSL odnawiany automatycznie.
• Wsparcie z realnym SLA i człowiekiem po drugiej stronie, w Twoim języku.
• Serwery i przetwarzanie danych zgodne z RODO, faktura VAT z polskim NIP.
• Okres próbny albo bezpłatna migracja, żeby zweryfikować wydajność na własnych danych.