Hosting dla sklepu internetowego: co wybrać dla PrestaShop, Shoper i WooCommerce

Blog na słabym hostingu po prostu ładuje się wolniej. Sklep na słabym hostingu przestaje przyjmować zamówienia — i robi to dokładnie w tym momencie, w którym ruch jest największy, czyli wtedy, gdy kosztuje to najwięcej. To jest cała różnica między doborem hostingu pod treść a doborem hostingu pod e-commerce: w sklepie awaria ma cenę wyrażoną w koszykach, a nie w spadku pozycji.

Ten tekst jest przewodnikiem niezależnym od platformy. Niezależnie od tego, czy stawiasz PrestaShop, korzystasz z Shopera, budujesz na WooCommerce czy patrzysz w stronę Magento, wąskie gardła są bardzo podobne: zapisy do bazy przy koszyku i zamówieniu, brak możliwości cache'owania kluczowych stron, cron, który musi zadziałać co do minuty, oraz backup, który musi dać się odtworzyć razem z zamówieniami, a nie tylko z plikami. Przechodzimy po kolei przez to, co sprawdzić przed zakupem i kiedy przestać kombinować z hostingiem współdzielonym.

Dlaczego sklepy padają tam, gdzie blogi przeżywają

Blog da się w całości zserwować z cache'u. Sklep — nie. Strona kategorii i karta produktu owszem, ale koszyk, kasa, konto klienta i wyszukiwarka produktów muszą być generowane dynamicznie dla każdego użytkownika osobno. To oznacza, że w sklepie każdy równoczesny użytkownik w lejku zakupowym to osobny proces PHP i osobny zestaw zapytań do bazy — w tym zapytań zapisujących, których nie da się rozłożyć na repliki ani schować za cache.

Drugi mechanizm to zapisy do bazy. Dodanie do koszyka, zmiana ilości, przeliczenie wysyłki, rezerwacja stanu magazynowego, utworzenie zamówienia, zapis płatności — to wszystko są operacje zapisu. Przy kilkudziesięciu jednoczesnych koszykach silnik bazy zaczyna blokować wiersze, kolejka rośnie, a użytkownik widzi kasę, która "myśli" osiem sekund. Trzeci mechanizm to opóźnienie w samej kasie: każde 100 ms dodatkowego czasu odpowiedzi na etapie płatności realnie kosztuje konwersję, a to jedyne miejsce w sklepie, gdzie nie masz żadnego cache'u, żeby to ukryć.

Wniosek praktyczny: parametrem, który powinieneś porównywać przy hostingu pod sklep, nie jest przestrzeń dyskowa ani transfer, tylko liczba równoczesnych procesów, limit CPU i wydajność zapisu do bazy danych. Jak te limity czytać i jak je przeliczyć na realny ruch, opisuje osobny tekst o tym, jak czytać limity hostingu.

Wspólny mianownik: czego wymaga każda platforma

Zanim wejdziemy w różnice, lista rzeczy, które musisz mieć niezależnie od silnika sklepu:

• Aktualne PHP. W 2026 roku wspierane są wersje z linii 8.2–8.5, przy czym 8.2 kończy wsparcie z końcem tego roku. Realny cel to 8.3 lub 8.4. Kluczowa jest jednak nie sama wersja, tylko możliwość jej samodzielnej zmiany w panelu — bo migracja sklepu na nowe PHP to proces, który robisz na kopii, testujesz i dopiero potem przełączasz produkcję.
• Komplet rozszerzeń PHP. Silniki sklepowe potrzebują m.in. cURL, GD lub Imagick, intl, mbstring, PDO/MySQL, SimpleXML, zip, opcache. Brak intl albo zip potrafi wyłożyć instalator, a brak Imagick — generowanie miniatur w dużym katalogu.
• Sensowne memory_limit i czasy wykonania. Dla realnego sklepu 256 MB to absolutne minimum, a przy większych katalogach i importach potrzeba więcej. Osobno sprawdź max_execution_time — importy feedów i przeliczanie cen to długie operacje.
• MySQL/MariaDB w aktualnej wersji z InnoDB. Sklep to baza z blokadami wierszowymi i transakcjami. Sprawdź też, czy dostawca w ogóle podaje wersję silnika bazy — jeśli nie, to zwykle znaczy, że jest stara.
• Cron, który rzeczywiście działa. Nie "cron dostępny w panelu", tylko: z jaką najmniejszą częstotliwością (co minutę czy co 15 minut) i czy zadanie nie jest ubijane po przekroczeniu limitu czasu.

Co sprawdzić w zależności od rodziny platformy

