Dlaczego hosting dla sklepu to inne wymagania niż dla bloga

Blog na WordPressie z cache pełnostronicowym oddaje większość odsłon bez uruchamiania PHP — żądanie kończy się na pliku statycznym albo w Varnishu i do bazy nie trafia ani jedno zapytanie. Sklep tak nie działa.

Strona kategorii z filtrami w WooCommerce to zwykle kilkadziesiąt do kilkuset zapytań SQL na jedno wywołanie: posty produktów, postmeta, warianty, stany magazynowe, ceny z podatkami, taksonomie atrybutów i przeliczenie licznika wyników dla każdego filtra. W PrestaShop odpowiednikiem są tabele ps_layered_* i JOIN-y po atrybutach. Wpis blogowy z tego samego serwera to kilka–kilkanaście zapytań. Różnica nie jest procentowa, jest rzędowa.

Druga różnica to ścieżki, których zcache'ować nie wolno: koszyk, kasa, konto klienta, endpointy AJAX typu ?wc-ajax=add_to_cart. Każde kliknięcie „dodaj do koszyka” zajmuje pełny proces PHP i zapisuje sesję. W WooCommerce siedzą one w wp_woocommerce_sessions, a przy porzuconych koszykach i botach ta tabela puchnie do setek tysięcy wierszy — widzieliśmy sklepy, gdzie sam cron czyszczący sesje zjadał limit procesów na shared hostingu.

Koszt opóźnień jest realny. Powszechnie cytowane badania Akamai i Deloitte podają ok. -7% konwersji za każdą dodatkową sekundę ładowania; nie mamy do nich zweryfikowanego linku, więc traktuj tę liczbę jako rząd wielkości, nie stałą. Sprawdzalne u siebie są Core Web Vitals (LCP, INP, CLS) w Search Console, no i porzucenia koszyka w Analytics. Jeśli wskaźniki odrzuceń rosną razem z ruchem, zajrzyj do typowych przyczyn wysokiego bounce rate w sklepie — hosting jest tam jedną z pierwszych rzeczy do wykluczenia.

Trzecia różnica: SSL i PCI-DSS. Nawet gdy płatność przenosi się do PayU czy Przelewy24, strona sklepu mieści się w zakresie SAQ A-EP. Standard wymaga TLS 1.2 lub wyższego i aktualnego stosu kryptograficznego. Hosting, który nie pozwala wyłączyć starych protokołów ani nie łata OpenSSL, jest po prostu dyskwalifikowany.

Typy hostingu: shared, VPS, cloud — który dla jakiego sklepu

Shared hosting sprawdza się do około 500 unikalnych sesji na dobę i kilku–kilkunastu zamówień. Płacisz za miejsce w środowisku, gdzie kilkuset innych klientów dzieli ten sam CPU i tę samą pulę I/O. Nie masz izolacji procesów — cudzy skrypt eksportujący feed do Google Shopping potrafi zjeść dysk na godzinę, a Twoja kasa zwróci w tym czasie błąd 508 „Resource limit reached”. Nie da się tego przewidzieć ani obejść z Twojej strony.

VPS to minimum od około 1000 sesji na dobę albo wcześniej, jeśli sklep ma rozbudowany zestaw wtyczek: multiwarianty, kalkulacje wysyłki po API kurierów, synchronizację z ERP, dwa systemy rekomendacji. Dostajesz gwarantowane vCPU i RAM oraz kontrolę nad wersją PHP, OPcache i Redisem. Praktyczny próg graniczny: powyżej 100 zamówień na dobę shared hosting to nie oszczędność, to aktywne ryzyko — jedna zablokowana kasa w piątkowy wieczór kosztuje więcej niż roczna różnica w abonamencie. Rozpisaliśmy to szerzej w tekście o tym, dlaczego tani hosting zawodzi i jak bezpiecznie przenieść sklep na VPS.

Cloud (Cloudways, Kinsta, SiteGround Cloud i podobne) ma sens przy dużych wahaniach ruchu: Black Friday, wyprzedaże sezonowe, kampanie z influencerami, gdzie szczyt jest 10–20× wyższy od średniej. Płacisz za możliwość dołożenia zasobów w kilka minut, bez migracji.

