Wstęp i… mini podsumowanie
W skrócie: tani hosting za kilkadziesiąt złotych rocznie to pozorna oszczędność – ujawnia się w wysokim TTFB, drogich odnowieniach i problemach z dostarczalnością poczty. Solidna infrastruktura pod stronę firmową to: dyski NVMe, PHP 8.3 lub nowsze, dwie warstwy cache (page cache i Redis), jawne limity RAM, CPU i procesów PHP, kopie zapasowe z określonym RPO i RTO oraz ochrona WAF i DDoS. Poniżej opisuję wszystkie te parametry krok po kroku, a na końcu znajdziesz listę pytań do wysłania dostawcy.
Wielu właścicieli firm popełnia na starcie ten sam błąd: inwestują w dopracowany projekt i optymalizację kodu strony, a następnie umieszczają witrynę na najtańszym serwerze współdzielonym. Ta pozorna oszczędność szybko obraca się przeciwko nim – w postaci wysokiego TTFB, kosztownych odnowień i wiadomości, które nie docierają do skrzynek klientów.Jako specjalista projektujący rozwiązania nastawione na wyniki biznesowe wielokrotnie spotykałem projekty, które traciły klientów przez powolne działanie hostingu. Wybór serwera pod stronę www nie jest więc decyzją czysto techniczną – to kalkulacja biznesowa, od której zależy, czy witryna stanie się stabilnym narzędziem sprzedażowym, czy źródłem frustracji i odrzuceń. Poniżej znajdziesz zestawienie parametrów, które warto zweryfikować przed wyborem dostawcy, sposób na samodzielne sprawdzenie obecnego hostingu oraz listę pytań, które możesz wysłać do działu technicznego.Rodzaje hostingu – kiedy wystarczy serwer współdzielony, a kiedy VPS?
Zanim przejdziesz do analizy parametrów, dopasuj typ usługi do skali projektu. Poniższe widełki cenowe są orientacyjne (ceny warto zawsze sprawdzić bezpośrednio u dostawcy – widoczne poniżej są średnią z września 2026). Należy pamiętać by zwracać uwagę na ceny odnowienia po pierwszym roku.- Hosting współdzielony (shared): wiele kont dzieli zasoby jednej maszyny fizycznej. Dobre rozwiązanie dla stron wizytówkowych i lokalnych firm o przewidywalnym ruchu, o ile dostawca podaje jawne limity RAM, CPU i procesów PHP. Orientacyjny koszt: ok. 200–700 zł netto rocznie. Uważaj na promocje za kilka złotych w pierwszym roku – sprawdzaj zawsze cenę odnowienia.
- Managed WordPress Hosting: środowisko współdzielone lub chmurowe skonfigurowane pod WordPressa, zwykle z wbudowanym cache, regułami WAF i automatycznym stagingiem. Dobry wybór dla firm bez własnego administratora. Orientacyjny koszt: ok. 400–1200 zł netto rocznie.
- VPS / Cloud: gwarantowana, wydzielona część zasobów CPU i RAM. Warto rozważyć przy sklepach WooCommerce z większą liczbą zamówień miesięcznie, rozbudowanych portalach lub integracjach ze stałą synchronizacją z systemami ERP/CRM.
Kluczowe parametry techniczne serwera
Rekomenduję unikać dostawców, którzy ukrywają parametry wydajnościowe za ogólnikowymi hasłami reklamowymi, takimi jak „nielimitowany transfer” czy „nielimitowana przestrzeń”. Liczą się konkretne, jawnie podane liczby:| Parametr | Rekomendowane minimum | Dlaczego to ważne? |
|---|---|---|
| Pamięć RAM dla procesu PHP | min. 1 GB (2 GB przy WooCommerce) | Zapobiega błędom pamięci przy generowaniu raportów, imporcie produktów i edycji blokowej. |
| Procesor (CPU / vCPU) | jawny limit, min. 100% rdzenia | Odpowiada za szybkość wykonywania skryptów PHP przy równoległych wizytach. |
| Limit procesów PHP (entry processes) | jawnie podany, dopasowany do ruchu | Zbyt niski limit powoduje błędy 503 przy jednoczesnych wizytach na koszyku czy w panelu klienta. |
| Nośniki danych | dyski NVMe | Wyższa liczba operacji I/O przyspiesza zapytania do bazy MySQL. |
| Wersja PHP | min. 8.3 (dostępne też 8.4 i 8.5) | Wsparcie bezpieczeństwa i wyższa przepustowość przetwarzania kodu. |
| Mechanizmy cache | page cache (LSCache/FastCGI) + Redis | Szybkie serwowanie stron statycznych i odciążenie bazy danych na podstronach dynamicznych. |
| Poczta firmowa | obsługa SPF, DKIM, DMARC | Gwarancja, że wiadomości z formularzy i sklepu nie trafią do spamu. |
Czas reakcji serwera (TTFB) i jego wpływ na LCP
TTFB (Time to First Byte) to czas od wysłania żądania przez przeglądarkę do odebrania pierwszego bajtu odpowiedzi z serwera. Nie jest samodzielnym wskaźnikiem Core Web Vitals, ale jest bezpośrednią składową metryki LCP (Largest Contentful Paint), która wchodzi w skład Core Web Vitals.
Oficjalna dokumentacja Google (web.dev) uznaje TTFB do 800 ms za wynik akceptowalny. W dobrze skonfigurowanych wdrożeniach, z cache po stronie serwera, realne jest osiągnięcie 100–300 ms dla użytkowników z Polski. Jeśli serwer potrzebuje 700 ms na samo przetworzenie żądania, przeglądarce zostaje bardzo mało czasu na wyrenderowanie głównego elementu strony w budżecie 2,5 sekundy, jaki Google przyjmuje jako dobry wynik LCP.
Wskaźnik INP (Interaction to Next Paint), który w marcu 2024 roku zastąpił FID w Core Web Vitals, mierzy czas reakcji interfejsu na kliknięcia użytkownika i zależy przede wszystkim od kodu JavaScript wykonywanego w przeglądarce – nie od samego hostingu. Sam dobry serwer nie naprawi więc strony przeciążonej skryptami.
Pamięć podręczna: LSCache i Redis to dwie różne warstwy
Częstym błędem jest wrzucanie wszystkich mechanizmów cache do jednego worka. Nowoczesna konfiguracja powinna obejmować dwa poziomy:
- Cache całych stron (page cache): realizowany bezpośrednio przez serwer www, np. LiteSpeed z modułem LSCache albo Nginx z FastCGI cache. Pozwala ominąć interpreter PHP przy powtarzalnych wizytach i od razu odesłać gotowy kod HTML.
- Cache obiektowy (Redis lub Valkey): przechowuje w pamięci RAM wyniki powtarzalnych zapytań do bazy MySQL. Jest kluczowy na podstronach dynamicznych – koszyku, koncie klienta, wynikach filtrów – których nie da się w pełni objąć page cache.
Nie ma jednej najlepszej konfiguracji – LiteSpeed z LSCache dobrze sprawdza się przy WordPressie i WooCommerce, ale dobrze skonfigurowany Nginx lub Apache z PHP-FPM i Redisem daje podobne efekty. Ważne, żeby dostawca jasno deklarował obie warstwy cache w danym pakiecie.
Wersja PHP i limit procesów – dlaczego to fundament wydajności i bezpieczeństwa
Bezpieczną bazą we wrześniu 2026 roku jest PHP 8.3 lub nowsze, a dobry dostawca oferuje też wersje 8.4 i 8.5 oraz pozwala zmieniać wersję PHP dla każdej domeny z poziomu panelu. Wsparcie bezpieczeństwa dla PHP 8.2 kończy się 31 grudnia 2026 roku, a dla PHP 8.1 zakończyło się już 31 grudnia 2025 roku (php.net). Dla WordPressa minimalna rekomendowana wersja PHP to obecnie 8.3. Sama migracja na nowszy PHP zwykle nie przyspiesza strony spektakularnie – to raczej kilka do kilkunastu procent – ale jest warunkiem bezpieczeństwa i dalszych aktualizacji CMS.
Osobno warto sprawdzić limit jednoczesnych procesów PHP (entry processes) – parametr określający, ile zapytań serwer przetwarza równocześnie. Zbyt niski limit sprawia, że przy jednoczesnej wizycie kilkunastu użytkowników kolejni dostają błąd 503 Service Unavailable. Dotyczy to zwłaszcza stron, których nie da się w pełni cache’ować: koszyka, panelu klienta i systemów rezerwacji.
Kopie zapasowe: RPO, RTO i reguła 3-2-1
Obietnica „robimy backupy raz na dobę” to za mało. Weryfikując ofertę, sprawdź dwa parametry:
- RPO (Recovery Point Objective): maksymalny dopuszczalny wiek danych w kopii. Dla prostej strony wizytówkowej backup raz na dobę jest akceptowalny, ale dla aktywnego sklepu utrata 24 godzin zamówień to poważny problem.
- RTO (Recovery Time Objective): ile czasu faktycznie zajmie odzyskanie działania strony po poważnej awarii. Zależy to od wielkości bazy danych, liczby gigabajtów multimediów i przepustowości łącza serwera zapasowego – zamiast wierzyć obietnicom, poproś o test odtworzenia.
Dobrą praktyką jest reguła 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z czego jedna poza główną lokalizacją – kopie powinny trafiać na odizolowaną macierz w innym centrum danych niż serwer główny. Testowanie backupów warto ująć na stałe w umowie o opiekę techniczną i usługi posprzedażowe nad stroną.
Bezpieczeństwo, lokalizacja serwera i RODO
Jeśli Twoja firma kieruje ofertę do odbiorców w Polsce, serwer fizyczny powinien znajdować się w Polsce lub na terenie Unii Europejskiej – to niższe opóźnienia sieciowe, a często też prostsza droga do zgodności z RODO.
- Izolacja kont (np. CloudLinux LVE i CageFS): każde konto działa w osobnym, ograniczonym środowisku na poziomie systemu operacyjnego – to izolacja programowa, a nie sprzętowa. Dzięki niej infekcja na stronie innego klienta nie zagraża Twojej witrynie.
- WAF (Web Application Firewall): system analizujący ruch HTTP i blokujący typowe ataki, takie jak wstrzykiwanie kodu SQL, XSS czy brute force. Nie zastępuje regularnych aktualizacji CMS i wtyczek.
- Ochrona przed atakami DDoS: filtrowanie ruchu na poziomie sieci dostawcy. Przy większych projektach warto rozważyć dodatkowo CDN lub proxy z ochroną (np. Cloudflare).
- Protokoły i szyfrowanie: darmowy, automatycznie odnawialny certyfikat SSL/TLS (np. Let’s Encrypt) oraz obsługa HTTP/2 i HTTP/3.
- Zgodność z RODO: zgodnie z art. 28 RODO dostawca serwera jest podmiotem przetwarzającym dane osobowe Twoich klientów (np. adresy IP, dane z formularzy). Musisz mieć możliwość podpisania lub zaakceptowania umowy powierzenia przetwarzania danych (DPA).
Poczta firmowa: SPF, DKIM, DMARC
Poprawna konfiguracja rekordów SPF, DKIM i DMARC decyduje o tym, czy wiadomości z formularza kontaktowego, sklepu czy systemu rezerwacji trafią do skrzynki klienta, a nie do spamu. SPF wskazuje, które serwery mają prawo wysyłać maile w imieniu Twojej domeny, DKIM to cyfrowy podpis wiadomości, a DMARC mówi serwerom odbiorcy, jak traktować maile, które nie przejdą weryfikacji.
Biznesowe konsekwencje powolnego serwera
Wolno ładująca się witryna obniża efektywność płatnych kampanii – płacisz za kliknięcie w Google Ads czy Meta Ads, a część wartościowego ruchu odbija się od strony, zanim ta zdąży się załadować. Dane Google pokazują, że prawdopodobieństwo odrzucenia rośnie o 32%, gdy czas ładowania wydłuża się z 1 do 3 sekund, a o 90% przy wydłużeniu z 1 do 5 sekund. Badanie Deloitte i Google powiązało skrócenie czasu ładowania o 0,1 sekundy ze wzrostem konwersji w e-commerce o ok. 8,4%, a analiza Portent (2019) wskazuje na ok. trzykrotnie wyższą konwersję B2B przy stronach ładujących się w 1 sekundę względem 5 sekund. To dane sprzed kilku lat i mają charakter korelacyjny, ale kierunek zależności pozostaje ten sam.
Core Web Vitals (LCP, INP, CLS) są jednym z sygnałów rankingowych Google, ale ich wpływ na pozycję jest umiarkowany – treść i dopasowanie do intencji użytkownika nadal ważą więcej. Przy zbliżonych wynikach konkurencji szybkość może jednak przesądzić, a dla użytkownika jest po prostu odczuwalna. Jeśli masz stronę, na której działa system rezerwacji / rejestracji albo elementy oparte o automatyzacje AI działające na webhookach, niestabilność serwera przekłada się też na błędy w zapisach i niedziałające procesy – a to koszt, który rzadko trafia od razu do arkusza kalkulacyjnego.
Jak samodzielnie sprawdzić swój obecny hosting?
Nie musisz wierzyć na słowo deklaracjom z panelu dostawcy – stan infrastruktury możesz zweryfikować za pomocą bezpłatnych narzędzi:
- PageSpeed Insights: sekcja danych laboratoryjnych pokaże wynik z jednorazowego testu, a raport na bazie CrUX (jeśli strona ma wystarczający ruch) – realne dane z odwiedzin użytkowników, w tym TTFB.
- org: uruchom test z lokalizacji w Warszawie lub Frankfurcie i sprawdź wykres Waterfall oraz czas pierwszego bajtu.
- Mail-Tester.com: wyślij testową wiadomość ze swojego formularza kontaktowego, aby sprawdzić poprawność rekordów SPF, DKIM i DMARC.
Lista pytań weryfikacyjnych do dostawcy hostingu
Przed podpisaniem umowy lub migracją usług prześlij dostawcy poniższe pytania. Jeśli to możliwe, skorzystaj też z okresu próbnego lub gwarancji zwrotu pieniędzy i zmierz TTFB w praktyce.
- Jakie gwarantowane limity CPU, RAM oraz jednoczesnych procesów PHP otrzymuję w wybranym pakiecie?
- Które wersje PHP są dostępne (minimum 8.3, najlepiej także 8.4 i 8.5) i czy mogę zmieniać je samodzielnie dla każdej domeny?
- Czy stosujecie dyski NVMe i jaki stos technologiczny odpowiada za cache (page cache oraz Redis lub Valkey)? Czy obie warstwy są dostępne w wybranym pakiecie?
- Gdzie fizycznie przechowywane są kopie zapasowe, jakie jest RPO i RTO oraz czy mogę samodzielnie przetestować odtworzenie kopii?
- Jaką izolację kont zapewnia serwer (np. CloudLinux LVE) oraz czy działa ochrona WAF i przed atakami DDoS?
- W jakim kraju znajdują się serwery i czy mogę podpisać umowę powierzenia przetwarzania danych (RODO)?
- Czy serwer umożliwia pełną konfigurację rekordów SPF, DKIM i DMARC dla domeny pocztowej?
- Jaki jest gwarantowany uptime w skali roku, tryb rekompensaty w umowie SLA oraz ile realnie kosztuje usługa po zakończeniu okresu promocyjnego?
Podsumowanie: serwer to fundament Twojego biznesu online
Wybór hostingu to decyzja o charakterze strategicznym. Jeśli zależy Ci na tym, by Twoja obecność w sieci była stabilna, bezpieczna i przygotowana na obsługę ruchu z kampanii reklamowych, wybieraj usługę na podstawie konkretnych, weryfikowalnych parametrów, a nie hasła „nielimitowany”. Aktualne PHP, dwie warstwy cache, jawne limity zasobów, backup z określonym RPO i RTO oraz wsparcie techniczne, które reaguje w godzinach, a nie w dniach – to zestaw, który realnie ogranicza ryzyko i wspiera wyniki sprzedażowe.
Projektując dla klientów strony internetowe i sklepy e-commerce, dobieram infrastrukturę tak, by maksymalizować zwrot z inwestycji, a po wdrożeniu dbam o to, by serwer działał bezawaryjnie. Jeśli nie masz pewności, czy Twój obecny hosting nie ogranicza wyników firmy, chętnie pomogę – przeprowadzę audyt infrastruktury i doradzę rozwiązanie, które poprawi szybkość i stabilność strony. Skontaktuj się, aby porozmawiać o szczegółach.
FAQ - Najczęściej zadawane pytania
1. Hosting współdzielony czy VPS – co wybrać na start?
Dla nowej strony firmowej lub bloga o umiarkowanym, przewidywalnym ruchu zwykle wystarczy dobrze skonfigurowany hosting współdzielony z dyskami NVMe i PHP 8.3+. Na VPS lub chmurę warto przejść przy uruchomieniu większego sklepu WooCommerce, konieczności instalacji niestandardowych bibliotek na serwerze lub przy gwałtownych skokach ruchu.