PrestaShop. Najbardziej wrażliwy na wersję PHP i na wydajność bazy. Aktualne wydania działają na PHP 8.1 i nowszych, a nowsze gałęzie idą w stronę 8.4–8.5 — jeśli dostawca oferuje tylko starsze wersje, odpada. PrestaShop lubi też pamięć: przy katalogu liczonym w tysiącach produktów, wielu językach i wielu kombinacjach atrybutów zapotrzebowanie na RAM rośnie szybciej niż liczba produktów. Pytaj o możliwość podniesienia memory_limit i o dostęp do Redis lub Memcached pod cache obiektowy.

WooCommerce. Wąskim gardłem jest zwykle nie sam silnik, tylko baza i liczba wtyczek. Kluczowe pytania: czy dostawca daje obiektowy cache (Redis), czy potrafi wykluczyć koszyk i kasę z cache'u strony, oraz czy cron jest systemowy, a nie oparty o ruch użytkowników. Ponieważ to najczęstszy wybór w małych sklepach, opisaliśmy go osobno w tekście hosting dla WooCommerce — co sprawdzić przed uruchomieniem sklepu; tutaj traktujemy go tylko jako jeden z wariantów.

Magento / Adobe Commerce. To już nie jest kandydat na hosting współdzielony i nie ma sensu udawać, że jest. Wymaga Elasticsearch lub OpenSearch, Redisa, kolejek, znacznej ilości RAM-u i dostępu do CLI. Punktem wyjścia jest VPS albo cloud z profilem przygotowanym pod ten stos.

Shoper, Shopify i inne SaaS-y. Tu hostingu nie wybierasz — jest częścią abonamentu i to jest realna zaleta tego modelu: nie martwisz się wersją PHP, cronem ani backupem infrastruktury. Cena tej wygody to brak dostępu do warstwy serwerowej, limity na wywołania API i integracje oraz koszt rosnący razem z obrotem. Hosting zewnętrzny będzie Ci w tym modelu potrzebny co najwyżej pod bloga, landing page albo integracje — i wtedy wystarczy zwykły pakiet współdzielony.

Skoki ruchu i sezonowość

Sklep nie ma równomiernego ruchu. Ma Black Friday, ma sezon przedświąteczny, ma dzień po wysłaniu newslettera i ma efekt kampanii w social mediach. Planowanie hostingu pod średnią jest błędem — planuje się pod szczyt, a właściwie pod liczbę równoczesnych sesji w szczycie.

Praktyczne minimum przygotowania: sprawdź w analityce swój dotychczasowy szczyt równoczesnych użytkowników, pomnóż go przez planowany wzrost i porównaj z limitem procesów w ofercie. Ustal z dostawcą, co się dzieje po przekroczeniu limitu — czy dostajesz kolejkowanie, czy błąd 508, czy zawieszenie konta. Zapytaj, czy da się czasowo podnieść pakiet na miesiąc i czy zmiana jest natychmiastowa, czy wymaga migracji. Cały proces przygotowania sklepu opisuje szerzej poradnik jak przygotować sklep do sezonowego skoku ruchu.

Backup i odtwarzanie, gdy w grze są zamówienia

W sklepie kopia zapasowa ma inną naturę niż na blogu, bo dane zmieniają się co minutę. Kopia dobowa oznacza w najgorszym scenariuszu utratę całego dnia zamówień — a to nie jest strata "danych", tylko strata pieniędzy i sytuacja prawnie kłopotliwa wobec klientów, którzy już zapłacili.

Trzy pytania do dostawcy, na które musisz mieć odpowiedź przed zakupem: jak często robione są kopie bazy (dla sklepu dobowa to minimum, częstsza to komfort), jak długo są przechowywane i czy odtworzysz je samodzielnie z panelu, oraz ile trwa i ile kosztuje przywrócenie. Do tego dołóż własny, niezależny backup poza infrastrukturą dostawcy oraz — to jest część, którą prawie wszyscy pomijają — jednorazowy test odtworzenia na kopii sklepu. Backup, którego nigdy nie przywróciłeś, jest hipotezą, nie zabezpieczeniem.

SSL, płatności i co naprawdę oznacza PCI

Certyfikat SSL nie jest dziś przewagą konkurencyjną żadnego hostingu — darmowe certyfikaty Let's Encrypt są standardem, wydawanym i odnawianym automatycznie, a dla sklepu w modelu z zewnętrzną bramką płatniczą są w zupełności wystarczające. To, co powinieneś sprawdzić, to nie typ certyfikatu, tylko czy odnowienie dzieje się automatycznie i czy obejmuje wszystkie subdomeny, których używasz.