Managed vs unmanaged to pytanie, kto o 2:00 restartuje MariaDB. Unmanaged VPS za 60 zł wymaga kogoś, kto skonfiguruje nginx, fail2ban, kopie zapasowe i monitoring. Bez działu IT albo agencji na abonamencie wybieraj managed — realna różnica w cenie to zwykle 100–300 zł miesięcznie, czyli mniej niż jedna interwencja awaryjna.

Kluczowe parametry techniczne, które musisz sprawdzić

Specyfikacje dostawców są napisane tak, żeby brzmieć dobrze. Sprowadź je do sześciu liczb i sprawdź każdą przed zakupem, najlepiej pytaniem na czacie sprzedażowym — odpowiedź na piśmie bywa później przydatna.

• PHP workers / entry processes — ile żądań PHP serwer obsłuży równolegle. Minimum 4 dla małego WooCommerce, 6–8 dla średniego sklepu z filtrami i AJAX-owym koszykiem. Przy limicie 2 wystarczy jeden bot skanujący katalog, żeby klient zobaczył błąd. Wielu dostawców shared nie podaje tej liczby w ofercie; brak odpowiedzi traktuj jako odpowiedź.
• RAM na proces PHP (memory_limit) — minimum 256 MB, optymalnie 512 MB. Import produktów z pliku CSV i generowanie faktur PDF to dwa najczęstsze miejsca, gdzie 128 MB kończy się białym ekranem. Sprawdzisz w WordPressie w Narzędzia → Stan witryny, w PrestaShop w Zaawansowane → Informacje.
• TTFB — cel poniżej 200 ms dla ruchu z Polski, czyli serwer w kraju albo CDN z węzłem w Warszawie. Zmierz sam: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://adres, kilka razy, także wieczorem.
• Limit bazy danych — brak limitu wierszy, minimum 1 GB przestrzeni dla katalogu 500+ produktów. Limity typu „max 500 tys. wierszy” zabijają sklep na tabelach sesji i logów.
• Warstwy cache — OPcache włączony domyślnie plus dostępny Redis albo Memcached na object cache. Bez tego każde żądanie odtwarza konfigurację od zera. PrestaShop opisuje obsługiwane backendy cache w dokumentacji dla deweloperów.
• PHP i SSL — minimum 8.1, z dostępnym 8.3, przełączanym z panelu bez zgłoszenia. Certyfikat: automatyczny Let's Encrypt z odnawianiem, wildcard jeśli masz subdomeny. Pytaj wprost, czy jest w cenie — dopłata 200 zł rocznie za DV jest dziś anachronizmem.

Pułapki tanich planów hostingowych i jak je wykryć przed zakupem

Plan za 15 zł miesięcznie nie jest problemem sam w sobie. Problemem jest plan, którego realnych limitów nie znasz przed podpisaniem umowy. Zanim zapłacisz, wyślij ticket na support przedsprzedażowy i poproś o konkretne liczby: ile procesów PHP może działać jednocześnie (entry processes), ile rdzeni CPU i MB RAM przypada na konto, jaki jest limit I/O w MB/s, ile inodów, ile jednoczesnych połączeń do MySQL. Jeśli w odpowiedzi dostaniesz „nie limitujemy zasobów”, to znaczy, że limit istnieje, ale nie jest opisany w umowie i będzie wymuszany ubijaniem procesów w godzinach szczytu.

„Nieograniczony transfer” i „nieograniczona przestrzeń” to zwykle skrót od fair use policy. Ten zapis znajdziesz w regulaminie pod hasłem nadmiernego wykorzystania zasobów i on daje dostawcy prawo zawiesić konto. Przeczytaj go przed zakupem, nie po pierwszym mailu o przekroczeniu limitów.

Brak izolacji procesów boli podwójnie. Jeden węzeł z kilkuset kontami oznacza wspólne CPU, ale też wspólny adres IP dla poczty wychodzącej. Wystarczy, że sąsiad rozsyła spam, IP wejdzie na listę Spamhausa i twoje maile z potwierdzeniem zamówienia zaczynają lądować w spamie. Objaw wygląda jak błąd sklepu, a przyczyna jest cudza. Wolniejszy TTFB od przeciążonego węzła przekłada się też bezpośrednio na LCP, czyli jeden z Core Web Vitals.

