Sklep WooCommerce może działać dobrze na hostingu współdzielonym, a może też zwalniać mimo pozornie mocnego pakietu. Sama pojemność dysku, liczba baz danych albo hasło „hosting WooCommerce” niewiele mówią o tym, jak plan zachowa się przy dynamicznym ruchu, checkoutcie, zadaniach w tle czy integracjach. Przy wyborze hostingu trzeba najpierw sprawdzić zgodność środowiska z WooCommerce, a dopiero potem oceniać zasoby i limity wpływające na wydajność.
Nie istnieje jeden uniwersalny zestaw typu „2 vCPU, 4 GB RAM i 10 PHP workers wystarczy dla sklepu z tysiącem produktów”. Obciążenie zależy od ruchu równoczesnego, motywu, wtyczek, zapytań do bazy, integracji, wyszukiwania, importów, API oraz tego, ile pracy sklep wykonuje poza samym wyświetleniem strony.
Najpierw zgodność techniczna, dopiero potem wydajność
Na dzień 21 września 2026 r. aktualna karta rekomendacji serwerowych WooCommerce dla wersji 10.8+ wskazuje dla nowego środowiska WordPress 6.9 lub nowszy, PHP 8.3 lub nowszy, MySQL 8.0 albo MariaDB 10.6 lub nowsze, obsługę HTTPS oraz WordPress memory limit co najmniej 256 MB. Poniższe wartości traktuj jako rekomendowany baseline dla nowego hostingu, a nie najniższe wersje, na których WooCommerce może się jeszcze uruchomić. Dokumentacja zgodności może nadal przewidywać starsze minimalne wersje części komponentów, ale przy wyborze nowego hostingu nie warto traktować legacy minimum jako celu.
Przed porównywaniem CPU, workers czy cache sprawdź więc wersje WordPressa, PHP i bazy, aktywny limit pamięci oraz HTTPS. Wersje i zalecenia WooCommerce zmieniają się w czasie, dlatego przy późniejszym zakupie hostingu warto ponownie sprawdzić bieżącą dokumentację zamiast traktować powyższe liczby jako stałe na lata. Przy zmianie środowiska sprawdź osobno zgodność z nowszą wersją PHP.
Najpierw ustal, co w sklepie jest dynamiczne
Prosta strona firmowa może większość wizyt obsłużyć z page cache. W WooCommerce część ruchu jest trudniejsza do buforowania: koszyk, checkout, konto klienta, operacje w panelu, AJAX, REST API czy niektóre integracje muszą wykonać kod PHP i zapytania do bazy. Im większy udział takich żądań, tym ważniejsze stają się limity procesora, pamięci, PHP workers i osobno parametry warstwy bazodanowej.
Dlatego przed zmianą hostingu warto ustalić, czy problem pojawia się przy zwykłym wejściu na stronę produktu, podczas finalizacji zamówienia, w panelu administracyjnym, przy synchronizacji stanów czy podczas zadań wykonywanych w tle. To różne ścieżki i mogą mieć różne wąskie gardła.
CPU i RAM: ważne, ale nie opisują całego sklepu
Limity CPU i pamięci konta wpływają przede wszystkim na PHP i zadania aplikacji. Baza danych może korzystać z osobnej infrastruktury i osobnych mechanizmów ograniczania zasobów, dlatego jej wydajność trzeba oceniać oddzielnie. Sam zapis „2 CPU” albo „4 GB RAM” nie wystarcza też do oceny hostingu: liczą się sposób naliczania limitów, ich zakres, czas tolerowanego przeciążenia oraz zachowanie platformy po przekroczeniu wartości granicznej.
Krótki skok użycia zasobów podczas importu produktów ma inne znaczenie niż stałe dochodzenie do limitu w godzinach sprzedaży. Jeśli sklep regularnie osiąga limit CPU albo pamięci przy zwykłym ruchu, wyższy plan może pomóc. Jeżeli obciążenie powoduje pojedyncza wadliwa wtyczka lub ciężkie zapytanie, sama migracja może tylko przesunąć problem.
Przed zakupem warto sprawdzić, czy operator pokazuje limity wprost i czy są one liczone dla całego konta, pojedynczego procesu czy innego zakresu. Szerzej opisujemy to w poradniku o limitach CPU, RAM, procesów i I/O na hostingu.
PHP workers: ile dynamicznych żądań może być obsługiwanych równolegle
PHP worker można uprościć do procesu obsługującego dynamiczne żądanie PHP. Jeżeli wszystkie dostępne workers są zajęte, kolejne żądania muszą czekać albo mogą zakończyć się błędem zależnie od konfiguracji środowiska.
W sklepie znaczenie mają przede wszystkim żądania, których nie da się bezpiecznie obsłużyć z pełnego page cache: checkout, konto klienta, część zapytań AJAX, API czy operacje w panelu. Duża liczba workers nie gwarantuje jednak szybkiego sklepu. Jeżeli pojedyncze żądanie trwa długo przez wolne zapytanie lub ciężki kod, każdy worker będzie zajęty dłużej.
Nie ma sensownego przelicznika „jeden worker na określoną liczbę użytkowników”. Lepiej sprawdzić rzeczywiste kolejki, czasy odpowiedzi i zachowanie sklepu przy równoległym ruchu. Więcej kontekstu znajduje się w poradniku PHP workers w hostingu WordPress.
MySQL: liczba baz to nie wydajność bazy
WooCommerce zapisuje i odczytuje dużo danych: produkty, zamówienia, metadane, sesje, ustawienia i informacje używane przez rozszerzenia. Wąskim gardłem może być liczba lub czas zapytań, brak dobrych indeksów, rozrastające się tabele, limit połączeń albo ograniczenia osobnej warstwy bazodanowej.
Informacja „100 baz MySQL” praktycznie nie mówi, jak szybko będzie działał jeden sklep. Przydatniejsze są limity połączeń na użytkownika, ograniczenia wielkości bazy, dostęp do statystyk i możliwość diagnozy wolnych zapytań. Wyższy limit połączeń również nie oznacza automatycznie szybszej bazy — pozwala tylko na inną skalę równoległości.
Osobno opisujemy limity MySQL na hostingu i sposób ich interpretacji.
Persistent object cache i Redis: pomoc dla części dynamicznych operacji
WordPress ma object cache, ale domyślnie nie jest on trwały pomiędzy kolejnymi żądaniami. Persistent object cache może przechowywać część wyników pomiędzy requestami i ograniczać powtarzalne odczyty z bazy. Backendem może być między innymi Redis lub Memcached.
W WooCommerce może to być użyteczne przy dynamicznych operacjach, ale nie zastępuje optymalizacji kodu, zapytań i bazy. Sama informacja „Redis dostępny” też nie oznacza, że WordPress faktycznie korzysta z niego jako persistent object cache. Potrzebna jest poprawna konfiguracja po stronie aplikacji.
Więcej o różnicy między dostępnością Redisa a realnym wykorzystaniem object cache opisujemy w artykule Redis na hostingu WordPress — kiedy pomaga.
Page cache nie obejmuje całego sklepu
Page cache może znacznie odciążyć stronę katalogu czy część stron produktów, ale sklep ma obszary zależne od sesji użytkownika. Zasady cache WooCommerce wskazują Cart, Checkout i My Account jako strony, które powinny pozostać dynamiczne. Błędne buforowanie może prowadzić do nieaktualnego koszyka, problemów z sesją albo nieprawidłowego działania konta klienta.
Dlatego szybka strona główna nie jest jeszcze dowodem, że hosting dobrze obsługuje finalizację zamówień. Przy diagnozie trzeba mierzyć te ścieżki oddzielnie.
CDN pomaga w dostarczaniu zasobów, nie zastępuje serwera aplikacji
CDN może przyspieszyć dostarczanie obrazów, arkuszy CSS, JavaScriptu i innych zasobów statycznych, szczególnie gdy klienci są geograficznie oddaleni od serwera. W części konfiguracji może obsługiwać także szerszy zakres cache, ale nie należy zakładać tego tylko na podstawie informacji „CDN dostępny”.
CDN nie naprawi wolnych zapytań MySQL, zajętych PHP workers ani ciężkiego checkoutu. Przy problemach dynamicznych nadal kluczowa jest praca originu. Szerzej opisujemy to w poradniku CDN przy WordPressie — kiedy pomaga.
Cron i Action Scheduler: sklep pracuje także wtedy, gdy klient niczego nie klika
WooCommerce i jego rozszerzenia wykonują zadania w tle. Action Scheduler utrzymuje własną kolejkę i historię zadań, a jej przetwarzanie jest domyślnie inicjowane między innymi przez WP-Cron. WooCommerce udostępnia Scheduled Actions w panelu WooCommerce > Status > Scheduled Actions, gdzie można sprawdzić zadania oczekujące, zakończone i błędne.
Problem z harmonogramem może opóźniać kolejkę, ale sama zmiana sposobu uruchamiania crona nie naprawi błędnych ani zbyt ciężkich zadań. Nie oznacza to również, że każdy sklep musi od razu zastępować WP-Cron cronem serwerowym.
Warto sprawdzić, czy hosting pozwala ustawić cron oraz jaki jest minimalny interwał. Więcej w poradniku WP-Cron czy cron serwerowy.
I/O, IOPS i liczba plików
Aktualizacje, generowanie obrazów, logi, cache, backupy, importy i eksporty powodują operacje dyskowe. Przy małym limicie I/O intensywne zadanie może spowolnić sklep nawet wtedy, gdy pojemność dysku jest daleka od wykorzystania. Warto odróżniać przepustowość I/O od liczby operacji IOPS — to różne ograniczenia i operator może raportować je osobno.
Osobnym ograniczeniem bywa liczba inode, czyli w praktyce liczba obiektów w systemie plików. Sklep może gromadzić wiele miniatur, plików cache, logów i kopii, więc limit liczby plików może zostać osiągnięty wcześniej niż limit gigabajtów. Więcej o warstwie dyskowej opisujemy w poradniku I/O i IOPS w hostingu.
Backup i staging: przy sklepie liczy się zakres odtwarzania
Przywrócenie starszej kopii sklepu może cofnąć zamówienia, konta klientów i zmiany stanów magazynowych powstałe po wykonaniu backupu. Dlatego trzeba wiedzieć nie tylko, jak często powstają kopie i jak długo są przechowywane, ale też czy restore może być selektywny oraz jaki zakres danych zostanie nadpisany.
Środowisko staging pozwala sprawdzić aktualizację WooCommerce, motywu lub wtyczki przed zmianą produkcji. Trzeba jednak znać workflow operatora. Pełne przeniesienie bazy staging na produkcję może nadpisać zamówienia albo konta utworzone już po wykonaniu kopii. W sklepie różnica między kopiowaniem kodu a kopiowaniem bieżących danych jest krytyczna.
Pomocne są poradniki o retencji kopii zapasowych oraz o stagingu WordPressa na hostingu.
Poczta transakcyjna też jest częścią działania sklepu
Potwierdzenia zamówień, reset haseł i część powiadomień zależą od wysyłki poczty. W hostingu współdzielonym mogą obowiązywać limity wysyłki. Samo to, że WordPress potrafi wysłać wiadomość, nie potwierdza jeszcze poprawnego uwierzytelnienia domeny ani dobrej dostarczalności.
Przy ważnej poczcie transakcyjnej warto sprawdzić rzeczywisty system wysyłający oraz konfigurację SPF, DKIM i DMARC. Szczegółowo opisujemy ją w poradniku SPF, DKIM i DMARC na hostingu.
Cały sklep powinien działać po HTTPS
Dokumentacja WooCommerce dotycząca HTTPS zaleca zabezpieczenie całego sklepu, nie tylko checkoutu. Checkout i konto klienta są szczególnie wrażliwymi obszarami, ale nie ma powodu utrzymywać pozostałych stron sklepu po HTTP. Płatny certyfikat nie jest z tego powodu automatycznie potrzebny — bezpłatny certyfikat może zapewnić poprawne HTTPS, jeśli jest prawidłowo wystawiony i odnawiany.
Jeżeli chcesz rozdzielić wymagania techniczne od marketingu ofert, zobacz poradnik czy za certyfikat SSL trzeba płacić.
Jak rozpoznać, że problem może leżeć po stronie hostingu
Na ograniczenie infrastruktury mogą wskazywać powtarzalne błędy 503 lub 508, timeouty, wyczerpywanie workers, regularne dochodzenie do limitów CPU/RAM/I/O albo problemy pojawiające się wyłącznie przy większym równoczesnym obciążeniu. To są sygnały do diagnozy, a nie automatyczny dowód, że trzeba zmienić operatora.
Jeżeli problem dotyczy konkretnego kodu, wtyczki albo zapytania, mocniejszy pakiet może jedynie opóźnić jego wystąpienie. Pomocne są osobne poradniki o błędzie 508, błędzie 503 i sytuacji, gdy WordPress działa wolno.
Jak odróżnić problem hostingu od problemu samego sklepu
- Sprawdź limity i logi w panelu hostingu. Zanotuj momenty, w których pojawia się problem.
- Porównaj je z ruchem i zadaniami sklepu. Szukaj zależności z checkoutem, importem, synchronizacją lub innym procesem.
- Sprawdź wolne zapytania i ciężkie rozszerzenia, jeśli hosting lub narzędzia aplikacji udostępniają takie dane.
- Sprawdź Scheduled Actions w WooCommerce i zalegające zadania.
- Sprawdź cache oraz to, czy dynamiczne strony nie są buforowane niewłaściwie.
- Zmiany dodatków testuj na stagingu, a nie przez destrukcyjne eksperymenty na sklepie produkcyjnym.
- Dopiero po ustaleniu wąskiego gardła oceniaj, czy potrzebny jest wyższy plan, inny hosting czy poprawka aplikacji.
O co zapytać operatora przed zakupem hostingu dla WooCommerce
| Obszar | Pytanie | Dlaczego ma znaczenie |
|---|---|---|
| Zgodność | Jakie wersje PHP, MySQL/MariaDB i WordPressa obsługuje plan oraz jaki limit pamięci może mieć WordPress? | Najpierw trzeba spełnić aktualne wymagania platformy. |
| CPU i RAM | Jakie limity obowiązują dla planu, jak są mierzone i jaki mają zakres? | Same nazwy pakietów nie pokazują dostępnych zasobów. |
| PHP workers | Ile workers może równocześnie obsługiwać PHP i jaki jest zakres limitu? | Dynamiczne żądania sklepu konkurują o dostępne procesy. |
| I/O / IOPS | Jakie są limity transferu dyskowego i liczby operacji? | Importy, cache, logi i backup mogą intensywnie korzystać z dysku. |
| MySQL | Czy są limity połączeń, wielkości bazy albo inne limity użytkownika DB? | Liczba baz nie opisuje sposobu działania serwera baz danych. |
| Cron | Czy można uruchamiać własne zadania cron i jaki jest minimalny interwał? | Regularny harmonogram może mieć znaczenie dla zadań w tle. |
| Object cache | Czy plan pozwala używać persistent object cache dla WordPressa i jak się go aktywuje? | Sama dostępność Redis nie potwierdza, że WordPress z niego korzysta. |
| Staging | Jak działa push/pull i czy można przenosić selektywnie pliki oraz bazę? | Pełne nadpisanie bazy może usunąć nowe zamówienia. |
| Backup | Jak często powstają kopie, jak długo są przechowywane, co można przywrócić i jaki zakres zostanie nadpisany? | Restore sklepu może dotyczyć danych transakcyjnych. |
| Poczta | Jakie są limity wysyłki i jakie dane operator podaje do konfiguracji poczty? | Powiadomienia sklepu są częścią procesu sprzedaży. |
| Przekroczenia | Co dzieje się po osiągnięciu limitu: throttling, kolejka, błąd czy blokada? | Ten sam limit może mieć inne skutki zależnie od platformy. |
Czego nie przeceniać przy wyborze hostingu dla sklepu
- Samej pojemności SSD/NVMe. Duży dysk nie mówi nic o CPU, workers, bazie ani I/O.
- Liczby baz danych. Sklep zwykle potrzebuje jednej bazy, a ważniejsze są parametry jej działania.
- Hasła „nielimitowane strony”. W typowej konfiguracji witryny na jednym koncie korzystają ze wspólnej puli zasobów. Niektórzy operatorzy mogą jednak stosować izolację albo limity per domena, dlatego trzeba sprawdzić konkretną konfigurację.
- Nazwy „hosting WooCommerce”. Sprawdź konkretne parametry i limity.
- Pojedynczej technologii. Redis, LiteSpeed czy CDN nie zastąpią poprawnej aplikacji i wystarczających zasobów.
Jeżeli planujesz kilka serwisów na jednym koncie, warto przeczytać także poradniki o hostingu dla kilku stron i o tym, co naprawdę oznacza „nielimitowana liczba stron”. Przed zakupem przyda się też lista z artykułu jak sprawdzić limity hostingu przed zakupem.
Czy wolny sklep oznacza, że trzeba zmienić hosting
Nie. Najpierw trzeba ustalić wąskie gardło. Jeżeli sklep regularnie osiąga udokumentowany limit planu, a aplikacja działa poprawnie, wyższy pakiet lub zmiana operatora może być uzasadniona. Jeżeli przyczyną jest ciężka wtyczka, błędne zapytanie, zalegająca kolejka albo niewłaściwa konfiguracja cache, sama migracja może nie przynieść oczekiwanego efektu.
Przed decyzją możesz policzyć koszt wariantów w kalkulatorze zmiany hostingu. Gdy decyzja o migracji już zapadła, planer migracji pomaga uporządkować kolejność prac. Jeśli dopiero określasz wymagania, zacznij od narzędzia dobierz hosting.
Dla WooCommerce liczy się zestaw parametrów, a nie jedna liczba na karcie planu. Najpierw sprawdź zgodność środowiska z aktualną wersją platformy. Potem oceniaj CPU, RAM, workers, bazę danych, cron, cache, I/O, backup i sposób testowania zmian w odniesieniu do rzeczywistego obciążenia sklepu.