Kwestia PCI DSS wygląda podobnie: jeśli płatności obsługuje operator (a w polskich realiach niemal zawsze obsługuje), dane kart nigdy nie trafiają na Twój serwer i zakres Twoich obowiązków jest minimalny. Ryzyko przenosi się gdzie indziej — na to, żeby nie hostować przestarzałego PHP, mieć aktualne moduły płatności i nie trzymać w bazie danych, których nie musisz trzymać. RODO obowiązuje Cię natomiast w pełni, więc lokalizacja serwerów i to, kto ma do nich dostęp, jest realnym kryterium wyboru. Wśród polskich dostawców pakiety kierowane pod sklepy oferuje m.in. dhosting.pl, ale zasada pozostaje ta sama: porównuj limity i politykę backupu, nie nazwę pakietu.

Kiedy przenieść się na VPS albo cloud

Sygnały, że hosting współdzielony przestał wystarczać, są dość jednoznaczne: administracja sklepu działa wolniej niż strona publiczna, w logach pojawiają się przekroczenia limitu procesów, import feedu produktowego nie kończy się w oknie czasowym, a czas odpowiedzi w kasie rośnie w godzinach szczytu. Do tego dochodzą wymagania techniczne, których współdzielony po prostu nie spełni: własny Redis, Elasticsearch, kolejki, kontrola nad wersją bazy, dostęp do CLI.

Zanim jednak przeskoczysz o poziom wyżej, warto rozumieć, czym te usługi faktycznie się różnią — tłumaczy to porównanie hostingu współdzielonego, VPS-a, serwera dedykowanego i cloudu. VPS to nie jest bowiem automatyczna poprawa. Bierzesz na siebie aktualizacje, monitoring i bezpieczeństwo — jeśli nikt tego nie robi, źle skonfigurowany VPS wypada gorzej niż dobrze zarządzany współdzielony. Realistyczne opcje pośrednie to wyższy pakiet u tego samego dostawcy, hosting współdzielony wyraźnie profilowany pod e-commerce albo VPS zarządzany. Ostatnie trzeba tylko policzyć uczciwie: do abonamentu doliczasz koszt administracji, a nie zakładasz, że zrobi się sama.

FAQ

Czy sklep na hostingu współdzielonym to zawsze zły pomysł? Nie. Sklep z kilkuset produktami i kilkoma zamówieniami dziennie działa na dobrym pakiecie współdzielonym bez problemu. Zły pomysł zaczyna się wtedy, gdy wybierasz najtańszą opcję i nie sprawdzasz limitu równoczesnych procesów — bo to on, a nie dysk, ustawia sufit Twojego ruchu.

Ile pamięci PHP potrzebuje sklep? Dla realnego sklepu produkcyjnego 256 MB traktuj jako podłogę, a przy większym katalogu, wielu językach i regularnych importach celuj wyżej. Ważniejsze od samej liczby jest to, czy możesz ją podnieść samodzielnie i czy dostawca nie ubija procesów po kilkudziesięciu sekundach.

Czy Redis albo Memcached są konieczne? Konieczne nie, ale przy sklepie to jedna z niewielu zmian, która daje odczuwalną poprawę bez przepisywania czegokolwiek. Cache obiektowy zdejmuje z bazy powtarzalne zapytania, co przekłada się bezpośrednio na czas odpowiedzi w koszyku i kasie — czyli tam, gdzie cache strony nie działa.

Migrować sklep przed sezonem czy po nim? Zdecydowanie po. Migracja przed szczytem to najgorszy możliwy moment: nowe środowisko wymaga tygodni obserwacji w realnym ruchu, a Ty nie będziesz miał czasu ani spokoju, żeby to robić. Jeśli już teraz wiesz, że nie wyrobisz się w sezonie, tymczasowo podnieś pakiet, a przenoś się w martwym miesiącu.

Podsumowanie

Hosting pod sklep dobiera się według liczby równoczesnych procesów, wydajności zapisu do bazy, wersji PHP z kompletem rozszerzeń, niezawodnego crona i polityki backupu, którą przetestowałeś w praktyce. Platforma zmienia szczegóły — PrestaShop naciska na RAM i wersję PHP, WooCommerce na cache obiektowy i cron, Magento wypycha Cię od razu na VPS, a SaaS zdejmuje temat z głowy w zamian za kontrolę. Wspólne pozostaje jedno: w e-commerce testujesz hosting zanim ruszy sezon, a nie wtedy, gdy kasa przestaje odpowiadać.