Przy backupie zadaj jedno pytanie: czy mogę przywrócić pojedynczy plik i jedną tabelę bazy, czy tylko całe konto. Przywracanie całego konta po awarii wtyczki cofa też zamówienia złożone po kopii.

Sprawdź opłaty poza abonamentem: SSL inny niż Let's Encrypt, migracja, kolejne domeny, ręczne przywrócenie kopii, a przede wszystkim cena po pierwszym okresie rozliczeniowym. Odnowienie bywa dwa razy droższe od promocji.

Arytmetyka przestoju: sklep robiący w Black Friday 80 zamówień na dobę przy koszyku 220 zł ma około 17 600 zł obrotu. Cztery godziny padu w oknie 18:00–22:00 to nie 1/6 doby, bo w tych godzinach wpada często 25–30% zamówień. Do tego dochodzi budżet Ads wydany na ruch, który trafił na błąd 503. Pełny rozkład takich kosztów rozbieramy w tekście o kosztach sklepu internetowego.

Backup, monitoring i SLA — czego wymagać od dostawcy

SLA przelicz na minuty, bo procenty nic nie mówią. Różnica między 99,9% a 99,95% to w praktyce 4,4 godziny rocznie, czyli jedna dłuższa awaria w sezonie. Sprawdź przy tym trzy rzeczy w treści SLA: jak dostawca definiuje niedostępność (często tylko brak odpowiedzi na poziomie sieci, nie błąd 502 z PHP-FPM), czy okna serwisowe są wyłączone z rozliczenia i czy to ty musisz zgłosić przestój, żeby dostać rekompensatę. Rekompensata prawie zawsze ma formę kredytu na abonament, nie pokrycia utraconej marży.

Backup u dostawcy traktuj jako pierwszą kopię, nie jedyną. Minimum sensowne dla sklepu: kopia codzienna, retencja 14 dni, kopia off-site poza centrum danych dostawcy. Jeśli backup leży na tej samej macierzy co produkcja, nie jest backupem, tylko snapshotem. Drugą kopię rób sam — dump bazy i katalogu z plikami klientów na zewnętrzny magazyn S3-kompatybilny, z cronem i logiem. Raz na kwartał zrób próbne przywrócenie na środowisko testowe i zmierz czas. Ten czas jest twoim realnym RTO, a nie ten z ulotki.

Monitoring musi być zewnętrzny i niezależny od dostawcy — UptimeRobot albo Better Uptime, interwał 1 minuta, alert SMS-em, nie tylko mailem. Sprawdzaj endpoint, który faktycznie dotyka bazy i sesji: kartę produktu z parametrem cache-buster albo krok koszyka. Monitorowanie strony głównej podanej z cache Varnisha potwierdzi „uptime”, kiedy checkout już nie działa. Dodaj drugi monitor na certyfikat SSL i na czas odpowiedzi, żeby widzieć degradację przed padem.

Support zweryfikuj testem, nie deklaracją. Wyślij ticket w sobotę wieczorem i zmierz czas pierwszej odpowiedzi. Zapytaj wprost, czy wsparcie 24/7 obejmuje telefon i inżyniera, czy tylko przyjęcie zgłoszenia do kolejki, oraz czy obsługa jest po polsku. Przy migracji na własną infrastrukturę pomaga też przejrzeć wcześniej scenariusze z tekstu o VPS dla e-commerce i bezpiecznym przeniesieniu sklepu.

Bezpieczeństwo hostingu dla e-commerce

Sklep przetwarza dane osobowe i dotyka płatności, więc wymagania są wyższe niż dla strony wizytówki. Pierwsze pytanie: jak wygląda izolacja kont. Szukaj suEXEC lub osobnej puli PHP-FPM per użytkownik, ustawionego open_basedir, a na hostingu współdzielonym CloudLinux z CageFS. Bez tego proces PHP jednego klienta może czytać pliki innego, w tym parametry dostępu do bazy z app/config/parameters.php w PrestaShop albo wp-config.php w WooCommerce. Zapytaj wprost, czy hosting stoi na CloudLinux i czy limity są per konto.

WAF: ustal, czy dostawca daje ModSecurity z regułami OWASP CRS i czy możesz sam wyłączać pojedyncze reguły. Bez tej możliwości pierwszy fałszywy alarm zablokuje ci zapis produktu w panelu. Alternatywa niezależna od hostingu to Cloudflare przed domeną, z regułami na katalog panelu (w PrestaShop po zmianie nazwy folderu admin) i na wp-login.php. Przy DDoS przyjmij, że filtracja L3/L4 to standard w cenie, a ochrona warstwy aplikacyjnej (L7) prawie zawsze wymaga zewnętrznego proxy.

Aktualizacje systemu: dopytaj, kto łata OS i kernel oraz jakie wersje PHP są dostępne. Jeśli najnowsza to PHP 8.1 albo starsza, planujesz pracę na gałęzi bez wsparcia bezpieczeństwa. Wersje wspierane przez konkretne wydania sklepu sprawdzisz w dokumentacji dla deweloperów PrestaShop.

RODO w praktyce oznacza trzy dokumenty i jedną lokalizację: umowę powierzenia przetwarzania danych (DPA), listę podprocesorów, informację o retencji logów oraz serwery i backupy w UE. Jeśli kopie jadą do regionu poza EOG, potrzebujesz podstawy transferu — to pytanie do dostawcy przed zakupem, nie po kontroli.

Skanowanie malware ma sens, gdy generuje alert i kwarantannę z powiadomieniem, a nie ciche usunięcie pliku. Imunify360 czy ImunifyAV potrafią zabrać zainfekowany plik szablonu i wywalić layout sklepu, więc ustaw powiadomienia mailowe i sprawdzaj kwarantannę po każdym alercie.

Jak ocenić dostawcę przed zakupem: 5 testów, które możesz zrobić sam

Stronę marketingową dostawcy przeczytasz w 5 minut. Jakość obsługi i infrastruktury sprawdzisz w dwa wieczory. Zrób to przed przelewem, nie po pierwszej awarii w piątek.

1. Ticket testowy o PHP workers. Jeszcze przed zakupem napisz na support: „Ile procesów PHP-FPM (PHP workers) przypada na moje konto i jaki jest limit max_children? Co dzieje się z żądaniami, gdy limit zostanie przekroczony?”. Mierzysz dwie rzeczy: czas pierwszej odpowiedzi (przyzwoity wynik to poniżej 2 godzin w dzień roboczy, 4 godziny w weekend) i czy w odpowiedzi jest liczba. Zdanie „nasze serwery są bardzo wydajne” bez liczby oznacza, że albo nie wiedzą, albo nie chcą powiedzieć. Oba warianty są złe.
2. Historia awarii. Poszukaj publicznego status page. Jeśli dostawca go nie ma, to już jest informacja. Potem przeszukaj WebHostingTalk i polskie fora hostingowe: nazwa dostawcy plus „outage” i „awaria”. Patrz na daty i częstotliwość, nie na emocje. Trzy dłuższe przestoje w ostatnim roku to wzorzec, nie przypadek.
3. PageSpeed Insights i GTmetrix na jego własnej stronie. Dostawca hostuje się u siebie. Sprawdź TTFB i LCP na jego stronie głównej oraz na demo sklepu. TTFB powyżej 600 ms na lekkiej witrynie wizytówkowej to zapowiedź tego, co dostanie Twój koszyk.
4. ping.pe albo host-tracker.com. Wpisz adres serwera i sprawdź, gdzie fizycznie stoi maszyna oraz jakie są czasy odpowiedzi z Europy. Serwer w Polsce lub we Frankfurcie da klientom z Polski 5–25 ms. Serwer w USA to 100–150 ms dokładane do każdego zapytania.
5. Opinie z filtrem. Na Trustpilot i w Google ustaw 1 gwiazdkę i czytaj tylko wpisy z konkretem technicznym: „konto zawieszone za przekroczenie CPU”, „migracja bez zapowiedzi”, „backup starszy niż 7 dni”. Recenzje bez szczegółów pomiń.

Łącznie około 90 minut pracy. Tyle kosztuje uniknięcie migracji po trzech miesiącach.

Migracja sklepu do nowego hostingu: na co uważać

Migracja to nie skopiowanie plików. To operacja, w której najłatwiej zgubić zamówienia złożone w trakcie przenoszenia. Kolejność jest nienegocjowalna: najpierw pełne przeniesienie i testy, DNS na samym końcu.

1. Backup jako warunek startu. Pełny mysqldump plus archiwum plików, pobrane na dysk lokalny albo do zewnętrznego magazynu — nie na serwer, z którego się wyprowadzasz. Zanotuj rozmiar dumpa i liczbę zamówień na moment wykonania kopii. Bez tego nie zaczynasz.
2. TTL na 300 s, minimum dobę wcześniej. Jeśli rekord A ma TTL 86400, resolwery będą trzymać stary adres jeszcze cały dzień po zmianie. Obniż TTL 24–48 godzin przed migracją, podnieś go z powrotem po tygodniu.
3. Test przez plik hosts. Dopisz IP nowego serwera i domenę do pliku hosts (Windows: C:\Windows\System32\drivers\etc\hosts, macOS i Linux: /etc/hosts). Ty widzisz nowy serwer, klienci wciąż stary. Przejdź całą ścieżkę: kategoria, filtry, koszyk, dostawa, płatność w trybie sandbox, faktura, mail transakcyjny, logowanie do panelu, eksport do ERP.
4. Weryfikacja bazy. Porównaj COUNT(*) na kluczowych tabelach po obu stronach: ps_orders, ps_customer, ps_product w PrestaShop, wp_posts, wp_postmeta, wp_woocommerce_order_items w WooCommerce. Tabele sesji i cache możesz wyczyścić, ale muszą istnieć i mieć poprawne uprawnienia. Potem czytaj log błędów PHP przez pierwszą godzinę — brakujące rozszerzenia (intl, gd, soap, zip), zła wersja PHP i złe ścieżki ujawniają się właśnie tam.
5. Okno przełączenia. Wtorek rano, nie piątek po 15:00. Stary serwer trzymaj włączony jeszcze 72 godziny, dopóki jego logi nie pokażą zerowego ruchu.

Najczęstsze pułapki: nieprzeniesione zadania cron (porzucone koszyki, synchronizacja stanów), twarde ścieżki w konfiguracji, brak certyfikatu SSL w momencie przełączenia. Cały proces krok po kroku opisaliśmy w tekście o tym, dlaczego tani hosting zawodzi i jak bezpiecznie przenieść sklep na VPS.

Rekomendacje hostingów dla sklepów w Polsce w 2025

Zero linków afiliacyjnych, zero prowizji — żaden z wymienionych dostawców nie płaci nam za to miejsce. Kryteria są sprawdzalne: dostępne wersje PHP, liczba workerów, dostęp do SSH i crona, polityka limitów CPU, lokalizacja serwerów, sposób wykonywania backupów.

Cenniki zmieniają się szybciej niż ten artykuł, więc podajemy rzędy wielkości, nie kwoty: kilkadziesiąt złotych miesięcznie za sensowny shared, kilkaset za managed lub zarządzany VPS. Sprawdź stawki w dniu zakupu i zwróć uwagę na cenę odnowienia, nie promocyjną pierwszego roku.

PrestaShop to osobna rozmowa. Wymagania środowiska (wersja PHP, rozszerzenia, memory_limit, max_execution_time) są opisane w dokumentacji Google o Core Web Vitals tylko w części dotyczącej wydajności — konkretne minima znajdziesz w dokumentacji technicznej PrestaShop. Problem rzadko dotyczy samej instalacji. Problemem są moduły: generatory feedów do Google Shopping i porównywarek, integracje z ERP, regeneracja miniatur po zmianie szablonu. Każde z tych zadań potrzebuje minut pracy CPU i wysokiego max_execution_time. Shared hosting ubija taki proces po 30–60 sekundach i dostajesz feed z połową produktów albo bazę w stanie niespójnym. Przy katalogu powyżej 5000 SKU, dwóch językach lub multistore VPS przestaje być opcją i staje się warunkiem.

Dla WooCommerce kolejność bywa odwrotna: część problemów, które wyglądają na słaby hosting, to nieoptymalne zapytania wtyczek. Zanim zapłacisz za mocniejszą maszynę, przejdź przez optymalizację prędkości sklepu WooCommerce krok po kroku. Czasem 200 zł na porządek w wtyczkach daje więcej niż 400 zł miesięcznie na serwer.

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

Lista kontrolna do odklikania

• Policz realny ruch i zamówienia — Z Google Analytics weź średnią i szczytową liczbę sesji na dobę z ostatnich 12 miesięcy, z panelu sklepu liczbę zamówień na dobę. To dwie liczby, od których zależy cała decyzja.
• Ustal liczbę PHP workers — Zapytaj support przed zakupem: ile procesów PHP jednocześnie, jaki limit CPU, co się dzieje po przekroczeniu (kolejka czy błąd 503). Minimum 4, komfortowo 6–8.
• Sprawdź RAM na proces PHP — Minimum 256 MB, optymalnie 512 MB. Weryfikacja: wartość memory_limit w phpinfo oraz potwierdzenie od dostawcy, że można ją podnieść.
• Zweryfikuj wersję PHP — Minimum PHP 8.1, w ofercie PHP 8.3. Sprawdź też, jak szybko dostawca udostępnia nowe wersje — opóźnienie roku oznacza, że zostaniesz na niewspieranym PHP.
• Potwierdź dostępność Redis lub Memcached — Pytanie do supportu: czy cache obiektowy jest dostępny w tym planie i czy wymaga dopłaty. Bez niego katalog z filtrami będzie obciążał bazę przy każdym żądaniu.
• Sprawdź limity bazy danych — Brak limitu wierszy albo minimum 1 GB na bazę dla katalogu 500+ produktów. Dopytaj o limit jednoczesnych połączeń do MySQL — to częściej wąskie gardło niż rozmiar.
• Zmierz TTFB przed migracją i po niej — Test z lokalizacji w Polsce, na stronie produktowej i na kategorii z filtrami, nie na stronie głównej. Cel: poniżej 200 ms. Zapisz wynik przed zmianą hostingu, żeby mieć punkt odniesienia.
• Ustal, co dokładnie obejmuje SSL — Czy Let's Encrypt odnawia się automatycznie, czy certyfikat jest wliczony w cenę, czy dostępny jest wildcard dla subdomen (np. środowisko testowe). Sprawdź też wymuszenie HTTPS na poziomie serwera.
• Przeczytaj politykę fair use — „Nielimitowany transfer” i „nieograniczona przestrzeń” prawie zawsze mają zapis o dopuszczalnym obciążeniu w regulaminie. Znajdź konkretne progi i konsekwencje ich przekroczenia.
• Sprawdź parametry backupu — Częstotliwość codzienna, retencja minimum 14 dni, kopia off-site, możliwość odtworzenia pojedynczego pliku i bazy osobno, koszt przywrócenia. Ostatni punkt bywa płatny.
• Przeczytaj SLA i zasady rekompensaty — 99,9% to do 8,7 h przestoju w roku, 99,95% to do 4,4 h. Sprawdź, czy SLA obejmuje okna serwisowe i jak zgłasza się roszczenie — bez tego zapis jest deklaracją.
• Uruchom zewnętrzny monitoring uptime — Narzędzie niezależne od dostawcy, sprawdzające co 1–5 minut nie tylko stronę główną, ale też adres koszyka lub endpoint API. Alert na SMS albo komunikator, nie tylko mail.
• Wyceń ukryte opłaty w perspektywie 24 miesięcy — Cena po okresie promocyjnym, migracja, dodatkowe domeny, SSL, przywrócenie backupu, środowisko staging. Porównuj koszt całkowity, nie cenę pierwszego roku.
• Zaplanuj termin migracji — Poza szczytem sprzedażowym, z tygodniem na testy na środowisku docelowym i obniżonym TTL DNS na 300 s przed przełączeniem. Nigdy w tygodniu Black Friday.

Najczęściej zadawane pytania

Źródła i materiały

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